Minist re de lEnseignement Sup rieur Et de la
Recherche Scientifique
Universit de Tunis
Institut Sup rieur de Gestion de Tunis
Projet de fin d tudes pour lobtention
dune licence appliqu e en Informatique D cisionnelle
ELABORATION DUNE SOLUTION DECISIONNELLE
POUR LATB
Entreprise daccueil
Arab Tunisian Bank (ATB)
Elabor par
Kdous Mohamed Amine
Sammouda Chirine
Encadrant p dagogique
Encadrant professionnel
Mme. Rejeb Lilia
Mr. Sahraoui Aymen
Ann e universitaire
2017 2018
Remerciements
D dicace
Kdous Mohamed Amine
D dicace
Sammouda Chirine
Table des mati res
Chapitre I : Contexte g n ral ................................................................................................... 11
1.
Introduction ....................................................................................................................... 11
2. Cadre du projet .................................................................................................................. 11
3. Pr sentation de lorganisme daccueil .............................................................................. 11
3.1 Historique .................................................................................................................. 11
3.2
Fiche didentit de lATB .......................................................................................... 12
3.3 Organigramme du si ge ............................................................................................. 13
3.4 Direction du Stage ..................................................................................................... 13
3.4.1
Pr sentation de la DCSI ..................................................................................... 14
3.4.2
Pr sentation de la direction des tudes et des projets ......................................... 15
4. Pr sentation du projet ....................................................................................................... 15
4.1 Contexte du projet ..................................................................................................... 15
4.2 Analyse de lexistant ................................................................................................. 16
4.3 Critique de lexistant ................................................................................................. 16
4.4 Description de la solution .......................................................................................... 17
5. Conclusion ........................................................................................................................ 18
Chapitre II : M thodes de conception et outils d cisionnels .................................................... 19
1.
Introduction ....................................................................................................................... 19
2. M thode de conception ........................................................................................................ 19
2.1
Etudes des m thodes pr dictives classiques .............................................................. 19
2.2 M thodes AGILES .................................................................................................... 20
2.3 M thodes AGILES Vs M thodes pr dictives classiques .......................................... 21
2.4 M thodologie adopt e ............................................................................................... 22
2.5
Pr sentation de la m thodologie SCRUM ................................................................. 23
2.6
Les intervenants dans Scrum ..................................................................................... 23
2.7
Les art facts du Scrum [11] ....................................................................................... 24
2.8
Lapproche SCRUM appliqu un projet BI ............................................................ 25
3. Approche de conception de lentrep t de donn es ........................................................... 26
3.1 Mod les conceptuels .................................................................................................. 26
3.2 Approches pour la cr ation du Datawarehouse (ROLAP, MOLAP, HOLAP) ......... 26
4. Comparaison des outils d cisionnels ................................................................................ 27
4.1 Outils pour la cr ation de DataWarehouse ................................................................ 27
4.2 Outils pour Extract Transform Load (ETL) .............................................................. 29
4.3 Outils de Reporting .................................................................................................... 31
5. Environnement de d veloppement retenu ......................................................................... 32
5.1 Outil de conception ................................................................................................ 33
5.2 Outil de d veloppement ......................................................................................... 33
6. Conclusion ........................................................................................................................ 34
Chapitre III : Phase de pr paration ........................................................................................... 35
1.
Introduction ....................................................................................................................... 35
2. Analyse des besoins .......................................................................................................... 35
2.1
Identification des acteurs du syst me ........................................................................ 35
2.3
Sp cification des besoins non fonctionnels ............................................................... 36
3. Backlog produit ................................................................................................................. 37
4. Planification du projet ....................................................................................................... 39
4.1
Pilotage du projet avec la m thodologie SCRUM ..................................................... 39
4.2 D coupage de la solution en Sprints : ....................................................................... 39
4.3 Diagramme de Gant ................................................................................................... 40
5. Etude des donn es sources ................................................................................................ 40
6. Conception de la base de donn es .................................................................................... 42
7. Alimentation de la base de donn es .................................................................................. 42
8. Conclusion ........................................................................................................................ 44
Chapitre IV ............................................................................................................................... 45
Sprint 1 : Mise en place dun Data Warehouse des Suivis ....................................................... 45
1.
Introduction ....................................................................................................................... 45
2. Sprint Backlog .................................................................................................................. 45
3. Conception du DataWarehouse ......................................................................................... 47
3.1 Choix des mesures ..................................................................................................... 47
3.2 Choix des dimensions ................................................................................................ 47
3.3
Table de faits ............................................................................................................. 48
4. Mod lisation du DataWarehouse ...................................................................................... 49
5.
Int gration des donn es du DataWarehouse (ETL) .......................................................... 49
5.1 Extraction des donn es ................................................................................................... 51
5.2 Transformation des donn es ........................................................................................... 53
5.3 Chargement des donn es ................................................................................................ 57
6. La restitution des donn es ................................................................................................. 59
Chapitre V : Suivi et valuation de la classification des actifs et des risques clients. ............. 67
1.
Introduction ....................................................................................................................... 67
2. Sprint Backlog .................................................................................................................. 67
3. La classification des Actifs ............................................................................................... 68
3.1 Actifs courants (Classe 0) .......................................................................................... 68
3.2 Actifs n cessitant un suivi particulier (Classe 1) ....................................................... 68
3.3 Actifs incertains (Classe 2) ........................................................................................ 69
3.4 Actifs pr occupants (Classe 3) .................................................................................. 69
3.5 Actifs compromis (Classe 4) ..................................................................................... 69
4. Formules pour le calcul des risques .................................................................................. 70
Publicité
4.1
Formule de calcul du STRATE ........................................................................... 70
4.2
Formule de calcul de la Variation des engagements ................................................. 70
4.3
Formule de calcul de la Garantie plafonn lengagement ...................................... 70
5. Conception du Datamart Risque ................................................................................. 71
5.1 Choix des mesures .......................................................................................................... 71
5.2 Choix des dimensions ................................................................................................ 71
5.3 Mod lisation du Datamart .............................................................................................. 72
6.
Int gration des donn es du Datamart RISQUE (ETL) ............................................... 72
6.1
Extraction des donn es .............................................................................................. 72
6.2
Transformation des donn es ...................................................................................... 73
6.3 Chargement des donn es ........................................................................................... 76
Annexe A : Le Projet D cisionnel ............................................................................................ 77
ANNEXE B : Dictionnaire des donn es sources ..................................................................... 82
Bibliographie ............................................................................................................................ 87
Table des figures
Liste des tableaux
Introduction g n rale
Chapitre I : Contexte g n ral
1. Introduction
Dans le pr sent chapitre, nous allons voquer bri vement lhistorique de lorganisme daccueil,
ses missions et son organisation. Par la suite, nous allons introduire le contexte du projet et faire
une tude de lexistant. Enfin, nous nous int ressons la pr sentation de la solution propos e
et la justification du choix de la m thodologie adopt e.
2. Cadre du projet
Ce projet sinscrit dans le cadre de la pr paration dun projet de fin d tudes afin dobtenir le
Dipl me de Licence Appliqu e en Informatique D cisionnelle lInstitut Sup rieur de Gestion
(ISG). Ce projet dont la dur e est de trois mois, est r alis au sein de lATB (Arab Tunisian
Bank).
Son objectif principal est le d veloppement dune application int gr e d di e laide la
d cision.
3. Pr sentation de lorganisme daccueil
3.1 Historique
En 1930, lArab Bank a t fond e dans le but de construire une institution au service du monde
arabe. Elle a d marr avec sept actionnaires et un capital qui ne d passait pas les 15 000 livres
palestiniennes. 52 ans plus tard, Arab Bank a d cid dint grer lagence de Tunisie et fondre
une banque commerciale tunisienne lATB.
LATB sest donn e pour mission doffrir des services diversifi s et de qualit aux particuliers
ainsi quaux professionnels et de contribuer au d veloppement conomique et financier du pays.
Elle est class e parmi les meilleures banques en termes de r sultats, importance des fonds
propres et de ses actifs.
L'ATB dispose aujourd'hui d'un r seau de 131 agences et emploie plus de 1300 personnes. Cette
banque sest investie dans le d veloppement dune strat gie de filialisation. On parle
aujourdhui dune cr ation des soci t s sp cialis es. En vue de consolider sa position sur le
march Tunisien et daccro tre ses champs daction, lATB sint resse particuli rement aux
axes suivants [1] :
" Une orientation plus soutenue vers le march des particuliers sans toutefois
n gliger sa cible privil gi e constitu e des petites et moyennes entreprises, et les
grandes entreprises.
" Une synergie entre la banque et ses filiales.
3.2 Fiche didentit de lATB
Comme tout tablissement, lATB poss de une fiche signal tique qui est d crite par la table 1
[2] :
D nomination
Date de cr ation
Fondateur
Si ge social
Forme juridique
Activit
Direction
Nombre dagences
Nombre demploy es
Nombre de filiales
Capitalisation
Bilan comptable
T l phone
Site web
LArab Tunisian Bank
30 juin 1982
Hatem Kchouk
9 Rue Hedi Nouira, 1001 Tunis
Soci t anonyme
Banque
Mohamed Ferid Ben Tanfous
131
1300
9
100 millions TND en 2015
2 696 000 USD en 2014
71351155
http://www.atb.tn/
Table 1. Fiche d'identit de l'ATB
3.3 Organigramme du si ge
Lorganisation de lATB est mod lis e par lorganigramme pr sent dans la figure 1 :
Directeur
g n ral
Direction
centrale de
financement
Dircetion
centrale de
l'inspection et de
l'audit
Adjoint au
directeur
g n ral
Direction des
affaires
juridiques
Direction central
du d partement
comptable
Direction des
moyens de
paiement
Direction des
ressources
humaines
Direction
d'organisation
Direction de
syst mes
Publicité
d'infomation
Division
administration
des syst mes
Division de
coordination
Division de
production
Division tudes
et
d veloppement
Service
maintenance
hard
Service
exploitation
Service
maintenance
application soft
Service
maintenance
application hard
centrale
help desk
Figure 1. Organigramme du si ge [3]
3.4 Direction du Stage
Notre stage d tude se d roulera au sein de la direction des syst mes dinformation, plus
pr cis ment dans la division administration des syst mes en collaboration avec la direction des
Etudes et des projets. Nous allons expliquer dans ce qui suit, les activit s de chacune de ces
directions.
3.4.1
Pr sentation de la DCSI
La direction centrale des syst mes dinformation de lATB (DCSI) est compos e
principalement de trois d partements :
Le d partement infrastructure et syst mes qui est subdivis en :
" Unit r seau de communication
" Cellule dadministration syst mes et base de donn es
" Unit de gestion de mat riel informatique
Le d partement exploitation et maintenance constitu de :
" La division assistance utilisateur
" La cellule de sauvegarde et restauration
" La division exploitation
Le d partement application et maintenance qui est compos de :
" La cellule core system
" Lunit des canaux de distribution lectronique
" La division d veloppement et maintenance syst me
"
Nous nous int ressons, non seulement la cellule dadministration syst mes et base de donn es
qui fait partie du d partement infrastructure et syst mes, mais aussi la direction des tudes et
des projets qui pilote tous les projets de la banque.
3.4.2 Pr sentation de la direction des tudes et des projets
La Direction des tudes et des projets a pour mission la planification strat gique et
op rationnelle des actions de d veloppement de la banque.
A ce titre, elle est charg e notamment :
" De r aliser des tudes n cessaires latteinte des objectifs de la banque.
" Dassurer le pilotage de plusieurs projets en termes de co t, d lai, qualit et risque.
" Dassurer le suivi et l valuation de la performance des projets.
" De coordonner l laboration des plans et des strat gies
" De produire les rapports dactivit
4. Pr sentation du projet
4.1 Contexte du projet
Ce projet consiste laborer une solution d cisionnelle pour lanalyse des engagements, des
produits et des garanties de la banque tout en se r f rant de la classification et le calcul de risque
des clients afin de faciliter la prise de d cision.
La banque dispose des sources de donn es regroupant des informations sur les clients cr anciers
telles que :
Les engagements : Le client peut tre li diff rents types dengagements envers
la banque. Principalement, on peut citer :
" Les cr dits moyen terme
" Les cr dits long terme
" Les engagements par signature
" Laval
Les produits : Le client sengage fournir les produits bancaires tels que les
diff rents types de commissions, dint r t et les agios&
Les garanties : La banque exige une garantie bancaire qui permet dassurer un
remboursement dans le cas o le client n'arriverait pas honorer le contrat.
Les classes : La classification des clients peut tre consid r e comme une tape
essentielle la prise de d cision et se fait selon :
- Le gel des comptes bancaires
- La consolidation des cr dits
- La classification des impay s
Chaque classe peut avoir une valeur entre 0 et 5. Plus la note est proche de 5 plus le client est
mal class .
4.2 Analyse de lexistant
Les donn es de lATB sont g n ralement sauvegard es dans un syst me Oracle, mais il existe
aussi une grande partie qui a t migr e vers un nouveau syst me intitul Equation
sp cifique lArabe banque. La migration totale des donn es est encore inachev e donc une
partie des donn es concernant les engagements clients r side toujours dans lancien syst me.
Pour suivre les engagements, les produits et les garanties, la solution utilis e actuellement est
une application .NET classique qui permet la consultation et lexportation des donn es sous
forme Excel et peut tre consid r e comme tant basique et traditionnelle. Elle est d finie sur
une base de donn es Oracle 11g en utilisant des liens de bases de donn es DBLINK permettant
lacc s distance (oracle 11g, AS 400).
4.3 Critique de lexistant
La solution utilis e traite chaque module part. Dailleurs les informations concernant les
engagements, les clients, les produits et les garanties se trouvent dans diff rentes bases de
donn es.
Cette solution tait ad quate et r pondait aux besoins des d cideurs pour le suivi des
engagements clients, la consultation et le calcul. Cependant, depuis quelques ann es, la banque
a not une augmentation consid rable du nombre de client le, do une l vation du volume
des donn es traiter et lenrichissement du syst me dinformation de la banque. Ceci a men
alors, linefficacit de cette solution face ces changements, on parle d :
- un mauvais partage de linformation
- un manque de souplesse
- un temps de traitement tr s lent qui peut durer jusqu 4 jours en consid rant le volume
important des donn es analyser.
Les bases de donn es relationnelles utilis es dans cette solution sont d finies comme tant un
r pertoire d' l ments de donn es dot s d'une relation pr d finie entre eux. Ce r pertoire peut
contenir des informations erron es et manquantes, et ne r pondent pas aux attentes des
d cideurs qui ont besoin dinformations pertinentes et fiables sur lesquelles ils peuvent
sappuyer pour une prise de d cision avis e. Il est indispensable alors dopter pour une structure
de donn es mieux adapt e afin de faciliter lanalyse des donn es pour des fins d cisionnelles.
Les d cideurs sont confront s des probl mes qui r sident dans :
- La complexit de la structure de la base cause de nombre assez important des tables
et des jointures mises en Suvre.
- La difficult dacc s distance aux informations.
- La difficult de la repr sentation des donn es historiques
- La g ne de lexploitation optimale des donn es et la classification selon un th me
bien d termin .
Publicité
4.4 Description de la solution
Apr s avoir tudi le processus de la prise de d cision de lATB, il sest av r quil est
n cessaire de mettre en place un syst me d cisionnel qui va permettre de :
- Homog n iser les ressources de donn es h t rog nes.
- Suivre les engagements clients via une interface utilisateur en visualisant
principalement les impay s et les cr dits.
- Consulter les produits de la banque (les int r ts et les commissions).
- Consulter les garanties.
- Classifier les clients et calculer les risques dinsolvabilit (classification des actifs,
les agios, les provisions).
- Analyser les donn es et g n rer des rapports selon le besoin du d cideur.
- Diffuser les informations n cessaires tous les acteurs d cisionnels.
- Faciliter lanalyse et la prise de d cision au niveau des hauts et moyens secteurs de
la banque.
Cest pour cette raison que nous avons opt pour une solution d cisionnelle ayant pour but de
collecter et r cup rer les donn es de diff rentes sources disponibles, les traiter et les charger
dans un entrep t de donn es puis fournir une interface web dynamique qui permettra aux
d cideurs de suivre les engagements, les produits et les garanties bancaires, de consulter la
classification des clients tout en se r f rant du risque calcul , et enfin avoir lacc s aux
diff rents tableaux de bord et des rapports interactifs pour des fins d cisionnelles.
5. Conclusion
A travers ce chapitre, nous avons pu acqu rir une connaissance assez importante concernant
lactivit de lATB, en faisant l tude de lexistant et en soulignant ses limites. Ensuite, nous
avons propos une solution qui r pond aux besoins de la banque. Quant au chapitre qui suit,
nous allons num rer les diff rentes m thodes de conception qui existent pour enfin, adopter
une et Idem pour les outils informatiques d cisionnels.
Chapitre II : M thodes de conception et outils
d cisionnels
1. Introduction
Afin dassurer une bonne gestion du projet, une tude comparative des m thodes de conception
simpose ce stade. De m me pour le choix des outils informatiques que nous allons utiliser et
les approches que nous allons adopter. Ce chapitre sera alors, d di la justification de nos
choix en faisant recours une comparaison bien d taill e.
2. M thode de conception
2.1 Etudes des m thodes pr dictives classiques
Les m thodes de d veloppement utilis s jusqu 1990 comme Cycle en V , Cleanroom ,
Waterfall et la Spiral de Boehm nassuraient plus la bonne ma trise et la gestion des
co ts, budgets, et des d lais dun projet dont le p rim tre fonctionnel est assez d velopp .
Les tudes du Standish Group ont d montr travers le Chaos Report [4] que le taux de
r ussite des projets labor s avec Waterfall, par exemple, na pas d pass 32% en 2009, et
beaucoup moins en 2012 avec un taux de 14%. Alors quon consid re quun projet r ussi, sil
arrive respecter le p rim tre fonctionnel, le budget et les d lais pr vus pr alablement. Cest
pourquoi les recherches se sont orient es vers lexploration de nouvelles approches adopter
notamment les m thodes agiles.
Successful
Challenged
Failed
Figure 2. The Chaos Manifesto
2.2 M thodes AGILES
Une m thode agile est une approche it rative et incr mentale, qui est men e dans un esprit
collaboratif avec juste ce quil faut de formalisme. Elle g n re un produit de haute qualit tout
en prenant en compte l volution des besoins des clients. [5]
Cette approche forme un ensemble de m thodes permettant en effet de g rer essentiellement
les projets informatiques.
Elles se basent sur des cycles de d veloppement adaptifs en fonction des besoins fonctionnels
du projet. En outre, limplication des collaborateurs dans le d veloppement du projet est
assur e.
Ces m thodes r pondent aux attentes du client en un temps r duit et impliquent les
collaborateurs en comp tences.
Les m thodes de d veloppement Agile peuvent tre num r es comme suit :
" Scrum
" Adaptive Software Development (ASD)
" Extreme Programming
" Dynamic System Development Method (DSDM)
" XP
" Kanban
Etc...
La figure 3 illustre la r partition de diff rentes m thodologies Agiles adopt es en 2016 [6].
Scrum occupe la plus grande partie. Dailleurs il est g n ralement adopt pour son paradigme
innovateur de conduite de projet ainsi que ses pratiques ding nierie logicielle.
Figure 3. R partition des M thodologies agiles adopt es en 2016
2.3 M thodes AGILES Vs M thodes pr dictives classiques
Apr s avoir tudi chaque m thode, nous proposons ce tableau comparatif qui r capitule les
principales diff rences entre les deux m thodes. [7]
Axe de comparaison M thodes AGILES
M thodes classiques
Planification
Cycle de vie
Adaptive
Pr dictive
It ratif et incr mental
En cascade ou en V
Documentation
Tr s r duite au strict n cessaire au
Livr e en quantit
profit des fonctionnalit s
importante sous forme dun
op rationnelles afin de recevoir les
Support de communication
feedbacks des clients.
et de validation.
Equipe
Une quipe soutenue par un chef
Une quipe compos e de
de projet o la communication et
ressources sp cialis es
linitiative sont les piliers du
dirig e par un chef de projet.
travail.
Livraison de la
G n ralement rapide et
G n ralement tardive.
solution
incr mentale.
Intervention du client Tr s fr quente lors de la mise en
Pratiquement inexistante, le
Suvre de la solution avec
client value le produit vers
proposition de changement si
la fin du projet.
souhait .
Mesure de succ s
Respect des engagements initiaux
Satisfaction du client
en termes de d lais, budgets, co ts
et qualit .
Table 2. M thodes AGILES Vs m thodes classiques
2.4 M thodologie adopt e
Apr s cette tude comparative, nous avons d cid dadopter la m thode Agile pour r aliser
Publicité
notre projet. Cette m thode est parfaitement coh rente avec les concepts de base du cycle de
vie dun Datawarehouse, un concept publi par le Ralph Kimball, qui se r sume en trois points
[8] :
" Ajouter une valeur m tier lentreprise.
" Stocker les donn es dans des dimensions.
" Concevoir une solution daspect it rative.
Les m thodes agiles sont de nature it rative et participative, on commence par d velopper des
petits morceaux dapplication qui apportent de la valeur ajout e, quon valide par le client puis
on passe aux suivants. Cest le client qui pilote au fur et mesure le d veloppement de la
solution travers le choix des fonctionnalit s quil souhaite voir d velopper.
La nature de ce processus est la cl de notre d cision. Appliquer lagilit sur un projet
d cisionnel permettra dimpliquer davantage lutilisateur et dassurer la valeur m tier pour
lorganisation.
Apr s avoir fix une m thode suivre pour la r alisation du projet, il est temps de choisir une
des m thodes de d veloppement Agile parmi celles cit es pr c demment.
2.5 Pr sentation de la m thodologie SCRUM
La m thodologie SCRUM est inspir e des valeurs et de lesprit du jeu Rugby. Cette approche
est issue des travaux des signataires du Manifeste Agile : Sutherland et Schwaben, et fait partie
de la famille des m thodologies incr mentales et it ratives.
Cette m thodologie est d finie dans un milieu de travail assurant la r alisation des projets
consid r s complexes. Cette m thode est apte principalement pour la mise ex cution des
projets software n anmoins, elle peut tre galement appliqu e tout autre type de projet, du
plus simple au plus innovant.
En utilisant les m thodologies classiques et unifi es, le client ne pouvait ni suivre l volution
du travail ni tre impliqu dans lex cution de son projet
En effet, en Scrum, le client est plus impliqu dans le suivi de lavancement du projet et
lapprobation de plusieurs livrables. Il peut donc suivre r guli rement l volution des travaux
dans le cas dune demande de modification dun l ment ou dinsatisfaction a sera plus facile
de le modifier pour satisfaire ses besoins.
La m thodologie SCRUM assure loptimisation de la pr visibilit dun projet et le contr le des
risques. [9]
2.6 Les intervenants dans Scrum
En comparant un projet s quentiel avec un projet agile, on note une diff rence aux niveaux des
missions et des responsabilit s des intervenants car une importance particuli re est accord e
sur lappropriation de tous les l ments sprint du projet par les membres de l quipe.
La m thodologie Scrum d finit trois r les [10] :
" Le Porduct Owner (PO)
Cest le porte-parole des clients charg de d finir soigneusement le backlog qui permet de
recueillir les besoins du client, les sp cifications du produit ainsi que toutes les fonctionnalit s
du projet r aliser. Le propri taire du produit est galement responsable de classer les l ments
du backlog par priorit et indiquer lordre de leur r alisation.
" Le Scrum Master
Cest la personne qui joue le r le dun animateur de l quipe. Il nest pas consid r comme un
chef de projet ou un donneur dordres mais plut t comme un coordinateur facilitateur qui assure
le bon d roulement du projet et veille r soudre les probl mes et les obstacles qui emp chent
lavancement du travail de son quipe.
" Le Scrum Team
Cest l quipe de d veloppement qui est responsable de d livrer les l ments de chaque sprint
selon leurs ordres de priorit s. Le groupe est constitu darchitectes, d veloppeurs
administrateur base de donn es etc.
2.7 Les art facts du Scrum [11]
" Product Backlog :
Le carnet des produits est d fini comme tant une liste ordonn e contenant les exigences et les
besoins du client et toutes les sp cifications relatives au produit. Le Porduct Owner est charg
du Product Backlog en termes de contenu, disponibilit et ordonnancement.
" Sprint Backlog :
Le sprint Backlog est un l ment indispensable pour la compr hension de la progression du
travail de l quipe de d veloppement. Chaque sprint doit r pondre aux attentes du Product
Owner et assure latteinte des objectifs pr alablement d finis au d but du Sprint. Il sagit dun
plan bien d taill de taches effectu es
" Sprint Burn-Down Chart :
Le graphique d'avancement est une repr sentation qui donne une vue globale sur l' volution de
quantit de travail restante par rapport au travail engag . Sur laxe vertical se situe le travail
restant. Laxe horizontal pr sente le temps. Ce type de graphique permet de pr voir l tat
davancement du travail pendant un laps de temps afin de suivre le d roulement de lactivit .
Figure 4. Vue globale du Scrum [12]
2.8 Lapproche SCRUM appliqu un projet BI
Le projet d cisionnel est un projet de type particulier. Il est non seulement complexe, mais aussi
il doit aussi r pondre parfaitement aux besoins volutifs des utilisateurs engag s de prendre des
d cisions cruciales dans un univers instable et changeant. Cela nest autre que la finalit de
Business Intelligence. Dailleurs, toute d cision est obligatoirement une prise de risque,
dautant plus critique calculer dans un environnement incertain. De ce fait, il est indispensable
dint grer et inclure au plus les utilisateurs lors de d veloppement de la solution. Pour cette
raison, la solution SCRUM agile est appel e lors de l laboration dun projet BI. Elle propose
en effet, plusieurs approches appliquer sur ce type de projet [13], Nous citons : [14]
" Lapproche de Kimball Bottom-Up
Dans cette approche, Le Data Warehouse est consid r comme tant lunion des datamarts
coh rents entre eux. Le Datawarehouse physique nexiste pas.
" Lapproche dInmon Top-Down
Dans cette approche, le Data Warehouse est un r f rentiel centralise stockant les donn es
relatives lentreprise au niveau le plus d taille. Par la suite, des Datamarts sont mod lis s et
cr es a partir de ce Data Warehouse.
Quant notre solution, nous avons adopt lapproche de conception top-down permettant
de mettre en place un r f rentiel centralis , le DW, puis charger de mani re coh rente les
datamarts. Cette approche est simple et r sistante lors de chargements des dimensions, ainsi
que lors de cr ations des magasins de donn es. En outre, elle est insensible et flexible aux
besoins des clients qui voluent au cours des phases de mise en Suvre.
3. Approche de conception de lentrep t de donn es
3.1 Mod les conceptuels
Dans cette section, nous allons choisir un sch ma de mod lisation de notre Datawarehouse.
Commen ons tout dabord par d finir les deux mod les quils existent [15] :
" Un sch ma en toile (Star Schema) est une structure dimensionnelle qui repr sente, au
centre, une seule table de faits dont les colonnes sont les mesures. La table de faits est
entour e par cercle de dimensions pr sentant les axes danalyse. Toute dimension
niveaux multiples est aplatie en une seule dimension. Le sch ma en toile est con u
pour r pondre des requ tes inh rentes la structure dimension-fait.
" Le principe du sch ma en flocon de neige est quils peuvent exister des hi rarchies de
dimensions, contrairement au sch ma en toile.
Pour notre solution, nous avons opt pour le mod le en flocon de neige qui permet de formaliser
une hi rarchie de dimensions, ce qui facilite lanalyse et r duit le volume des donn es.
3.2 Approches pour la cr ation du Datawarehouse (ROLAP, MOLAP,
HOLAP)
Il existe 3 possibilit s pour cr er un DW [16] :
" Relationnel OLAP (ROLAP) : Les donn es sont stock es dans un SGBD relationnel et
un moteur OLAP permet de stimuler le comportement du SGBD.
" Multidimensionnel OLAP (MOLAP) : Les donn es sont stock es dans un Cube qui
nest autre quune base de donn es multidimensionnelle qui permet la restitution des
donn es de fa on instantan e.
" Hybride OLAP (HOLAP) : LHOLAP est un m lange du ROLAP et du MOLAP, les
cubes HOLAP sont donc Hybrides.
Pour notre solution, nous avons opt pour HOLAP. Lid e consiste avoir la possibilit
dacc der aux donn es agr g es travers MOLAP, ou acc der aux d tails si souhait s travers
ROLAP. Cela pourra nous aider lors de la phase de restitution. Nous pourrons avoir un rapport
dont les donn es sont issues dune base multidimensionnelle, ainsi quun autre beaucoup plus
d taill dont les donn es sont issues, cette fois-ci, dune table relationnelle. [17]
4. Comparaison des outils d cisionnels
Nous allons pr senter dans c...