Table des matières

Introduction Générale 1

1 Cadre général du projet 3 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Axe Finance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.2 Structure et
organisation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.3 Axe Credit Portal « ACP
»......................5
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3.1 Contexte du
projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3.2 Etude de l’existant . . . . . . . . . . . .
. . . . . . . . . . . . . . . 8 1.3.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Choix de la méthodologie du travail . . . . . . . . . . . . . . . . . . . . . 10 1.4.1 Cycle de
vie Ralph Kimball . . . . . . . . . . . . . . . . . . . . . . 11 1.4.2 Méthode
GIMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.4.3 Choix de
méthode . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5 Planification prévisionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.6
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 Lancement du projet et environnement 15 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . 15 2.2 Théorie et enjeux du Business Intelligence . . . . . . . . . . . . . . . . . . 15
2.2.1 Définition de l’informatique décisionnelle . . . . . . . . . . . . . . . 15
2.2.2 Objectifs de l’informatique décisionnelle . . . . . . . . . . . . . . . 16 2.2.3 Architecture
d’un système décisionnel . . . . . . . . . . . . . . . . . 16 2.3 Gestion de recouvrement de
crédit . . . . . . . . . . . . . . . . . . . . . . 17 2.3.1 Le processus de scoring d’octroi des crédits
aux clients . . . . . . . 17 2.3.2 Le recouvrement de crédit . . . . . . . . . . . . . . . . . . . . . . .
18 2.4 Définition des besoins BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.1 Besoins
fonctionnels et métiers . . . . . . . . . . . . . . . . . . . . . 18 2.4.2 Besoins non
fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5 La modélisation des données . . . . . .
. . . . . . . . . . . . . . . . . . . . 19 2.5.1 Modèles d’entrepôt de
données . . . . . . . . . . . . . . . . . . . . 21 2.6 Environnement technique du
travail . . . . . . . . . . . . . . . . . . . . . 24 2.6.1 Etude des outils BI présents sur le
marché . . . . . . . . . . . . . . 24 2.6.2 Nos choix technologiques dans notre projet . . . . . . .
. . . . . . 26 2.6.3 SQL Server 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6.4 Outils
de collaboration . . . . . . . . . . . . . . . . . . . . . . . . 28 2.7 Conclusion . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 28
3 CONCEPTION & MODÉLISATION 29 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 29 3.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1 Architecture fonctionnelle du système . . . . . . . . . . . . . . . . . 29 3.2.2 Architecture
logique des données . . . . . . . . . . . . . . . . . . . 30 3.3 Identification des
indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.4 Conception de l’entrepôt de
données . . . . . . . . . . . . . . . . . . . . . 32 3.4.1 Description des données
source . . . . . . . . . . . . . . . . . . . . 32 3.4.2 Identification des tables
dimensions . . . . . . . . . . . . . . . . . . 35 3.4.3 Vue d’ensemble de la conception de
l’entrepôt . . . . . . . . . . . . 41 3.5
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 MISE EN OEUVRE 46 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2.1 Phase
d’alimentation (ETL) . . . . . . . . . . . . . . . . . . . . . . 46 4.2.2 Phase d’analyse : . . . . .
. . . . . . . . . . . . . . . . . . . . . . . 54 4.2.3 Phase de restitution de données . . . . . . . . .
. . . . . . . . . . . 56
4.3 Développement d’un système de journalisation . . . . . . . . . . . . . . . . 61 4.3.1 Log
ODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.3.2 Log
DWH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4 Processus d’automatisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.5 Déploiement
de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.6
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Conclusion Générale 65

Liste des tableaux

2.1 Etude comparative entre Inmon et KimBall . . . . . . . . . . . . . . . . . 21 2.2 étude

comparative des outils BI . . . . . . . . . . . . . . . . . . . . . . . . 25 2.3 Etude comparative
entre SSRS et Power BI . . . . . . . . . . . . . . . . . 28

3.1 KPI & KRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2 Tableau descriptif

des données source . . . . . . . . . . . . . . . . . . . . . 34 3.3 Description des
dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Table des figures

1.1 Réseaux de partenaires [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Organigramme

 opérationnel de l’entreprise Axe Finance [1] . . . . . . . . . 4 1.3 Architecture de la
solution « ACP » [1] . . . . . . . . . . . . . . . . . . . . 6 1.4 Exemple d’un rapport SSRS
existant[2] . . . . . . . . . . . . . . . . . . . . 9 1.5 Diagramme de flux de travail (Kimball)[3] . . .
. . . . . . . . . . . . . . . 11 1.6 Planification des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13 1.7 Diagramme de Gantt réalisé par Gantt Project . . . . . . . . . . . . . . . 14

2.1 Architecture d’un système décisionnel [4] . . . . . . . . . . . . . . . . . . . 16 2.2

L’approche de l’inmon [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3 L’approche de
Kimball [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4 Schéma d’un modèle en étoile . . .
. . . . . . . . . . . . . . . . . . . . . . 22 2.5 Schéma du modèle en flocon . . . . . . . . . . . . . . . . . .
. . . . . . . . 23 2.6 Quadrant magique de Gartner[6] . . . . . . . . . . . . . . . . . . . . . . . 25 2.7
Logo du SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.8 Logo du
SSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.9 Logo du SSAS . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 27

3.1 Architecture fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2 Architecture

logique des données . . . . . . . . . . . . . . . . . . . . . . . 30 3.3 Modèle de
données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.4 Data mart « Recouvrement » . .
. . . . . . . . . . . . . . . . . . . . . . . 43 3.5 Data mart « Garantie » . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 44

4.1 Chargement du STG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 Standarisation des régions . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.3 Chargement
de la table Client_ODS . . . . . . . . . . . . . . . . . . . . . 49 4.4 Chargement des
dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.5 Chargement «
FACT_Recouvrement » . . . . . . . . . . . . . . . . . . . . 51 4.6 Chargement « FACT_Affaire
» . . . . . . . . . . . . . . . . . . . . . . . . 52 4.7 Chargement « FACT_Garantie » . . . . . . . . . . . .
. . . . . . . . . . . 53 4.8 Cube « Recouvrement » . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.9 Cube « Garantie » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.10 Tableau de bord
« Page d’accueil » . . . . . . . . . . . . . . . . . . . . . . 57 4.11 Tableau de bord «tableau de
bord global» : . . . . . . . . . . . . . . . . . 58 4.12 Tableau de bord « Détails Client
» : . . . . . . . . . . . . . . . . . . . . . . 59 4.13 Tableau de bord « Détails Agent
» : . . . . . . . . . . . . . . . . . . . . . 60 4.14 Log
ODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.15 Table Log de la ODS . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.16 Log
DWH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.17 Job d’automatisation . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 63

Liste des acronymes

 ACP Axe Credit Portal

BI Business Intelligence

DAX Data Analysis Expressions

ETL Extract Transform Load

GIMSI Généralisation Information Système Initiative KPI Key

Performance Indicator

KRI Key Risk Indicator

MDX Multidimensional Expressions

OLAP Online Analytical Processing

SID Système d’Information Décisionnelle STG Staging

Area

SQL Structured Query Language

Dashboard Tableau de bord

SSMS SQL Server Management Studio

Introduction Générale

L aréussite des institutions financières passe premièrement par une gestion intelligente,

continue et complète de l’information pour s’adapter aux différents changements et

par la mise en place d’une stratégie de contrôle qui offre un moyen de présenter à tout
moment des informations synthétiques et exploitables.

Ces informations présentent une importance stratégique pour une institution financière
qui cherche à améliorer sa production, assurer la qualité de ses produits et contrôler la
performance de ses activités et de bien gérer ses risques.

Dans cette optique que la Business Intelligence et la gestion de performance financière

sont deux domaines inséparables. Une grande importance est accordée à l’intégration
des systèmes décisionnels dans le secteur financier qui permettent aux institutions
financières de précéder et de s’adapter rapidement aux changements et aux nouvelles
tendances et vu que la business intelligence puise sa force dans l’interprétation des
différentes données en temps réel, cela offre aux institutions financières capacité de
gagner du temps pour l’analyse de données.

L’informatique décisionnelle occupe une place importante dans la liste des stratégies
des entreprises vu que les approches traditionnelles s’avèrent insuffisantes. Dans ce
cadre, nous allons réaliser un projet, pour la clientèle de la société Axe Finance, qui
consiste à déve lopper une application d’aide à la décision pour automatiser la génération
des Dashboards destinés aux gestionnaires des recouvrement de crédit afin de suivre les
pratiques managé riales et avoir en conséquence une vision globale sur la performance
des crédits accordés.
Notre projet englobe la modélisation de l’entrepôt de données, l’extraction, la transfor
mation, le chargement et la restitution des informations afin de générer des tableaux de
bords interactifs et des indicateurs de performance (KPI) s’adressant à la direction des
institutions financières dans le but de contrôler le recouvrement de crédit du client pour
intervenir en cas de déséquilibre.

1
Notre rapport est divisé en quatre chapitres : Le premier illustre notre cadre de travail à
savoir l’entreprise proposant le sujet, la présentation de notre projet, les problématiques
et la solution dégagée ainsi que la méthodologie de développement et la planification de
projet. Le deuxième chapitre fera l’objet d’une étude sur les concepts généraux de la BI et
recouvrement du crédit ainsi que la spécification des besoins. Le troisième chapitre se
focalise sur la présentation de l’architecture de la solution, le choix des indicateurs et la
modélisation du datawarehouse. Le dernier chapitre se résume en cinq parties y compris
la description de notre environnement de réalisation,le développement du processus ETL,
le déploiement des cubes OLAP , l’illustration d’un aperçu sur les tableaux de bords que
nous avons réalisé.
 2

Chapitre 1

Cadre général du projet

1.1 Introduction
Ce chapitre introductif a pour vocation tout d’abord de mettre le projet dans son
contexte et à présenter l’organisme d’accueil Axe Finance. Ensuite la présentation de la
problématique et de la solution proposée. Puis la méthodologie de travail adoptée. Et en
enfin la planification prévisionnelle.

1.2 Présentation de l’organisme d’accueil

1.2.1 Axe Finance

Axe Finance est une société tunisienne privée, fondée en 2004 qui opère à l’échelle in
ternationale. Elle est dirigée par des experts en gestion du crédit et des risques avec plus
de 20 ans d’expérience dans les secteurs des logiciels bancaires et de la gestion des
risques. L’activité d’Axe Finance consiste à l’automatisation des processus de crédit en
proposant des solutions sur mesure à valeur réelle et mesurable.

La société compte plus de 30000 utilisateurs de 20 pays différents, réparties sur 5

conti nents présentés sur la figure suivante.

3
CHAPITRE 1. CADRE GÉNÉRAL DU PROJET
 Figure 1.1 – Réseaux de partenaires [1]

1.2.2 Structure et organisation

L’organisation de la société s’articule autour de deux lignes métier : « Édition de pro
giciels » et « Conseil aux entreprises ».

Figure 1.2 – Organigramme opérationnel de l’entreprise Axe Finance [1] 4

CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

L’édition de progiciels est organisée autour de six divisions opérationnelles :

— Recherche et Développement (R&D)

Deux équipes composent cette division, une équipe chargée du développement et
de la maintenance de la solution ACP. Une autre équipe qui est en charge des
réflexions technologiques à long terme et à la recherche de nouvelles
 architectures.

— Assurance de la qualité
Cette division assure le test des livrables (des nouvelles versions et des taches cor
rectifs), la documentation fonctionnelle ainsi que la formation interne (ressources
Axe Finance) et externe (clients et partenaires). L’équipe « Assurance de la qualité
» couvre également le support client.

— Intégration
C’est l’équipe qui nous a accueillis, cette division est responsable de l’implémenta
tion des solutions Axe Finance auprès des clients. Elle est composée de
consultants fonctionnels « métier » en charge du paramétrage et de la
configuration ainsi que de consultants techniques en charge de l’intégration de ces
solutions au sein des systèmes d’information des institutions financières.

— Développement des affaires

Cette division est en charge de l’activité commerciale et marketing notamment de
la prospection et de la promotion d’Axe Finance et de ses produits et services. Elle
comprend également des experts avant-ventes qui interviennent pour renforcer
l’action commerciale en apportant leur support technique et leur savoir-faire métier.

— Gestion des produits

Cette équipe est en charge des spécifications fonctionnelles, elle centralise les de
mandes d’amélioration et de nouvelles fonctions et assure la cohérence globale
des solutions. Via ses solutions et ses prestations de services « Conseil aux
entreprises », Axe Finance permet à ses clients une meilleure gestion de leurs
risques de crédit, en conformité avec les réglementations nationales et
internationales.

1.2.3 Axe Credit Portal « ACP »

Axe Credit Portal se positionne comme solution phare du marché et répond aux
besoins des institutions financières en matière de gestion des risques de crédit, des prêts
couvrant aussi bien la banque de détail que l’entreprise.

5
CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

ACP est une solution flexible et qui permet un déploiement rapide et un retour sur
investissement quasi immédiat. Grâce à ACP Axe Finance a élargi sa présence sur les
mar chés cibles en Afrique, au Moyen-Orient et en Europe.

Parmi les avantages de la mise en place de cette solution :

— Une meilleure évaluation des risques de crédit et une réduction des risques opéra
tionnels liés au traitement des dossiers de crédit.
— Mise à jour rapide des changements touchant les procédures crédit.
— Amélioration de la supervision de tous les processus liés au crédit (durée
 d’exécution, dispatching optimal des tâches, suivi de l’acheminement,etc).
— Réduction du risque opérationnel lié au processus de crédit (numérisation et ratta
chement des documents).
— Optimisation de la fiabilité des processus de prise de décision du crédit et de la
gestion de portefeuille.

Les Modules de ACP sont représenté dans cette figure :

Figure 1.3 – Architecture de la solution « ACP » [1]

— Le module Axe Credit Management : « Gestion des crédits » Ce module rationalise

l’ensemble des processus d’application, d’évaluation, de sous cription et
d’approbation pour tous les types de crédit quel que soit le canal de distribution ou
le type de client. Industrialisation des cycles de vie des crédits et leur gestion
documentaire.

— Le module Axe Collateral Management : « Gestion des garanties » Ce module

traite tous les aspects de la gestion des garanties incluant une multitude de
fonctionnalités avancées pour assurer un contrôle efficace des risques du porte
feuille de prêts de l’institution financière.

6
CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

— Le module Axe Collection : « Gestion des recouvrements » Une solution de collecte

indépendante ou intégrée pour la collecte des données sur les événements et les
pertes et pour la gestion des activités correctives pour les cré dits douteux et non
performants.

— Le module Axe Scoring Rating : « Gestion des notations » La notation du client, sa

distribution et sa validation pour tous les types de clients et types d’actifs.
Application et évaluation comportementale.
Évaluations de crédit et résultats d’évaluation dans le cadre du cycle de vie global
du crédit.

— Le module Axe Provisionning « Gestion des provisions » Application des

règles de calcules des provisions et la rentabilité attendue.

— Le module Axe Portfolio Limit Monitoring : « Gestion des limites » Agréger et

déclarer les expositions de crédit consolidées à l’aide de l’analyse et de la tranche
et des dés par secteur, pays, notation, région ...
 Définir les limites, les seuils d’alerte précoce et gérer les excès avec les alertes,
les messages et les flux de travail correctifs.

— Le module Axe Back Testing « Test »

Le calcule de LGD (la perte en cas de défaut de paiements), la probabilité de
défaut de paiement de client et l’évaluation de la perte encourue en cas de défaut
de la part d’une contrepartie.

— Le module Business Intelligence

D’après le cycle de vie de différents modules d’ACP, Axe Finance a constaté qu’il
y’a un flux énorme d’informations qui n’est pas bien exploité. Ces informations
devront être traitées avec une analyse descriptive pour comprendre l’état actuel ou
passé et une analyse prédictive pour pouvoir anticiper les actions futurs.
Pour répondre à ce besoin et aider l’équipe de pilotage à choisir des décisions
fiables, Axe Finance a décidé de développer ce module pour répondre à toutes les
questions qui sont posées Concernant les garanties, les crédits, etc.

7
CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

1.3 Présentation du projet

1.3.1 Contexte du projet

Le présent projet s’inscrit dans le cadre d’un stage de fin d’études d’une durée de six
mois au sein de l’entreprise "axe finance" en vue d’obtention du diplôme d’ingénierie in
formatique spécialité Business Intelligence.

Notamment, ce stage est en rapport avec notre formation dans le domaine de l’infor
matique Décisionnelle, nous avons travaillé sur un projet générique qui intéresse toutes
les banques en partenariat avec axe finance. Dans le but de réussir ce projet et de faire
l’al liance finance et informatique décisionnelle connue sous le nouveau terme “FinTech”
nous avons adopté le monde « BI » comme solution pour faire face à ce genre de
problématique.

La gestion de recouvrement de crédit est une procédure réglementée qui vise à utiliser
des moyens légaux pour obtenir d’un débiteur le paiement d’une créance. Il existe deux
types d’actions : le recouvrement amiable et le recouvrement judiciaire, et pour notre cas
on s’intéresse plus au recouvrement amiable, tout en sachant que chaque banque a ses
propres procédures pour couvrir ses dettes. Le recouvrement amiable n’est pas codifié,
mais il implique toujours l’ouverture du dialogue avec un conseiller.
 La plupart du temps, cette démarche évite que certains dossiers seront transmis au
service contentieux de la banque ou à l’organisme chargé de procéder au recouvrement.
Ciblant cette nécessité, Axe Finance se situe en phase d’apporter une réponse aux
besoins de ses clients avec un autre esprit d’innovation. Cet esprit vise à implémenter un
système d’information décisionnel dédié au recouvrement de crédit.

1.3.2 Etude de l’existant

Des rapports SSRS Microsoft ont été déjà établis et on a observé qu’ils ne peuvent
pas être utilisable facilement par le personnel de la banque.
Les rapports sont gourmands en ressources à utiliser et ils occupent une grande partie
des ressources du serveur, en particulier lors de l’exécution de rapports volumineux. La
figure ci-dessous montre un exemple de rapport qui permet de consulter quelques in
formations utiles.

8
CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

Figure 1.4 – Exemple d’un rapport SSRS existant[2]

1.3.3 Problématique
Aujourd’hui nous n’avons que des données transactionnelles qui ne peuvent pas
fournir des informations et des connaissances d’aide à la décision. Les rapports existants
fournissent seulement une vue superficielle, nous n’avons pas de traçabilité des données
éparpillées ce qui ne permet pas d’avoir une vue synthétique assurant une prise de
décision fiable. De plus, les statistiques sur des bases de données relationnelles
négligent l’effet sur la performance du système à savoir, le temps que peut prendre une
formule pour être exécutée, la complexité d’une requête opérationnelle pour répondre à
un besoin simple et surtout le taux d’erreur au niveau du résultat renvoyé. En réalité, ces
méthodes sont confrontées à des temps d’analyse de données élevés dû à la masse
importante d’informations en Giga, et parfois des Teras, Les approches traditionnelles de
SSRS s’avèrent donc insuffisantes et coûteuses.
Le décideur a un fort besoin d’un tableau de bord permettant une vision plus claire
durant le processus du crédit (phase, état, statut...), détectant les anomalies pour suivre
l’évolution du crédit tombant recouvrement au fil du temps.
En outre le client a besoin d’une solution qui aide à identifier les indicateurs de perfor
mance et de risque liés à la gestion du recouvrement comme te taux de recouvrement et
les montants impayés, aussi d’analyser la performance de leur agents et les classer selon
leurs efficacité en terme de nombre de dossier et montants recouvrés.
Alors comment pourrions-nous à travers les outils BI mettre en valeur et exploiter le po
tentiel de ces données importantes ?

1.3.4 Solution proposée

L’objectif de ce projet est de créer un système décisionnel permettant de mettre à la
disposition des décideurs les moyens nécessaires pour qu’ils puissent prendre les
décisions stratégiques et opérationnelles les plus adéquates.

9
CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

Notre solution offre aux utilisateurs un gain de temps au niveau de la recherche de

l’information, elle assure un accès fiable aux informations pertinentes et rend possible
l’analyse des données sous différents angles afin de prendre la meilleure décision et
améliorer le processus de recouvrement de crédit.
Le projet comporte un volet d’aide à la décision qui consiste à une démarche BI offrant
des tableaux de bord interactifs.
En effet, grâce à cette solution décisionnelle, les décideurs auront l’occasion de : —
Approfondir la connaissance client (comportement,montant non payé...) afin de maîtriser
leurs risques.
— Superviser la processus de recouvrement de crédit autorisées en temps réel en
dégagent les montants reste à payer et les montants payé par les clients dans l’objectif
d’anticiper des pertes inattendues.
— Visualiser les phases et les strate par clients et déterminer le pourcentages des clients
qui passent à la phase client contentieux et bien sur déterminer les causes.

1.4 Choix de la méthodologie du travail

Le choix de la méthodologie du travail est une partie très importante et assez délicate.
Pour cela nous ferons une études de différentes méthodes et choisir laquelle est plus adé
quate avec notre projet. Parmi les méthodes nous citons la méthode Gimsi qui est centrée
sur la problématique de tableaux de bord et l’approche Ralph Kimball qui s’intéresse à la
modélisation du DWH.
 10
CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

1.4.1 Cycle de vie Ralph Kimball

La figure suivante décrit le cycle de vie d’un projet BI, son avancement ainsi que le
séquencement des différentes tâches.

Figure 1.5 – Diagramme de flux de travail (Kimball)[3]

— Planification du projet : Permet la définition de la portée du projet. Aussi il permet

de apprécier, déterminer et affecter des tâches.

— Définition des besoins : C’est une étape décisif à l’aboutissement du projet. Elle
permet de connaître les besoins du client à travers du document qui se compose
d’une description détaillée des besoins.

— Modélisation des données : identifie les tables des faits et les dimensions.

— Conception physique des données : permet de détailler le schéma relationnel

comme les clés, les types, les contraintes... et perfectionner la performance ( les in
dexes, le partitionnement, l’agrégation,...).

— Conception de l’architecture technique : identifie la vision de la solution et le choix

des technologies .

— Conception et développement du système ETL : identifie et analyse les don nées

sources, les méthodes d’extraction,la transformation bien que la confirmation de la
qualité des données.

— Conception et développement de l’application BI : Elle est en parallèle avec la

conception des données et la modélisation d’architecture. Force l’interaction avec

11
CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

le client.
 — Gestion du projet : c’est l’étape en continue durant la processus de la mé
thodologie de Kimball. Elle assure une coordination des taches du projet, un suivi
d”avancement du projet et des problèmes.

— Déploiement : Assure la formation des personnes qui vont utiliser la solution en

utilisant des supports de documentations.

— Maintenance et croissance : Permet d’améliorer le fonctionnement du système et

assure l’ajout des nouvelles fonctionnalités.

1.4.2 Méthode GIMSI

GIMSI[7] est une méthode de conception de systèmes d’aide à la prise de décision et
d’assistance au pilotage par tableaux de bord. Structurée en 10 étapes successives, elle
est dans un mode de direction moderne qui favorise la coopération des connaissances.
Elle se concentre sur la question : Comment se prennent réellement les décisions sur le
terrain ?

Elle se compose de 4 phases qui sont divisées en 10 étapes :

— Première phase : Identification

Étape 1 : Identification de l’entreprise dans son contexte (marché, stratégie)
Étape 2 : Identification de l’entreprise dans ses structures (métiers, processus)

— Deuxième phase : Conception

Étape 3 et 4 : Choisir les indicateurs pertinentes en fonction de la stratégie et des
processus.
Étape 5 et 6 : Construire les indicateurs et construire les données.
Étape 7 : Construire le système de tableau de bord.

— Troisième phase : Mise en œuvre

Étape 8 : Choisir les progiciels les mieux adaptés à la mesure de la performance
dans l’entreprise.
Étape 9 : Intégrer et déployer le système décisionnel dans l’entreprise.

— Quatrième phase : Amélioration permanente

Étape 10 : Contrôler en permanence d’adéquation entre le système décisionnel et

12

CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

les besoins des décideurs.

1.4.3 Choix de méthode

 Après l’étude les deux méthodes qui peuvent être utilisées pour mettre notre solution
en place nous remarquons qu’aucun d’entre eux n’est à privilégier et le choix de la
meilleure approche dépend de l’activité de l’entreprise ainsi que de ses objectifs à long et
court terme sur le plan décisionnel.
Dans notre cas GIMSI nous offrira une solution plus adaptable aux besoins du client en
fournissant une meilleure organisation de travail. Elle est originale pour la conception d’un
système de pilotage à base de tableaux de bord qui privilège la collaboration entre les
décideurs et l’échange des connaissances.

1.5 Planification prévisionnelle

Pour planifier et bien organiser les tâches de notre projet durant une période bien
définie nous avons exploité le diagramme de Gantt [8] qui est un outil d’ordonnancement
et de gestion de projet qui permet la visualisation des différentes tâches composant un
projet dans le temps.
Les figures 1.6 et 1.7 illustrent la gestion du projet en fonction du temps et les différentes
tâches effectuées.

Figure 1.6 – Planification des tâches

13
CHAPITRE 1. CADRE GÉNÉRAL DU PROJET

Figure 1.7 – Diagramme de Gantt réalisé par Gantt Project

1.6 Conclusion
 Ce chapitre nous a permis de percevoir la problématique concernant notre projet, ceci
en mettant le projet dans un cadre particulier en présentant l’entreprise au sein de
laquelle s’est déroulé le stage. Ce contexte nous a aussi permis d’élaborer notre
méthodologie de travail et de donner un aperçu sur les différentes phases à suivre.

Le chapitre suivant est consacré à la présentation des concepts théoriques de base en

rapport avec l’élaboration de notre solution ainsi que la spécification des besoins.

14

Chapitre 2

Lancement du projet et environnement

2.1 Introduction
Après avoir présenté la problématique et la solution proposée, nous essaierons via ce
chapitre, d’exposer l’état de l’art des différentes notions de l’informatique décisionnelle et
celles du métier bancaire et plus précisément, le recouvrement de crédit. Par la suite,
nous passerons à l’analyse des besoins qui est une phase critique dans la conduite de
notre projet puisqu’elle définit les besoins réels des personnes qui vont exploiter le
résultat final.
2.2 Théorie et enjeux du Business Intelligence

2.2.1 Définition de l’informatique décisionnelle

Un nouveau concept est apparu dans les années 90, c’est l’informatique décisionnelle.
Il connaît un essor considérable grâce au progrès réalisés en technologie de l’information.

Un système d’information décisionnel(SID) est généralement défini comme étant « un

regroupement de données orientées vers certains sujets, intégrées, dépendantes du
temps, non volatiles, ayant pour but d’aider les gestionnaires dans leurs prises de
décision » [In mon, 1996].

En effet, les SIDs sont des systèmes d’information de gestion orientés vers la
production de tableaux de bords et d’outils de pilotage. Ces systèmes visent à faciliter la
prise de décision au sein d’une organisation. [9]

15
CHAPITRE 2. LANCEMENT DU PROJET ET ENVIRONNEMENT

2.2.2 Objectifs de l’informatique décisionnelle

Malgré la diversité des domaines d’activités des entreprises, ces derniers réfugient à
un système décisionnel avec des raisons communes. En fait l’informatique décisionnelle a
plusieurs missions :

— Facilité et rapidité de l’accès aux informations.

— Cohérence des informations : Données crédibles et de bonne qualités. —
Adaptation aux changements : lorsque les besoins ou la technologie changent, les
données aussi doivent être changées et ce en tenant au courant tous les utilisateurs
du système.
— Conversion de la grande masse de données en une valeur métier : à partir des
outils d’analyse, le système doit permettre de dégager une valeur qui va aider dans
la prise des décisions. [10]

2.2.3 Architecture d’un système décisionnel

Le système décisionnel doit être constitué de quatre couches : ETL, entrepôt de
données, le cube OLAP et les outils de restitution.
 Figure 2.1 – Architecture d’un système décisionnel [4]

16
CHAPITRE 2. LANCEMENT DU PROJET ET ENVIRONNEMENT

L’architecture détaillée d’un système décisionnel, comme indiquée dans la figure

précé dente est composée des éléments suivants :

— Les sources de données : sont distribuées, variées et hétérogènes. Elles peuvent

être internes ou externes à l’organisme.

— Le processus ETL : permet le nettoyage, l’intégration et le chargement pério diques

de toutes les données au sein du data warehouse nécessaires pour l’analyse.

— L’entrepôt de données (data warehouse) : est l’endroit de stockage centra lisé, il

contient des informations orientées métier. Une fois ces informations hébergées
dans le data warehouse, on va pouvoir créer des magasins de données nommés :
datamarts.

— Les magasins de données (data marts) : sont des extraits de l’entrepôt de données.
Les données sont organisées de manière adéquate pour permettre des ana lyses
rapides à des fins de prise de décision.

— Le cube OLAP : permet d’accéder rapidement et interactivement à des données

stockées via une large variété de vues possible d’informations.

— Les outils de visualisation de données : permettent de visualiser les données selon

des axes d’analyses. L’information est visualisée via des interfaces interactives et
fonctionnelles dédiées à des décideurs souvent non informaticiens.
2.3 Gestion de recouvrement de crédit

2.3.1 Le processus de scoring d’octroi des crédits aux clients

Les clients de la banque font appel à des dettes pour plusieurs raisons comme l’achat
d’un logement, d’un véhicule ou des travaux de rénovation, Ils sont de plus en plus nom
breux ces dernières années. L’analyse des risques représentés par le crédit présente un
élément primordial pour la banque.En Outre les garanties indispensables pour l’octroi du
crédit, la banque dispose également d’un outil servant à statuer sur la fiabilité de l’emprun
teur et sa solvabilité en fonction d’une certaine méthode statistique. Celle-ci est basée sur
l’étude d’un échantillon de consommateurs selon chaque type de crédit ainsi que l’histo
rique de défaillance de centaines de profils. Les cas de non-remboursement les plus
fréquents recueillis seront déterminants dans les scores d’octroi.

17
CHAPITRE 2. LANCEMENT DU PROJET ET ENVIRONNEMENT

2.3.2 Le recouvrement de crédit

Le recouvrement de créances est l’essaie d’un débiteur de récupérer le crédit et les

prêts qui n’ont pas été remboursés par un client.
Le recouvrement de créances se produit lorsqu’un prêt, tel qu’un solde de carte de crédit,
continue de rester impayé et qu’un créancier engage un tiers, connu sous le nom de ser
vice de recouvrement, pour se concentrer sur la collecte de l’argent. Ce service peut être
interne généralement composé de juristes et/ou de salariés formés aux procédures
d’exécu tion comme une certaine psychologie, ainsi qu’une posture réactive, est attendue
de leur part et la voie amiable est souvent privilégiée, ou bien un service externe comme
certaines entreprises sont spécialisées dans le recouvrement de créances pour le compte
d’organismes et Leurs intervenants seront d’autant plus incisifs qu’ils ont une obligation
de résultat, et touchent même parfois même un pourcentage de rémunération si
l’opération réussit.
Ils existent des différentes étapes dans le processus de recouvrement de créances et il
est important, de bien maîtriser l’art de négociation lors d’un échange avec un mauvais
payeur. Étant donné que le crédit peut être une situation très délicate, un ensemble des
lois a été établie pour guider le processus de recouvrement du crédit et assurer que les
consomma teurs soient protégés contre les pratiques de recouvrement de la dette.

2.4 Définition des besoins BI

2.4.1 Besoins fonctionnels et métiers

Les besoins fonctionnels représentent ce que la solution offre comme services à l’utili
sateur.
Les besoins que notre solution doit satisfaire sont :

— Le traitement d’une grande quantité des données.

— L’extraction des données depuis la base de données ACP pour alimenter l’ODS.
— Le chargement de l’ODS contenant les deux data marts.
— La conception et la mise en place d’un Entrepôt de Données pour regrouper et
gérer les informations pertinentes qui concernent le recouvrement du crédit du
client et l’évolution du crédit.
— La restitution des données et l’élaboration des tableaux de bord et des rapports.

18

CHAPITRE 2. LANCEMENT DU PROJET ET ENVIRONNEMENT

2.4.2 Besoins non fonctionnels

En plus des besoins cités précédemment, le système à mettre en place devrait être ca
pable d’assurer des contraintes supplémentaires qui sont :

— Générique : Notre solution doit être générique et capable de tourner avec n’importe
quel besoin.
— La sécurité : permet la confidentialité des données stockées
— La fiabilité et l’intégrité des données existantes : garantir la stabilité du système
d’aide à la décision ainsi que la qualité du contenu et la pertinence des informations.
— Le temps de réponse : rapidité dans le traitement des données ce qui permet un
gain de temps.

2.5 La modélisation des données

Tout DWH doit être en mesure de répondre aux attentes des utilisateurs. Cela ne
peut, évidemment, se faire sans une étude approfondie de leurs besoins. Nous allons
donc réaliser une étude afin de choisir la méthodologie convenable pour notre solution.
En effet les deux démarches les plus connues pour la réalisation d’un s ystème d’aide à la
décision sont la méthode de Bill Inmon (Approche Ascendante) et celle de Ralph Kimball
(Approche descendante).

L’approche d’Inmon

Cette méthodologie de conception est basée sur la construction de l’entrepôt de

données qui suit l’approche descendante. La philosophie d’Inmon, commence par la
construction d’un grand entrepôt de données centralisé d’entreprise stockant l’information
au niveau le plus détaillé. Ensuite la création des Datamarts modélisés sous forme de
schémas en étoile à partir de ce Data Warehouse.
 Figure 2.2 – L’approche de l’inmon [5]

Cette méthodologie définit l’entrepôt de données en ces termes

19
CHAPITRE 2. LANCEMENT DU PROJET ET ENVIRONNEMENT

— Orienté sujet : Les données dans un DWH sont groupées sur la base du domaine
et donc elles sont "orientées sujet".
— Intégré : Les données sont intégrées à partir de différentes sources de données
dispa rates et donc de conventions de dénomination universelles, de mesures, de
classifi cations, etc. utilisées dans l’entrepôt de données. L’entrepôt de données
fournit une vue consolidée des données de l’entreprise et est donc désigné comme
une solution intégrée.
— Non volatile : Une fois les données intégrées chargées dans l’entrepôt de données,
elles ne peuvent être lues. Les utilisateurs ne peuvent pas modifier les données et
cette pratique rend les données non volatiles.
— Variante temporelle : Enfin, les données sont stockées pendant de longues
périodes de temps quantifiées en années et ont une date et un horodatage et sont
donc décrites comme «variantes temporelles».

L’approche de Kimball

Cette approche est appelée modélisation dimensionnelle ou méthodologie Kimball et

elle affirme qu’un Data Warehouse doit être rapide et compréhensible. Les data marts
sont d’abord créés pour fournir des capacités de génération de rapports et d’analyse pour
des processus métier / fonctionnels spécifiques, puis ces datamarts peuvent
éventuellement être réunis pour créer un entrepôt de données d’entreprise complet.

Figure 2.3 – L’approche de Kimball [5]

Étude comparative entre Inmon et KimBall

Dans notre cas, la solution la plus adéquate avec nos besoins sera fourni par la mé
thodologie de Ralph KIMBALL. Elle garantie une meilleure organisation de travail, elle
assure un gain de temps et garantie un coût de travail moins coûteux et aussi elle permet
de répondre aux différents besoins d’une façon optimale en ce qui concerne l’intégration
de données.

20
CHAPITRE 2. LANCEMENT DU PROJET ET ENVIRONNEMENT
Inmon Kimball

Approche Top-Down : Commence par la Buttom-Up : Commence par la

conception du modèle du Data conception du modèle
warehouse dimension nel pour les
Datamart
.

Construction Coûteux en temps Rapide

Durée mise Long Long

en œuvre

Coût Coût initial élevé Coût initial modéré

Maintenance Facile Difficile redondance à gérer

Table 2.1 – Etude comparative entre Inmon et KimBall

2.5.1 Modèles d’entrepôt de données

Il existe plusieurs types de modèles d’entrepôt de données qui sont :
— Modèle en étoile : composé d’une table de fait centrale et plusieurs dimensions dé
normalisées. Chaque table de fait correspond à un fait conceptuel et inclut une clé
primaire, des clés étrangères associées à des dimensions et une colonne pour
chaque mesure du fait.

La modélisation en étoile est plus facile à apprendre et à former, avec un minimum

de jointures et de requêtes simplifiées mais elle présente quelques problèmes
comme la redondance aussi l’intégrité des données.
 21
CHAPITRE 2. LANCEMENT DU PROJET ET ENVIRONNEMENT

Ce modèle est décrit dans la figure 2.4.

Figure 2.4 – Schéma d’un modèle en étoile

— Modèle flocon en neige :c’est la normalisation du version du schéma en étoile. Il est

constitué d’une table de fait entourée par les dimensions, qui sont répartie en sous
hiérarchies (chaque niveau est représenté dans une table différente).

La figure suivante représente le schéma en flocon.

22
CHAPITRE 2. LANCEMENT DU PROJET ET ENVIRONNEMENT
 Figure 2.5 – Schéma du modèle en flocon

— Modèle en constellation : Différents modèles en étoile partagent entre eux les

mêmes dimensions. En effet, un modèle en constellation comprend plusieurs
tables de faits et des dimensions communes ou non.

Choix du modèle

Dans notre projet , on a un modèle de donnée qui nécessite plusieurs tables de faits
et qui utilisent entre eux des dimensions communes, pour les systèmes complexes,
évidemment, comme le nôtre, nous avons besoin de constellations de faits.

23
CHAPITRE 2. LANCEMENT DU PROJET ET ENVIRONNEMENT 2.6

Environnement technique du travail

 Avant de commencer la partie réalisation de notre projet, nous avons effectué des
études comparatives pour les différents outils ETL et restitution afin de choisir les outils
les plus adaptés à notre besoin.

2.6.1 Etude des outils BI présents sur le marché

Nous commençons par définir les principaux outils de reporting présents sur le
marché pour les comparer et opter lequel est plus adéquat à la réalisation de notre projet.
Nous optons de comparer les outils qui sont classés comme Leaders dans le quadrant
ma gique de Gartner réalisé en 2019 et 2020 [6]
La visualisation proposée repose sur l’analyse des consultants du cabinet et sur une
enquête annuelle. Le graphe donne, pour l’axe des abscisses, le critère « complétude de
la vision » et « capacité d’exécution » en ordonnée.

LES CRITERES DE CLASSIFICATION DE GARTNER

les leaders : Exécutent bien par rapport à leur vision actuelle et sont bien positionnés
pour le futur.
les challengers : exécutent bien aujourd’hui ou peuvent dominer un grand segment, mais
ne démontrent pas une compréhension de l’orientation du marché.
les acteurs de niche : Les acteurs de niche se concentrent avec succès sur un petit
segment, sont non focalisés ou n’innovent pas pour surpasser les autres. les
visionnaires : Les visionnaires comprennent où le marché va ou ont une vision pour
changer les règles du marché, mais ne sont pas encore capable d’exécuter leur vision.

24
CHAPITRE 2. LANCEMENT DU PROJET ET ENVIRONNEMENT
 Figure 2.6 – Quadrant magique de Gartner[6]

Nous remarquons que le fournisseur Microsoft progresse à un rythme que ses

principaux concurrents ont du mal à égaler et il reste le ’Leader’ sur le marché. Ci-joint un
tableau comparatif des différents fournisseurs.
Points forts Points faibles

IBM Contrôle administratif en libre Mauvaise performance

service. Difficulté d’utilisation
Supporter de grands déploie
ments.

Tableau Manipulation rapide et facile Formation/consulting indispen

Connexion à diverse de sable pour les analyses les
données. plus complexes.

Qlik Création en libre-service Pas de stratégie claire pour

Chargement rapide des l’ave nir
données Difficulté d’usage et technicité

Microsoft Intégration infrastructure Micro Dépendance à une

soft simplissime infrastructure Microsoft
Communauté en croissance Complexité dans l’utilisation
Traitement rapide et securisé
des données

Table 2.2 – étude comparative des outils BI

25
CHAPITRE 2. LANCEMENT DU PROJET ET ENVIRONNEMENT
 Jusqu’à présent Microsoft est le premier à proposer un ensemble compétitif et en ex
pansion d’outil BI et d’analyse, c’est pourquoi Axe Finance l’a choisi pour la réalisation du
process BI.

L’entreprise a choisi les logiciels sur lesquels se base notre projet :

Microsoft SQL Server : pour la gestion de base de données.

SSIS : pour le processus ETL.
SSAS : pour l’analyse des données.
Power BI : pour la restitution des données.

2.6.2 Nos choix technologiques dans notre projet

Microsoft SQL Server

2.6.3 SQL Server 2017

Figure 2.7 – Logo du SQL Server

SSMS est une application utilisée pour configurer, gérer et administrer tous les compo
sants dans Microsoft SQL Server. L’outil comprend à la fois des éditeurs de scripts et des
outils graphiques.

Suite Microsoft (SSIS et SSAS)

26
CHAPITRE 2. LANCEMENT DU PROJET ET ENVIRONNEMENT SSIS
 Figure 2.8 – Logo du SSIS

SSIS est un ETL permettant de se connecter à toute sorte de source de données. Il

permet d’extraire des données, de les transformer en données exploitables par les outils
d’analyse qui elles-mêmes vont alimenter une ou plusieurs bases de données dédiées
(bases de données relationnelles ou multidimensionnelles).
SSAS

Figure 2.9 – Logo du SSAS

SSAS est une plate forme de stockage et de restitution de données qui fait partie de la
suite décisionnelle MSBI.

Les avantages de SSAS sont les suivants :

— Une simple couche sémantique mis en place.

— Une performance élevée et accès évident aux données.
— Outil de développement complètement intégré dans Visual Studio.

Outils de restitution

• Etude comparative entre SSRS et Power BI

Comme nous avons décidé de travailler avec la suite msbi pour l’intégration et l’analyse,

27

CHAPITRE 2. LANCEMENT DU PROJET ET ENVIRONNEMENT

c’est logique de choisir SSRS pour la phase de restitution. Alors la question qui se pose
est pourquoi le choix de power bi. Donc nous avons élaboré une étude comparative entre
les outils de reporting disponibles pour réussir à choisir l’outils la plus adéquate avec
notre projet.
La table 2.3 présente une Étude comparative entre SSRS et Power BI :
Power BI SSRS

Implémentation Serveur et Serveur

 Cloud .

Accessibilité Via web, mobile, Desktop Via web et desktop

Evolutivité coût initial élevé basé sur une technologie

ancienne

Conviviale facile à utiliser, riche en compo moins convivial

sants graphique

Adaptabilité Supporte données structuré et supporte données structurées

non structurés et semi structurées

Table 2.3 – Etude comparative entre SSRS et Power BI

2.6.4 Outils de collaboration

Afin de pouvoir collaborer avec les autres membres de l’équipe et intégrer notre solu
tion avec les siennes, nous avons utilisé un portail collaboratif nommé Teams. Microsoft
Teams est un logiciel de collaboration d’équipe basé sur le Cloud qui fait partie de la suite
d’applications Office 365. Les principales fonctionnalités de Microsoft Teams incluent la
messagerie d’entreprise, les appels, les visioconférences et le partage de fichiers. Les
entreprises de toutes tailles peuvent utiliser des équipes.

2.7 Conclusion
Ce chapitre a été consacré à la définition du BI et la spécification des besoins fonction
nels et non fonctionnels pour mieux identifier les objectifs attendus de notre solution, et
d’autre part il nous a permis de définir la vision d’ensemble de la solution et des techno
logies du projet et d’identifier les besoins techniques pour que nous puissions passer à la
partie de préparation des données dans le chapitre qui suit.

28

Chapitre 3

CONCEPTION & MODÉLISATION

3.1 Introduction
Après avoir distingué et énuméré les besoins, nous abordons la phase de conception
et de modélisation. Nous présentons dans cette rubrique l’architecture du système ainsi
que le modèle de données conçu.

3.2 Architecture
Notre solution parcourt toute la chaîne décisionnelle, depuis l’extraction des données
jusqu’au le déploiement des états.

3.2.1 Architecture fonctionnelle du système

L’architecture fonctionnelle de notre système peut être représentée comme suite :

— Collecte des données source depuis ACP.

— Extraire, transformer et charger les données collectées dans un entrepôt de
données afin de capter les informations servant à la prise de décision.
— L’entrepôt de données chargé est composé de deux Data Marts.
— Assurer la restitution des différentes données et déterminer la manière avec
laquelle les tableaux de bord seront présentés à l’utilisateur final en fonction de ses
besoins.

29
CHAPITRE 3. CONCEPTION & MODÉLISATION

La figure 3.1 décrit l’architecture globale de notre système.

 Figure 3.1 – Architecture fonctionnelle

3.2.2 Architecture logique des données

Quatre zones logiques de données sont définies et leur organisation est décrite dans
le schéma ci-dessous.

Figure 3.2 – Architecture logique des données

30
CHAPITRE 3. CONCEPTION & MODÉLISATION

— Sources de données : les sources de données représentent tous les systèmes ex

ternes et qui leurs fournissent des données brutes.

— STG : sont les données et méta-données techniques (et temporaires) nécessaires

aux traitements des données.

— Data warehouse : c’est la zone de stockage principale. Les données consolidées y

sont stockées.

— Data marts : Permet de stocker des informations dérivées du DWH et faites pour
 des besoins bien précis.

3.3 Identification des indicateurs

les KPI et les KRI sont des facteurs mesurables qui permettent l’évaluation des per
formances et du niveau de risque d’une banque. En d’autres termes, les KPI et les KRI
permettent à la banque de savoir si elle est sur la bonne voie.

31
CHAPITRE 3. CONCEPTION & MODÉLISATION

Voici quelques principaux KPI & KRI à surveiller en continu :

Indicateur Description

Nombre de client Fournit une vue globale et détaillée sur la

réparti tion des clients.

collection effectiveness L’Efficacité et la productivité de chaque

index CEI collection neurs de la banque.

Montant promis Le montant total de l’engagement de paiement

ef fectué par les client.

Montant Payé le montant total du paiement perçu.

Montant impayé Le total des montants impayés et qui ont

 dépassé la date d’échéance.

Taux de recouvrement Le degré d’endettement bancaire.

Table 3.1 – KPI & KRI

3.4 Conception de l’entrepôt de données

Nous présenterons dans ce qui suit la description des données source et le modèle physique de notre
entrepôt de données.

3.4.1 Description des données source

Vu que la base de données source ressemble un volume énorme de données et des tables qui ne
sont pas utiles pour le chargement des datamarts « recouvrement de crédit » et « garantie», nous
avons procédé à choisir ceux qui sont nécessaires.
Dans ce qui suit une petite description sur les tables utilisées de la base de données source. 32

CHAPITRE 3. CONCEPTION & MODÉLISATION

Nom de la Table Description

counterparty Contient des informations concernant les clients.

counterparty_type Contient les types de clients (particulier, institu

tion financière, entreprise, etc ).

counterparty_address Contient l’adresse de chaque client.

counterparty_category Contient les catégories de clients ( publique,

privé, etc ).

counterparty_classification Contient les classifications des clients tels que

(santé, éducation, IT, agriculture, etc ).

country Contient des informations relatives aux pays.

country_region Contient des informations relatives aux régions.

economic_sector Contient les secteurs économiques.

industry_sector Contient les secteurs industriels.

internal_entity Contient des informations relatives aux agences.

internal_segment Contient les segmentation interne de la banque.

transaction_type Contient les types de crédit (immobilier,

personnel, etc )

transaction Contient les détails des transactions.

transaction_credit_event Contient les transactions impayés .

Status Contient Les différents statuts possibles pour le

métier .

Recovery_type Contient les différents actions possibles suite à

une transaction impayé

Recovery_action_fate Contient les différents sorts qui correspondants

aux actions faites

Recovery_arrangment_action Contient l’etat des promesses de payement

ainsi que les montants .

33
CHAPITRE 3. CONCEPTION & MODÉLISATION
Recovery_credit_event Contient la liaison entre chaque credit event et
ses détails de recouvrement.

Recovery_type_category

Transaction_recovery Contient la liaison de chaque action et sort avec

le client concerné .

Transaction_add_data Contient la liaison entre chaque credit event et

ses détails de recouvrement.

Payment

Payment_posting Contient les paiements associés à leurs tran

sactions impayés(table de liaison entre transac
tion_credit_event et payment)

Software_user Contient les informations sur les agents de

dispat ching.

Group Contient les différents groupes chargé du

recouvre ment de crédit.

User_group Contient la liaison de chaque utilisateur avec

son groupe.
 wf_task_dispatch CContient le workflow du dispatching,tout en
men tionnant à chaque workflow l’agent et le
groupe chargé de chaque client

Mitigant Contient des informations générales sur le

garantit .

Mitigant_valuation Contient la valeur des garanties

Collateral_type Contient les types des garanties .

Constant_matrix Contient la liste des workflow des cas

amiables , contentieux, tribunaux et avocats..

Report_prepare_tier_phase Contient la phase et le strate de chaque client.

Credit_event_type Contient les raisons de la créance impayée.

Table 3.2 – Tableau descriptif des données source

34
CHAPITRE 3. CONCEPTION & MODÉLISATION

3.4.2 Identification des tables dimensions

Notre projet comporte plusieurs dimensions dont chacune représente un axe
d’analyse et qui une fois croisées avec les mesures donnent aux décideurs des
renseignements néces saires à la prise de décision.

Ci dessous le tableau descriptif qui présente les dimensions de notre modèle de données.
Dimension Attributs Description
Dim_client ID_Dim_Client Cette dimension
Code_Client contient toutes les
Nom_Client informations relatives
Date_Inscription aux clients.
Identifiant_Client
Date_Naissance
Etat_Civil
Profil_Client
InsetDate
UpdateDate

Dim_Type_Client BRANCH_DC_ID cette dimension corres

ID_Dim_Type_Client pond aux différents
CodeTypeClient types de clients.
NomTypeClient
InsertDate
UpdateDate

Dim_Categorie_Client Cette dimension

ID_Dim_Categorie_Client contient les catégories
Code_CategorieClient des clients.
Nom_CategorieClient
InsertDate
UpdateDate

Dim_segment_client ID_Dim_SegmentClient cette dimension

CodeSegmentClient contient les
VomSegmentClient segmentations des
InsertDate clients.
UpdateDate

35
CHAPITRE 3. CONCEPTION & MODÉLISATION
DimRegion ID_DimRegion cette dimension
Region_Code contient les adresses
address des clients.
zip_code
Region
InsertDate
UpdateDate

Dim_Profession ID_Dim_Profession Cette dimension

CodeProfession corres pond aux
NomProfession differents sec teurs de
InsertDate l’industrie des clients.
UpdateDate
Dim_Secteur ID_Dim_SecteurEconomique cette dimension corres
Economique CodeSecteurEconomique pond aux secteurs
NomSecteurEconomique écono miques des
InsertDate clients.
UpdateDate

Dim_SegmentClient ID_Dim_SegmentClient cette dimension corres

CodeSegmentClient pond aux différentes
VomSegmentClient clas sifications des
InsertDate clients.
UpdateDate

36
CHAPITRE 3. CONCEPTION & MODÉLISATION
Dim_Pays ID_Dim_Pays cette dimension corres
CodePays pond aux pays des
NomPays clients (entreprise).
InsertDate
UpdateDate

Dim_Manager ID_Dim_Manager Cette dimension

CodeAgent contient toutes les
NomAgent informations relatives
email managers des
isactive groupes.
InsertDate
UpdateDate

Dim_Agent ID_Dim_Agent Cette dimension

CodeAgent contient toutes les
NomAgent informations relatives
email aux agents qui
isactive travaillent dans la
InsertDate banque.
UpdateDate

Dim_Group ID_Dim_Group Cette dimension

Code_Group corres pond aux
Nom_Group informations groupes
insertDate client.
UpdateDate

37
 CHAPITRE 3. CONCEPTION & MODÉLISATION
Dim_Agence ID_Dim_Agence Cette dimension
Code_Agence contient la liste des
Nom_Agence agences du banque.
InsertDate
UpdateDate

Dim_Action ID_Dim_Action Contient les différents

CodeAction ac tions possibles
NomAction suite à une transaction
DescriptionAction impayé.
InsertDate
UpdateDate

Dim_Sort ID_Dim_Sort Contient les différents

CodeSort sorts qui
NomSort correspondants aux
InsertDate actions faites.
UpdateDate

Dim_Status ID_Dim_Status Contient les différents

CodeStatus statut possibles pour
NomStatus les phases, strates,
InsertDate promesses et garantie.
UpdateDate

38
CHAPITRE 3. CONCEPTION & MODÉLISATION
Dim_Time DateID Cette dimension
MonthName corres pond à l’axe
MonthNumber temporel.
DayNumber
DayName
Quarter
QuarterName
Year
FullDate

DimTypeAffaire ID_DimTypeAffaire Cette dimension

CodeT ypeAff air corres pond aux
nomT ypeAff aire segments in ternes.
catgorieT ypeAff aire
InsertDate
UpdateDate
Dim_Type_ ID_Dim_TypeRecouvrement Cette dimension
Recouvrement CodeT ypeRecouvrement corres pond aux types
DescT ypeRecouvrement de recou vrement.
InsertDate
UpdateDate

Dim_Cabinet_ ID_Dim_Cabinet_Restitution Cette dimension

Restitution Constant_matrix_id corres pond aux
CodeCabinetRestitution cabinets de res titution
NomCabinetRestitution des garanties.
InsertDate
UpdateDate

39
CHAPITRE 3. CONCEPTION & MODÉLISATION
Dim_Model_Garantie ID_Dim_Model_Garantie Cette dimension
Constant_matrix_id corres pond aux
CodeMode modèles des ga
NomModel ranties.
InsertDate
UpdateDate

Dim_Marque_ ID_Dim_Marque_Garantie Cette dimension

Garantie Constant_matrixid corres pond aux
CodeM arque marques des
NomM arque garanties..
InsertDate
UpdateDate

Table 3.3 – Description des dimensions

 40
CHAPITRE 3. CONCEPTION & MODÉLISATION

3.4.3 Vue d’ensemble de la conception de l’entrepôt

Notre modèle de l’entrepôt de données complet est un modèle en constellation
construit à partir des modèles en étoile et en constellation et il est présenté dans la figure
suivante. Notre entrepôt de données est composé de deux data marts intitulés «
Recouvrement » et «Garantie ».

41
CHAPITRE 3. CONCEPTION & MODÉLISATION
 Figure 3.3 – Modèle de données

42
CHAPITRE 3. CONCEPTION & MODÉLISATION

Notre entrepôt de données est composé de deux data marts intitulés « Recouvrement
» et «Garantie ».

Data mart « Recouvrement» La figure suivante représente le modèle en constellation qui

permet l’analyse du recouvrement.
 Figure 3.4 – Data mart « Recouvrement »

43
CHAPITRE 3. CONCEPTION & MODÉLISATION

Data mart « Garantie » Le modèle en étoile qui permet l’analyse du garantie, est décrit
dans la figure ci-dessous.
 Figure 3.5 – Data mart « Garantie »

44
CHAPITRE 3. CONCEPTION & MODÉLISATION

3.5 Conclusion
Dans ce chapitre nous avons exposé l’architecture fonctionnelle de notre système
ainsi que l’architecture logique des données. Nous avons également présenté le modèle
de données relatif au data warehouse issues de ACP selon notre besoin et nous avons
décrit en détail chaque dimension qui le compose. Les différentes phases de réalisation
seront détaillées dans le chapitre qui suit.
 45

Chapitre 4

MISE EN OEUVRE

4.1 Introduction
Ce chapitre est consacré à la présentation du travail réalisé. D’abord nous allons com
mencer par présenter quelques aperçus sur les étapes réalisées pour le chargement et la
construction du DWH et des cubes.. Ensuite, nous allons présenter l’exploitation de ce
dernier sous forme de tableau de bord.

4.2 Implémentation
Après avoir terminé la conception de notre module et définis notre environnement de
développement, nous passons à l’implémentation de notre module BI passant par la
préparation des données sources tout en détaillant les différentes phases.

4.2.1 Phase d’alimentation (ETL)

Étape 1 : Extraction

Durant cette étape, nous extrayons les données depuis la base de données source
ACP. En effet, le staging area est une copie de notre base de données opérationnelle et
un moyen de les protéger. Cette zone sera utilisée en tant que source pour alimenter
notre data warehouse. Nous créons un package SSIS qui permet le chargement de
données dans le staging area où nous utilisons des composants SSIS :
Execute SQL Task : Ce composant permet l’exécution des requêtes SQL. Dans notre
package, nous l’avons utilisé pour tronquer toutes les tables avant de charger les
données dans le staging area. Cela signifie que les données doivent être supprimé du le
staging area

46
CHAPITRE 4. MISE EN OEUVRE

afin d’éviter la duplication ces dernières lors de l’extraction des sources et du chargement
dans les tables.
Data Flow Task : Toutes les données sont extraites des sources et chargées dans staging
area à l’aide de ce composant. En fait, chaque table est représentée par un Data Flow
Task qui contient un composant OLE DB SOURCE utilisé pour extraire les données de la
table source et un composant OLE DB DESTINATION utilisé pour charger les données
dans la table staging. Les figures suivantes montrent l’exécution du package SSIS
La figure 4.1 présente le design du chargement du STG.
 Figure 4.1 – Chargement du STG

Etape 2 : Transformation

Pour alimenter notre base de données temporaire ODS, nous avons récupéré d’abord
les données, dont nous aurons besoin, à partir des tables insérées au niveau STG et puis
nous allons effectuer toutes les modifications et les traitements nécessaires.

La transformation garantie la qualité des données et leur accessibilité qui doit tenir
compte des pratiques suivantes :

47
CHAPITRE 4. MISE EN OEUVRE

La Recherche Floue :
La transformation de recherche floue est utilisée pour remplacer les mots mal saisis par
des mots corrects. Elle utilise la correspondance floue pour rechercher une ou plusieurs
correspondances proches dans la table de référence et remplacer les données source par
des données de référence.
La figure ci-dessous représente l’implémentation d’un exemple de la recherche floue pour
la table Région_ODS :

La figure ci-dessous représente l’implémentation d’un exemple du formatage des

 dates :

Figure 4.2 – Standarisation des régions

Nous avons remarqué que la table counterparty_addres contient beaucoup de fautes

d’orthographes dans le saisie des régions des clients à cause de ces mots mal saisis,
nous ne pouvons pas faire correspondre les données source avec la table de recherche.
Donc la recherche floue recherchera dans la table référence country_region le mot le plus
proche et remplacera la mauvaise valeur par le mot correct.
La figure suivante illustre un exemple de déduplication :

48
CHAPITRE 4. MISE EN OEUVRE

L’historisation :
Pour un besoin métier nous avons choisi de garder l’historique de changement de toutes
les données dans l’ODS puis les charger dans le DWH. Comme le cas de la table
Client_ODS Présentée dans la figure ci-dessous : Dans ce cas la jointure était : Full Outer
Join car nous
 Figure 4.3 – Chargement de la table Client_ODS

allons deux cas possibles :

• Insertion : Lorsqu’il s’agit d’un nouveaux client.
• Historisation : Dans ce cas le client se trouve dans l’ODS mais l’un de ses attributs dont
nous avons besoin de garder la trace a été mis à jour. Alors nous ajoutons une nouvelle
ligne avec ce nouveau client avec la nouvelle date d’insertion (InsertDate)et nous gardons
l’autre enregistrement tout en changeant sa date de mise à jour(UpdateDate).

Étape 3 : Chargement

Le chargement des données constitue la troisième et dernière étape du processus

ETL. Cette étape consiste à charger les données extraites et transformées dans leur
nouvel em placement, le DWH.

- Chargement des dimensions :

49
CHAPITRE 4. MISE EN OEUVRE

La figure suivante montre le chargement des dimensions dans le DWH à travers SSIS :
 Figure 4.4 – Chargement des dimensions

50
CHAPITRE 4. MISE EN OEUVRE

- Chargement de la table de fait « Recouvrement » :

Pour charge la table de fait « Recouvrement » nous devons passer par deux étapes : -
Préparer la source de données à travers d’une procédure stockées qui représente une
join ture entre toutes les tables, ainsi que les mesures extraites telle qu’elles sont dans la
base source.
-Appliquer la technique ETL pour compléter le chargement de la table.
 Figure 4.5 – Chargement « FACT_Recouvrement »

51
CHAPITRE 4. MISE EN OEUVRE

- Chargement de la table de fait « Affaire» :

Pour charge la table de fait « Affaire » nous devons passer par deux étapes : -
Préparer la source de données à travers d’une procédure stockées qui représente une
join ture entre toutes les tables, ainsi que les mesures extraites telle qu’elles sont dans la
base source.
-Appliquer la technique ETL pour compléter le chargement de la table.
 Figure 4.6 – Chargement « FACT_Affaire »

52
CHAPITRE 4. MISE EN OEUVRE

- Chargement de la table de fait « Garantie» :

Pour charge la table de fait « Garantie » nous devons passer par deux étapes : -
Préparer la source de données à travers d’une procédure stockées qui représente une
join ture entre toutes les tables, ainsi que les mesures extraites telle qu’elles sont dans la
base source. -Appliquer la technique ETL pour compléter le chargement de la table.
 Figure 4.7 – Chargement « FACT_Garantie »

53
CHAPITRE 4. MISE EN OEUVRE

4.2.2 Phase d’analyse :

Cette phase est consacrée à l’analyse en utilisant SSAS, nous avons créé des
partitions et des mesures qui seront exploitées par la suite dans la phase de restitution
des données. Une foi que notre DWH est alimenté, nous avons sélectionné les ta
dimensions et les tables de fait sur lesquelles se baserons chaque cube pour faire les
analyses tout dépend du métier pour lequel les cubes serons destinés.
Pour notre projet nous avons conçu et implémenté les deux cubes multidimensionnels
«Recouvrement » et « Garantie ».
Nous avons choisi le cube multidimensionnel pour garantir une performance de requêtes
rapide par rapport aux données dimensionnelles.
Ce modèle peut prendre en charge des constructions de requêtes complexes pour
accélérer les temps de réponse et alimenter une seule source pour les rapports. Parmi les
autres avantages que nous pouvons citer, le cube multidimensionnel garantie l’intégration
avec les outils de visualisation de données souvent utilisées tels que PowerBI, Excel.
Cube « Recouvrement» :
La figure 4.8 présente le modèle du cube « Recouvrement »..

54
CHAPITRE 4. MISE EN OEUVRE
 55

Figure 4.8 – Cube « Recouvrement »

CHAPITRE 4. MISE EN OEUVRE

Cube « Garantie » :

La figure 4.9 présente le modèle du cube « Garantie ».

 Figure 4.9 – Cube « Garantie »

4.2.3 Phase de restitution de données

La visualisation de données est un outil puissant qui permet d’analyser, qualifier et
présenter un vaste ensemble de données de manière attrayante et facile à comprendre.
Cela

56
CHAPITRE 4. MISE EN OEUVRE

indique que la visualisation des données est devenue essentielle.

Dans la partie suivante nous présentons Les tableaux de bords générés avec Power
BI. Page d’accueil :

Nous avons réalisé une page d’accueil pour garantir une utilisation facile de notre rap
port. Elle fournit une vision totale sur les tout rapports disponibles dans notre solution.
Cette page contient des boutons qui vont nous diriger vers la page demandé. :
 Figure 4.10 – Tableau de bord « Page d’accueil »

57
CHAPITRE 4. MISE EN OEUVRE

Tableau de bord «tableau de bord global» :

Ce tableau de bord représente des informations générales sur le recouvrement et sa

répartition selon différents axes tels que :

— Période.
— Agent/groupe.
— Client.
— Type Client.
Client .
— Secteur Economique.
— Localisation. Affaire.
— Somme impayés. de Recouvrement.
 Figure 4.11 – Tableau de bord «tableau de bord global» :

58
CHAPITRE 4. MISE EN OEUVRE

Tableau de bord « Détails Client » :

Ce tableau de bord décrit les détails du client sélectionné en terme de notation selon dif
férentes axes tels que :

— -Période.
— -Phase et strate actuels.
— - Agent et groupe.
— - Historique des actions et des sorts.
—
—
— - Nombre de transactions Impayées.
—
— -Montant impayé.
— -Montant de recouvrement.
 Figure 4.12 – Tableau de bord « Détails Client » :

59
CHAPITRE 4. MISE EN OEUVRE

Tableau de bord « Détails Agent » :

Ce tableau de bord permet d’observer détails du client, son efficacité, les montants re
couvrés ainsi que les montants impayés qu’il doive les recouvrer selon différentes axes
tels que :

— -Période
— - Action / Sort
— - Nombres d’affaires
 Figure 4.13 – Tableau de bord « Détails Agent » :

60
CHAPITRE 4. MISE EN OEUVRE

4.3 Développement d’un système de journalisation

Pour contrôler l’exécution de nos packages et assurer une trace sur les tâches et les
événements nous devons implémenter des fonctionnalités de journalisation. Ces derniers
nous permettent d’avoir des informations sur la performance de nos packages et de
détecter les erreurs qui peuvent être commises.

4.3.1 Log ODS

Nous avons configuré l’étendue de la journalisation qui se produit lors de l’exécution

d’un package sur le serveur Intégration Services de la manière suivante. La table de
journa
 Figure 4.14 – Log ODS

lisation nous offre des données détaillées sur l’exécution de notre package. Ces
informations peuvent être utilisées pour la réalisation des tableaux de bords de
performance.

61
CHAPITRE 4. MISE EN OEUVRE

Figure 4.15 – Table Log de la ODS

4.3.2 Log DWH

Nous avons configuré l’étendue de la journalisation qui se produit lors de l’exécution

d’un package sur le serveur Intégration Services de la manière suivante.
 Figure 4.16 – Log DWH

62
CHAPITRE 4. MISE EN OEUVRE

4.4 Processus d’automatisation

Plusieurs solutions existent pour planifier / automatiser l’exécution des packages SSIS
et SSAS dans le cadre d’un projet BI, les plus utilisées sont :

— À l’aide d’un job SQL : SQL Server Agent est un service Windows Microsoft qui
exécute des travaux définis dans une instance de SQL Server.

— À l’aide d’un script .bat : c’est un fichier qui contient une série d’instructions qui
permet d’automatiser un processus.

Dans notre projet, nous avons procédé à configurer un job SQL pour l’automatisation
périodique du processus ETL et le déploiement des cubes.

Ci dessous un exemple de résumé du journal pour l’exécution du job SQL.

Figure 4.17 – Job d’automatisation

4.5 Déploiement de la solution

Avec Power BI Report Server nous avons publié nos tableaux de bords sur le web afin
de partager les informations avec les collaborateurs au sein de l’organisation et d’explorer
visuellement les données et révélez rapidement les tendances afin de prendre des
décisions éclairées plus rapidement.
La publication Power BI sur le web permet de créer des scénarios de données avec
des visualisations interactives attrayantes

63
CHAPITRE 4. MISE EN OEUVRE

4.6 Conclusion
Nous avons dans ce chapitre présenté la partie réalisation de notre projet : les
interfaces des différentes parties de l’implémentation de la solution.
 64

Conclusion Générale

D ans un monde continuellement évolutif, la possession de la bonne information est une

nécessité pour les entreprises qui exercent le métier de vente et surtout l’octroi des
crédits vu les nouveaux défis du marché et la concurrence acharnée entre ces
entreprises. La présence d’un bon système qui fournit des données correctement
restituées devient indispensable pour tout manager qui veut assurer la croissance de son
entreprise.

Ce stage de fin d’étude s’inscrit dans le cadre d’obtention du diplôme d’ingénierie infor
matique spécialité Business Intelligence . Il s’est déroulé au sein de la direction
Intégration de la société Axe Finance pour une durée de 5 mois. C’était une opportunité
pour appro fondir les connaissances et le savoir-faire acquis durant les années de notre
formation.

Le système décisionnel développé dans le présent projet s’est déroulé comme suit : la
conception d’un DWH, l’extraction, la transformation et le chargement des données dans
une base de données , ainsi que le calcul des indicateurs de performance et de risque.
Finalement, la présentation des résultats d’une manière synthétique ou détaillée selon les
axes d’analyses sous forme de tableaux et de graphiques (histogrammes, courbes, etc.)

Cependant, ce présent travail pourrait être amélioré. Ainsi, il serait judicieux de mettre
en évidence des corrélations éventuelles dans un volume important de données afin de
dégager des tendances et prévoir des événements futurs.

Ce projet nous a beaucoup aidés à mieux découvrir le travail en équipe dans un cadre
professionnel. Nous avons appris aussi à gérer le temps, les problèmes , localiser la
problé matique et trouver une solution qui répond aux besoins attendus.

En termes de perspectives, la prochaine étape consiste à réaliser un volet décisionnel

qui va couvrir une analyse plus approfondie aidant le décideur à prédire les résultats du
futur pour classifier les clients selon son historique et prédire leurs comportements et
solvabilités dans des périodes bien définis.

65

Bibliographie

[1] Axe Finance :. http://www.axefinance.com/. Visité le 06 Juillet 2020.

[2] Rapports Internes Axe Finance :. Rapport de recouvrement.
[3] Cycle de vie Ralph Kimball. https://decizia.com/
 cycle-de-vie-decisionnel-definition/#:~:text=Le%20cycle%20de%20vie% 20logiciel%2C
%20une%20norme%20IEEE%20!&text=En%20g%C3%A9n%C3%A9ral%
20le%20cycle%20de,%C3%A2ge%20adulte%20et%20la%20vieillesse. Visité le 10
Mars 2020.
[4] Architecture d’un système décisionnel :. http://theses.univ-lyon2.fr/
documents/lyon2/2016/younsi_fz/pdfAmont/younsi_fz_these_udl.pdf. Visité le 30
Janvier 2020.
[5] approches pour construire un Data Warehouse (DW) :. https://www.aerow.group/
a16u1509/. Visité le 03 Mars 2020.
[6] Gartner. https://www.climber.nl/qlik-a-leader-in-the-2020-gartner-magic-quadrant/. Visité le 15
Février 2020.
[7] La méthodologie GIMSI :. https://www.piloter.org/mesurer/methode/ methode-GIMSI-
phases.htm/. Visité le 10 Mars 2020.
[8] Diagramme de gantt :. https://www.gantt.com/fr/. Visité le 02 Avril 2020. [9] Définition
de l’informatique décisionnelle :. http://theses.univ-lyon2.fr/
documents/lyon2/2016/younsi_fz/pdfAmont/younsi_fz_these_udl.pdf. Visité le 7 Janvier
2020.
[10] Objectif de l’informatique décisionnelle :. http://theses.univ-lyon2.fr/
documents/lyon2/2016/younsi_fz/pdfAmont/younsi_fz_these_udl.pdf. Visité le 15
Janvier 2020.

66