Développement des interfaces pour la plateforme Megara-Forex et implémentation d'une couche décisionnelle.

1. D ´EDICACES
Je d´edie ce projet `a ma pr´ecieuse famille pour lui exprimer ma sinc`ere
gratitude, dans le but de partager avec elle les bons moments de ma vie
et mon bonheur d’en faire partie.
`A mes parents ador´es qui m’ont toujours soutenu pendant toute ma vie
en me procurant leur aide inestimable.
Pour leur amour et leur pr´esence continue `a mes cot´es.
Pour leur affection et leur sacrifice continu.
`A mon fr`ere qui n’a jamais cess´e de me supporter.
`A ma sœur qui m’a toujours aid´e et soutenu.
`A tous mes ami(e)s et coll`egues et toutes les personnes qui ont
contribu´e `a la r´ealisation de ce projet.

2. REMERCIEMENTS
C’est avec un r´eel honneur que je j’attribue cette page pour exprimer ma
gratitude `a toutes les personnes qui m’ont aid´e `a r´ealiser ce projet.
Je tiens `a exprimer ma reconnaissance et mes remerciements `a mon
encadrante acad´emique au sein de l’´ecole Polytech-Intl Mme Yemna
SAYEB pour le temps qu’elle a bien voulu consacrer au suivi et
l’encadrement et au suivi de ce projet.
Les discussions que nous avons tenues ont permis d’orienter ce travail
d’une mani`ere sure et pertinente. Je la remercie vivement pour ses
efforts, sa disponibilit´e et surtout ses conseils qui ont largement
contribu´e `a rehausser la valeur de ce travail..
Je ne manquerais pas d’adresser mes chaleureux et tr`es sinc`eres
remerciements `a mon encadrant au sein de BFI, M. Anis KHLIF qui a
su me communiquer la richesse de son savoir faire `a travers ses conseils
qu’il n’a pas h´esit´e `a me fournir, malgr´e ses nombreuses charges.
Ma reconnaissance s’adresse enfin, `a tous mes enseignants, qui m’ont
form´e tout au long de mes ann´ees d’´etudes.

3. Avant-propos
La fin de notre cursus universitaire en tant qu’´el`eve ing´enieur `a l’´ecole Polytech-Inlt est couronn´ee par
un projet de fin d’´etudes qui est consid´er´e comme une mise au point des acquis durant les ann´ees universi-
taires avant d’entamer la vie professionnelle.
Dans ce cadre, j’ai eu l’opportunit´e d’effectuer un stage au sein de la soci´et´e BFI `a savoir Banque Fi-
nance Internationale dans laquelle je travaille depuis d´ej`a un an.
Au cours de notre projet nous avons impl´ement´e une solution bas´ee sur deux ´etapes. La premi`ere
consiste `a d´evelopper de nouveaux ´ecrans dans le module Carthago Tr´esorerie qu’on va pr´esenter plu tard
et impl´ementer une chaine d´ecisionnelle afin de r´ealiser des tableaux de bords offrant une visibilit´e plus
accrue des donn´ees des modules faisant partie de la solution Megara Forex.

4. Table des mati`eres
Introduction g´en´erale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 Cadre g´en´eral du projet 3
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1 Pr´esentation g´en´erale de l’organise d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Historique de BFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Pr´esentation de BFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Solutions de BFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Global banking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Organigramme de BFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 ´Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Probl´ematique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Solution propos´ee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Analyse du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1 Description du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Analyse des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 P´erim`etre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Choix de la m´ethodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5 Planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6 Organisation du rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2 Initialisation du projet 25
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1 Concepts de l’informatique d´ecisionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.1 Syst`emes d’informations d´ecisionnels . . . . . . . . . . . . . . . . . . . . . . . . 26
1.2 L’informatique d´ecisionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.2.1 D´efinition de l’informatique d´ecisionnelle . . . . . . . . . . . . . . . . . 27

5. 1.2.2 Avantages de l’informatique d´ecisionnelle . . . . . . . . . . . . . . . . 28
1.2.3 Inconv´enients de l’informatique d´ecisionnelle . . . . . . . . . . . . . . . 28
1.3 Syst`eme op´erationnels et syst`emes d´ecisionnels . . . . . . . . . . . . . . . . . . . 28
1.4 Entrepˆots de donn´ees ou DW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.5 Types d’entrepˆots de donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.6 Chaine d´ecisionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.6.1 Alimentation du datawarehouse . . . . . . . . . . . . . . . . . . . . . . 31
1.6.2 Mod´elisation des donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.6.3 Restitution des donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.6.4 Analyse et pr´evision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2 Sources de donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 Processus et choix ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1 D´efinition du processus ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2 ´Etapes du processus ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Choix de l’outil ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4 Mod´elisation du datawarehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5 Choix outil de restitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1 Pr´esentation de Power BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Fonctionnalit´es de Power BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3 Mise en œuvre de la partie applicative 45
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2 M´ethodologie et pilotage du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.1 Langage de mod´elisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.2 M´ethodes de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.3 M´ethodes agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.4 M´ethode adopt´ee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3 Les fonctionnalit´es de la plateforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1 Sp´ecification des fonctionnalit´es . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2 Diagramme de cas d’utilisation initial . . . . . . . . . . . . . . . . . . . . . . . . 51
4 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1 Description des cas d’utilisations cot´e Front office . . . . . . . . . . . . . . . . . . 51
4.1.1 Raffinement du cas d’utilisation G´erer les op´erations . . . . . . . . 51
4.1.2 Raffinement du cas d’utilisation G´erer ticket . . . . . . . . . . . . . 56
4.2 Description des cas d’utilisations cot´e Back office . . . . . . . . . . . . . . . . . . 58
4.2.1 Raffinement du cas d’utilisation G´erer op´erations . . . . . . . . . . 58

6. 4.2.2 Raffinement du cas d’utilisation G´erer les ´ech´eances des op´erations . 61
4.2.3 Raffinement du cas d’utilisation G´erer les tickets de validation . . . . 63
4.3 Description des cas d’utilisations cot´e administrateur . . . . . . . . . . . . . . . . 63
4.3.1 Raffinement du cas d’utilisation G´erer utilisateurs . . . . . . . . . . 63
4.3.2 Raffinement du cas d’utilisation G´erer Menu . . . . . . . . . . . . . 66
4.3.3 Raffinement du cas d’utilisation G´erer privil`eges . . . . . . . . . . . 69
4.4 Diagramme de cas d’utilisation d´etaill´e . . . . . . . . . . . . . . . . . . . . . . . 71
4.5 Conception du cas d’utilisation g´erer utilisateurs . . . . . . . . . . . . . . . . . . . 72
4.6 Prototypes des interfaces de l’application . . . . . . . . . . . . . . . . . . . . . . 75
4.7 Diagramme de classes des entit´es . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5 Environnement mat´eriel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.1 Outil de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2 Environnement mat´eriel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3 Environnement de d´eveloppement . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6 Interfaces utilisateurs de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4 Mise en œuvre de la partie d´ecisionnelle 86
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
1 Identification des indicateurs de performance . . . . . . . . . . . . . . . . . . . . . . . . . 87
2 Maquettes des tableaux de bords de la partie d´ecisionnelle . . . . . . . . . . . . . . . . . . 87
3 Mod´elisation des donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.1 Pr´esentation du source de donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.2 Chargement de la zone de pr´eparation ( ODS ) . . . . . . . . . . . . . . . . . . . . 92
3.3 Mod´elisation du datamart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
3.3.1 Approches de construction du DW . . . . . . . . . . . . . . . . . . . . 103
3.3.2 Mod´elisation du datamart . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.4 Construction du datamart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.4.1 Analyse des donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.4.2 Alimentation des dimensions . . . . . . . . . . . . . . . . . . . . . . . 107
3.4.3 Alimentation de la table de faits . . . . . . . . . . . . . . . . . . . . . . 110
4 Restitution des donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.1 Pr´esentation des tableaux de bords . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.1.1 Suivi des swifts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.1.2 Suivi des montants par devise . . . . . . . . . . . . . . . . . . . . . . . 112
4.1.3 Montant achet´e contre montant vendu . . . . . . . . . . . . . . . . . . . 113
4.1.4 Solde de la position de change . . . . . . . . . . . . . . . . . . . . . . . 113
4.1.5 Suivi des dossiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.1.6 Suivi des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

7. Conclusion g´en´erale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

8. Table des figures
1.1 Services de BFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Organigramme g´en´eral de BFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Diagramme de cycle de vie de Ralph Kimball . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 Cycle de vie Agile BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Architecture d’un SID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2 Types d’entrepˆots de donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 Processus ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4 Logo Talend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.5 Architecture Talend Open Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6 Repr´esentation du mod`ele en ´etoile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.7 Repr´esentation du mod`ele en flocon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.8 Repr´esentation du mod`ele en constellation . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.9 Magic Quadrant du Business Intelligence[15] . . . . . . . . . . . . . . . . . . . . . . . . 42
2.10 Logo de Power BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.11 Architecture de Power BI [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1 Unified Modeling Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2 Composants de la m´ethode SCRUM[18] . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3 Diagramme des cas d’utilisation g´en´eral . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4 Raffinement du cas d’utilisation G´erer Op´eration Front . . . . . . . . . . . . . . . . . 52
3.5 Raffinement du cas d’utilisation G´erer ticket . . . . . . . . . . . . . . . . . . . . . . . 57
3.6 Raffinement du cas d’utilisation G´erer op´eration . . . . . . . . . . . . . . . . . . . . 59
3.7 Raffinement du cas d’utilisation G´erer les ´ech´eances des op´erations . . . . . . . . . . 62
3.8 Raffinement du cas d’utilisation G´erer les tickets de validation . . . . . . . . . . . . . 63
3.9 Raffinement du cas d’utilisation G´erer utilisateurs . . . . . . . . . . . . . . . . . . . 64
3.10 Raffinement du cas d’utilisation G´erer Menu . . . . . . . . . . . . . . . . . . . . . . 67
3.11 Raffinement du cas d’utilisation G´erer Privil`eges . . . . . . . . . . . . . . . . . . . . 69
3.12 Diagramme de cas d’utilisations d´etaill´e . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.13 Diagramme de s´equence du CU Ajouter utilisateur . . . . . . . . . . . . . . . . . . . . . . 73
3.14 Diagramme de s´equence du CU Consulter utilisateur . . . . . . . . . . . . . . . . . . . . . 74
3.15 Diagramme de s´equence du CU Modifier utilisateur . . . . . . . . . . . . . . . . . . . . . 74

9. 3.16 Diagramme de s´equence du CU Supprimer utilisateur . . . . . . . . . . . . . . . . . . . . 75
3.17 Maquette d’authentification de l’application Megara-Forex . . . . . . . . . . . . . . . . . 76
3.18 Maquette de la page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.19 Maquette de la rubrique Carthago-Tr´esorerie . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.20 Maquette saisie des op´erations spot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.21 Maquette annulation des op´erations spot . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.22 Diagramme de classes des entit´es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.23 Logo MagicDraw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.24 Sp´ecification de la machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.25 Logo eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.26 ´Ecran de l’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.27 ´Ecran de l’interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.28 ´Ecran saisi change au comptant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.29 ´Ecran saisie d’une op´eration DAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.30 ´Ecran annulation d’une op´eration DAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.31 ´Ecran modification d’une op´eration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.32 ´Ecran saisie des op´erations de type change au comptant . . . . . . . . . . . . . . . . . . . 85
4.1 Maquette du suivi annuelle des dossiers(1) . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.2 Maquette du suivi annuelle des dossiers(2) . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.3 Maquette du suivi des op´erations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.4 Maquette du suivi utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.5 Maquette du suivi utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.6 Maquette du suivi de la position de change . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.7 Processus de chargement des donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.8 Chargement des client dans l’ODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.9 Chargement des groupes,grpe et group users dans l’ODS . . . . . . . . . . . . . . . . . . 94
4.10 Chargement des tier dans l’ODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.11 Chargement des utilisateurs dans l’ODS . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.12 Chargement des types op´erations dans l’ODS . . . . . . . . . . . . . . . . . . . . . . . . 98
4.13 Chargement des swfits dans l’ODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.14 Chargement de la table hope dans l’ODS . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.15 Repr´esentation sch´ematique de l’approche Bill Inmon . . . . . . . . . . . . . . . . . . . . 103
4.16 Repr´esentation sch´ematique de l’approche de Kimball . . . . . . . . . . . . . . . . . . . . 104
4.17 Mod`ele multidimensionnel du datawarehouse . . . . . . . . . . . . . . . . . . . . . . . . 106
4.18 Chargement de la dimension Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.19 Chargement de la dimension groupe,group users et grpe . . . . . . . . . . . . . . . . . . . 108
4.20 Chargement des dimensions Swiout et swift tyop . . . . . . . . . . . . . . . . . . . . . . 109
4.21 Chargement de la dimension TIER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.22 Chargement de la dimension utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

10. 4.23 Chargement des dimensions Tyop desk, Tyop Inter et Tyop . . . . . . . . . . . . . . . . . 110
4.24 Alimentation de la table de faits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.25 Suivi des swifts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.26 Suivi des montants par devise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.27 Montant achet´e contre montant vendu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.28 Solde de la position de change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.29 Suivi des dossiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.30 Suivi des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

11. Liste des tableaux
1.1 ´Evaluation des risques du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1 Tableau comparatif entre les syst`emes op´erationnel et d´ecisionnel . . . . . . . . . . . . . . 29
2.2 Tableau comparatif entre les outils ETL [18] . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3 Tableau comparatif entre les outils de restitution [14] . . . . . . . . . . . . . . . . . . . . 41
3.1 Tableau de planification des tˆaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2 Description textuelle du sous cas d’utilisation Saisir op´eration . . . . . . . . . . . . . 52
3.3 Description textuelle du sous cas d’utilisation Consulter op´erations . . . . . . . . . . . 53
3.4 : Description textuelle du sous cas d’utilisation Modifier op´eration . . . . . . . . . . . 54
3.5 Description textuelle du sous cas d’utilisation Supprimer op´eration . . . . . . . . . . . 55
3.6 Description textuelle du sous cas d’utilisation Validation op´eration . . . . . . . . . . . 56
3.7 Description textuelle du sous cas d’utilisation G´en´erer ticket . . . . . . . . . . . . . . 57
3.8 Description textuelle du sous cas d’utilisation G´en´erer ticket . . . . . . . . . . . . . . 58
3.9 Description textuelle du sous cas d’utilisation Valider op´eration . . . . . . . . . . . . . 60
3.10 Description textuelle du sous cas d’utilisation Modifier op´eration . . . . . . . . . . . . 61
3.11 Description textuelle du sous cas d’utilisation Valider ´ech´eance . . . . . . . . . . . . . 63
3.12 Description textuelle du sous cas d’utilisation Consulter liste utilisateurs . . . . . . . . 64
3.13 Description textuelle du sous cas d’utilisation Modifier utilisateur . . . . . . . . . . . 65
3.14 Description textuelle du sous cas d’utilisation Supprimer utilisateur . . . . . . . . . . . 66
3.15 Description textuelle du sous cas d’utilisation Enlever masque . . . . . . . . . . . . . 68
3.16 Description textuelle du sous cas d’utilisation Affecter masque . . . . . . . . . . . . . 68
3.17 Description textuelle du sous cas d’utilisation Autoriser acc`es . . . . . . . . . . . . . . 70
3.18 Description textuelle du sous cas d’utilisation Bloquer acc`es . . . . . . . . . . . . . . 71
4.1 Structure de la table client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.2 Structure de la table Groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.3 Structure de la table Group users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.4 Structure de la table Grpe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.5 Structure de la table Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.6 Structure de la table des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.7 Structure de la table tyop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

12. 4.8 Structure de la table tyop Desc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.9 Structure de la table Swift tyop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.10 Structure de la table Swiout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.11 Structure de la table Swiout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.12 Etude comparative entre les approches Kimball et Inmon . . . . . . . . . . . . . . . . . . 105

13. Vocabulaire sp´ecifique
BFI Banque Finance Internationale
SGBD Syst`eme de Gestion de Bases de Donn´ees
DW Datawarehouse ou Entrepˆot de donn´ees
KPI Key Performance Indicator ou Indicateur de Performance
ETL Extract – Transform – Load ou Extraxtion - Transformation - Chargement
EDI Environnement de D´eveloppement Int´egr´e
SCD Slowly Changing Dimensions
ODS Operational Data Store
GIMSI G´en´eralisation – Information – M´ethode – Syst`eme - Individualit´e
ERP Entreprise Resource Planning ou Progiciel de Gestion Int´egr´e
OLTP OnLine Transactional Processing
OLAP OnLine Analytical Processing
BI Business Intelligence ou Informatique D´ecisionnelle

14. INTRODUCTION G ´EN ´ERALE
La finance est une direction qui tient une place pr´epond´erante dans toute soci´et´e. La finance
bancaire et d’entreprise englobent les pr´evisions, les tableaux de bord, les flux de tr´esorerie, les
politiques d’investissement, la gestion des risques, la r´egularisation des documents.
En plus cette direction est ´etroitement li´ee au march´e des changes qui est le march´e sur lequel
se retrouvent tous les participants d´esireux de vendre ou d’acheter une devise contre une autre.
Il est souvent question du Forex pour d´esigner le march´e des changes; contraction des termes
anglais FOReign EXchange.
De fait les banques et les institutions financi`eres sont en mesure de collecter des quantit´es
presque infinies de donn´ees clients. Elles devraient donc ˆetre en mesure de les exploiter au mieux
afin de personnaliser la relation client de fac¸on concurrentielle. On constate aujourd’hui que ces
bases de donn´ees clients sont ind´eniablement sous-exploit´ees. Ceci peut ˆetre dˆu au fait que au
manque de donn´ees coh´erentes et exactes sur lesquelles aurait pu s’appuyer l’analyse interne (ges-
tion des risques) et externe (supervision r´eglementaire). La qualit´e des donn´ees sur les financiers
n’est g´en´eralement pas consid´er´ee comme sensiblement meilleure.
Cette situation nous a amen´e ainsi que notre organisme d’accueil `a savoir BFI `a impl´ementer
une solution d´ecisionnelle afin d’am´eliorer son processus de prise de d´ecision. Ainsi, c’est dans
ce cadre que nous avons entam´e notre projet de fin d’´etudes qui a ´et´e propos´e afin d’impl´ementer
une nouvelle fonctionnalit´e au sein de la solution Megara-Forex de BFI et de mettre en place une
plateforme d´ecisionnelle qui va servir `a collecter et optimiser la pr´esentation des donn´ees relatives
`a toutes les op´erations financi`eres notamment celles qui se rapportent aux changes de devises.
Afin de r´ealiser ce syst`eme nous allons adopter la m´ethodologie Gimsy afin de pouvoir opti-
miser le d´ecoupage de notre cahier de charges en tˆaches claires.
Notre rapport sera d´ecoup´e en quatre chapitres suivant lesquels sera impl´ement´ee notre solution
et qui seront pr´esent´es comme suit :
La pr´esentation de l’organisme d’accueil et l’´etude de l’existant fera l’objet du premier chapitre
ainsi nous aurons une id´ee sur les principales probl´ematiques et les solutions `a proposer avant de
pouvoir choisir la m´ethodologie adopt´ee.
Le second chapitre fera l’objet de la phase de d´emarrage du projet au cours de laquelle nous
allons pr´esenter le domaine de l’informatique d´ecisionnelle ainsi que ses notions th´eoriques et
choisir les outils que nous allons utiliser `a travers des ´etudes comparatives.
1

15. Le troisi`eme chapitre pr´esentera la partie impl´ementation des fonctionnalit´es `a ajouter au sein
de la solution Megara-Forex `a travers l’analyse, la conception et l’impl´ementation de ces derni`eres.
Le quatri`eme et dernier chapitre sera consacr´e `a la partie d´ecisionnelle de notre projet et il
servira en premier lieu `a identifier les indicateurs de performance cl´es de notre projet suivi de la
pr´esentation des maquettes des tableaux de bords puis du traitement des donn´ees en utilisant la
solution ETL `a choisir pour enfin finir avec l’exposition des tableaux de bords r´ealis´es.
2

16. Chapitre 1
Cadre g´en´eral du projet
3

17. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
Introduction
Le pr´esent chapitre sera d´edi´e `a la pr´esentation de l’organisme d’accueil en l’occurrence la
banque finance international (BFI) et `a ses principaux domaines d’activit´e.
1 Pr´esentation g´en´erale de l’organise d’accueil
1.1 Historique de BFI
Le Groupe a d´emarr´e ses activit´es sur le march´e tunisien en 1994 avec une mission principale
qui consiste `a ´equiper la totalit´e des interm´ediaires en Bourse ensuite les salles des march´es des
banques en 1997 `a travers une large panoplie de solutions servant `a couvrir les activit´es de gestion
de la totalit´e des op´erations sur les march´es de capitaux.
Au cours des ann´ees 1999-2000, notre organisme l’accueil a mis en œuvre l’un de ses premiers
projets structurant avec la Banque Centrale de Tunisie (BCT) `a savoir le syst`eme de compensation,
et a enchaˆın´e avec plusieurs autres solutions comme le syst`eme de virement gros montants, RTGS.
La mise en place du syst`eme de compensation a offert l’opportunit´e `a BFI de s’ouvrir `a
l’´echelle internationale notamment avec la banque des Etats d’Afrique Centrale (banque centrale
r´egionale de 6 pays) au sein de laquelle la soci´et´e a impl´ement´e le premier syst`eme de compen-
sation r´egionale. En plus de cela, elle a continu´e ses activit´es avec le Madagascar et les 4 pays de
l’Afrique de l’Ouest anglophone (Guin´ee Conakry, Sierra Leone, Gambie et Liberia).
La philosophie du groupe consistait `a aborder les banques africaines `a travers ce partenariat
avec les Banques Centrales ce qui a permis `a BFI d’entrer en contact avec les banques pour voir
ce qui manquait `a leurs syst`emes d’information et c’´etait le point de d´epart de la r´eflexion de
constitution de son propre Core Banking dans une approche modulaire.[1]
1.2 Pr´esentation de BFI
Int´egrateur et ´editeur de plusieurs solutions informatiques financi`eres depuis 1994, BFI consti-
tue un partenaire strat´egique pour accompagner ses clients afin de moderniser leur syst`eme d’in-
formation.
Le groupe est pr´esent dans plus que 200 institutions financi`eres dans 25 pays `a travers le conti-
nent africain.
La figure 1.1 pr´esente les principales missions de BFI :
4

18. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
FIGURE 1.1 – Services de BFI
1.3 Solutions de BFI
Le groupe BFI offre une large gamme de solutions `a ses clients couvrant la totalit´e de leurs be-
soins en mati`ere de syst`emes d’information front et back-end ainsi que tous les m´etiers bancaires :
gestion du r´ef´erentiel, reporting r´eglementaire, gestion des engagements, march´e des capitaux,
op´erations et agence, bancaire ´etranger, tr´esorerie et ALM, moyens de paiement, maˆıtrise des
risques, comptabilit´e, la banque digitale,etc.
Ceci permet ainsi aux clients de disposer d’un syst`eme d’information `a la hauteur des attentes
en termes d’enjeux strat´egiques.
Ainsi, BFI a r´eussi `a construire son catalogue de solutions autour de trois axes essentiels du
domaine de la banque et de la finance : le Global Banking urbanis´e qui sert `a couvrir la globalit´e
des m´etiers de la banque, les syst`emes de place et les activit´es de march´es.
Grˆace `a des investissements d’une importance capitale, la soci´et´e s’est donn´ee une certaine
souplesse aussi bien sur le plan de r`eglementation que celui du besoin d’int´egration de nouveaux
aspects, notamment la partie digitale.
BFI est de ce fait capable d’automatiser tous les processus de la banque `a travers son moteur
de flux de travail bas´e sur les normes BPMN2.0 ce qui a permis aux clients de s’ouvrir encore plus
sur le domaine du digital dans une approche omnicanale.
1.3.1 Global banking
La Solution Global Banking de BFI, baptis´ee ” Carthago ”, consiste en un global, hautement
s´ecuris´e et modulaire couvrant l’ensemble des m´etiers des banques et institutions financi`eres.
Elle est munie d’une architecture performante et solide, conforme aux standards JEE et orient´ee
services.
• Carthago-R´ef´erentiel
Le Module Carthago-R´ef´erentiel constitue un point d’acc`es unique, centralis´e et parta-
5

19. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
geable avec l’ensemble des modules m´etiers de la banque, pour g´erer essentiellement trois
types d’informations :
- La nomenclature bancaire (devises, pays, calendriers, taux, etc...) & l’organisation de
la banque (d´epartements, centres de responsabilit´e, structures, agences, organigramme,
etc...).
- Les donn´ees appartenant aux clients et tiers en relation avec la banque (personnes mo-
rales, personnes physiques, banques, etc...), ainsi que les parties prenantes dans le cadre
de ces relations (mandataires, prospects, clients, actionnaires, avocats, fournisseurs, no-
taires, etc...).
- Les informations relatives au catalogue des produits et services offerts par la banque
ainsi que des conditions g´en´erales et particuli`eres de tarification et de fonctionnements
de ces produits et services.[2]
• Gestion des op´erations de la banque
La solution Carthago offre un ensemble de modules m´etiers `a haute valeur ajout´ee pour
la gestion de la tr´esorerie de la banque (locale, devise, correspondants), la gestion de la
salle des march´es, la gestion des ressources de la banque et leur mobilisation et finalement
la gestion ALM et pilotage des risques march´e.
◦ Carthago-Tr´esorerie
Le Module Carthago-Tr´esorerie permet de suivre en temps r´eel la tr´esorerie de l’ins-
titution financi`ere, ainsi que ses op´erations sur le march´e interbancaire :
- Gestion de la tr´esorerie pr´evisionnelle et r´eelle.
- Gestion des op´erations de prˆets/emprunts interbancaires et des op´erations de place-
ments (certificats de d´epˆots, billets de tr´esorerie, etc...).
- Gestion des lignes de cr´edits internes et externes.
◦ Carthago-SDM
Le Module Carthago-SDM permet de g´erer les op´erations de change `a terme (Desk
Change `a terme), des op´erations de change au comptant (Desk Comptant) sans oublier
les op´erations sur les produits d´eriv´es (Desk d´eriv´es), comme moyens de couverture des
risques de change et de taux courus.
◦ Carthago-ALM
Le Module Carthago-ALM permet de g´erer l’´equilibre emplois/ressources et de
piloter les risques relatifs aux diff´erents march´es `a travers l’adoption des TDB ALM,
bas´es sur des sc´enarii qui portent sur un ensemble d’hypoth`eses param´etrables telles
que :
6

20. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
- Hypoth`eses d’adossement des emplois aux diff´erentes ressources.
- Hypoth`eses d’anticipations/pr´epaiement.
- Hypoth`eses sur le rythme d’´ecoulement des rubriques non contractuelles.
- Etc...[3]
• Gestion des op´erations de la client`ele
La solution Carthago offre un ensemble de modules m´etiers permettant la gestion de
l’ensemble des op´erations de la client`ele quelques soient leurs natures :
- Les op´erations Agence et la gestion des Moyens de Paiements
- Les op´erations de suivi du recouvrement
- Les op´erations de contentieux et de recouvrement judiciaire
- Les op´erations sur les engagements donn´es ainsi que la gestion des garanties rec¸ue
- Les op´erations relevant du domaine Bancaire-Etranger
◦ Placements de la client`ele, Agence et Moyens de paiements :
Le module Carthago-DAVE (gestion des D´epˆots A Vue et Epargne), offre une
gestion facile et globale des assets des clients (d´epˆots, ´epargnes, etc.), des op´erations
de guichet et d’arri`ere-guichet, sans oublier les op´erations applicables dans le cadre
des moyens de paiements compensables (Ch`eques et Effets ,Virements, Pr´el`evements),
ceci en tenant compte des r´eglementations de compensation, en y mettant en place les
op´erations de scann´erisation des valeurs compensables `a partir d’une seule et unique
plateforme.
Le module Carthago-Placements , offre une gestion des placements des clients en
utilisant les Bons de caisses, DAT et autres solutions de placements.
◦ Gestion des Engagements donn´ees et des Garanties rec¸ues :
La solution Carthago-Engagements , permet la gestion et le contrˆole des engagements
donn´es aux clients, ainsi que pour le financement des entreprises et le financement des
particuliers.
A cet effet, la solution Carthago-Engagements englobe plusieurs sous-modules au-
tonomes et parfaitement int´egr´es cadrant un bus applicatif, ainsi elle offre une large pa-
noplie de processus m´etiers Front to Back pour la gestion des engagements donn´es
`a la client`ele :
- Carthago-Instruction : Est une solution qui permet la gestion des processus d’ins-
truction des requˆetes de financements en commenc¸ant par le d´epˆot du dossier du
client en passant par les ´etapes d’octroi et de mises en place.
7

21. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
- Carthago-Cr´edits : Offre la possibilit´e de g´erer l’ensemble des cr´edits propos´es
aux clients, que ce soit sur les Cr´edits-Amortissables , Les Cr´edits en Pool
, les Cr´edits-Bails , etc. commenc¸ant par leur mise en place jusqu’`a leur ex-
tinction. Cela int`egre la gestion des actions m´etiers qui puissent se produire durant
leurs cycles de vies (Ren´egociations, Remboursements Anticip´es, R´eam´enagements,
R´e´echelonnements, etc...).
- Carthago-EPS : Ce module permet la gestion de l’ensemble des engagements par
signatures donn´es par la banque, ainsi que la gestion de l’ensemble des ´ev`enements
m´etiers survenant durant leurs cycles de vies (Tirages, Main Lev´ees, Mises En Jeu,
Etc...).
- Carthago-Portefeuille : Est un module qui permet de g´erer des portefeuilles effets
des clients ainsi que la gestion des lignes d’escomptes sous-jacentes.
◦ Bancaire ´Etranger : Carthago-COMEX est un outil qui offre une gestion simple et
efficace des op´erations issent du domaine Bancaire Etranger , dans le contexte du
financement et accompagnement des clients exportateurs et importateurs des banques.
Du coup, la solution Carthago-COMEX contient une multitude de sous-modules
autonomes
- Gestion des cr´edits documentaires import et export.
- Gestion des encaissements documentaires.
- Gestion des transferts internationaux.
- Gestion des domiciliations.
- Gestion des circuits documentaires import et export.
◦ Recouvrement et Contentieux :La solution Carthago int`egre deux sous-modules
permettant de faciliter de g´erer les op´erations financi`eres et de mise en contentieux. Ces
processus peuvent ˆetre configur´es par les utilisateurs pour ˆetre d´eploy´es automatique-
ment afin d’apparaˆıtre de fac¸on automatique sur les Tableaux de bords des Agents de
Recouvrements.
Les ex´ecutions des tˆaches inh´erentes aux processus de recouvrement se font selon des
flux param´etrables ax´es sur les composants d’automatisation des diagrammes BPM.
Les processus de mise en contentieux et de recouvrement judiciaires sont eux aussi
couverts par les composants cit´es, permettant toujours de savoir tous les allers-retours
des dossiers en contentieux, ainsi que du suivi des frais de recouvrements engag´es, et
des flux des garanties.
8

22. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
◦ Vision Globale Client : Le module Carthago-Vision-Globale-Client permet la cen-
tralisation et la consolidation en temps r´eel de l’ensemble des informations relatives `a
un client afin d’offrir une vue compl`ete de sa situation au niveau de la banque.
Cette vue 360, est personnalisable `a souhait, pour inclure l’ensemble des donn´ees que la
banque juge n´ecessaires.
La solution Vision-Globale-Client, int`egre optionnellement la gestion des processus
d’entr´ee en relation, KYC, et la gestion de la relation client dans sa globalit´e.[4]
• Finances et Activit´es de Contrˆoles
La solution Carthago offre un ensemble de modules m´etiers permettant la gestion des
activit´es de contrˆoles et de suivi des finances de la banque, traitant de domaines m´etiers
de comptabilit´e g´en´erale, analytique et budg´etaire ainsi que la gestion du risque cr´edits, du
risque op´erationnel et de la conformit´e aux normes IFRS.
◦ Carthago-Compta : est un module qui permet une gestion multiplans de comptes,
multidevise, multi-cl´es comptables, multi-entit´es, multi-p´eriodes comptables en assurant
trois fonctionnalit´es majeures : L’interpr´etation comptable, la trac¸abilit´e comptable et la
gestion des ´editions (d´eclarations fiscales, ´etats comptables, statistiques, ´etats financiers,
etc).
◦ Carthago-R´eglementaire : Sert `a param´etrer et `a g´erer automatiquement les ´etats r´eglementaires,
sur la base d’une alimentation p´eriodique d’informations comptables et extracomptables,
ceci en v´erifiant les contrˆoles d’´egalit´e entre les encours comptables et les encours de
gestion, pour assurer in fine le calcul des corr´elations et la production des d´eclarations
r´eglementaires en permettant leur audit et trac¸abilit´e afin de pouvoir les historier et re-
produire.
◦ Carthago-Budget : La gestion des budgets est r´ealis´ee par le module Carthago-Budget
qui permet l’automatisation des flux de construction du budget pluriannuel, selon di-
vers axes d’analyses (cl´e budg´etaires) configurables. Le processus de validation du bud-
get est r´ealis´e de mani`ere participative Bottom-up . Carthago-Budget garanti
aussi l’imputation automatique des r´ealisations `a partir des diff´erents modules m´etiers et
de la comptabilit´e g´en´erale, en assurant la r´epartition de certaines r´ealisations sur les ru-
briques budg´etaires en utilisant des cl´es de r´epartitions configurables. Enfin, Carthago-
Budget propose des TDB permettant le suivi en temps r´eel avec une analyse multiaxe
des actions et des ´ecarts avec les budgets arrˆet´es.
◦ Carthago-Analytique : Le module Carthago-Analytique assure la gestion des donn´ees
financi`eres de la banque afin de quantifier la Rentabilit´e de ses activit´es en passant
par plusieurs axes d’analyse.
9

23. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
Il se base sur une collecte de donn´ees (intrants) `a partir la comptabilit´e g´en´erale et des
modules m´etiers, dans le but des r´e analyser et calculer les r´esultats analytiques.
Il constitue, de ce fait, un v´eritable outil de gestion et de pilotage pour la banque. En
outre, et grˆace `a un traitement des donn´ees en temps r´eel, Carthago Analytique permet
d’offrir une vision pointue et en temps r´eel de chaque axe analytique (client, centre de
responsabilit´e, produit, contrat, groupe de clients, activit´e, etc.)
Enfin, l’objectif vis´e de la comptabilit´e est de d´ecouper la vision de la banque afin de
mettre en relief la participation des axes d’analyses.
◦ Carthago-IFRS : C’est un module permettant de maintenir une comptabilit´e IFRS, adap-
table aux standards internationaux, en visant l’utilisation des diff´erentes normes IAS/IFRS
mises en place. De ce fait, le module IFRS se base sur la balance comptable selon le
plan de compte conventionnel, les donn´ees m´etiers n´ecessaires pour l’ensemble des re-
traitements relatifs `a la classification des actifs et passifs financiers, aux calculs des
d´epr´eciations conform´ement `a la norme IFRS 9, etc....
La module Carthago-IFRS permet de maintenir des sessions de d´eclaration IFRS
p´eriodique en garantissant les op´erations d’historisation et de reproduction des ´etats
IFRS g´en´er´es, ainsi que la piste d’audit des retraitements effectu´es.
◦ Carthago-Risque Cr´edit : Le module Carthago-Risque Cr´edit propose les op´erations
de manipulation n´ecessaires en termes d’´evaluation des engagements de la banque et du
risque de cr´edit. La maˆıtrise du risque de cr´edit se base sur les composants suivants :
- La gestion du Scoring/Rating des Clients et le calcul de la provision `a caract`ere
g´en´eral (calcul de l’actif net pond´er´e et la r´eservation des fonds propres).
- La gestion des limites autorisations (r´eglementaires et sp´ecifiques `a la banque)
- La gestion des analyses financi`ere pour l’´evaluation de la sant´e financi`ere de la
client`ele corporative.
- La gestion de la classification des contrats et calcul de la provision sur les cr´eances
impay´ees, douteuses et contentieuses
◦ Carthago-Risque Op´erationnel : Le module Carthago-Risque Op´erationnel permet
de g´erer l’ensemble des risques op´erationnels au sein d’une banque ou institution fi-
nanci`ere. Il permet ´egalement la constitution et le suivi d’une base d’incidents, ou les
incidents sont cat´egoris´es conform´ement `a une typologie telle que sp´ecifi´e au niveau des
normes bˆaloise.
La r´ealisation des incidents se fait soit de mani`eres manuelle (via simple saisie) ou `a
travers l’alimentation automatique `a partir de d´etection de retards d’ex´ecution de tˆaches
10

24. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
dans le cadre des diff´erents flux m´etiers de la banque. Les types d’accidents seront en-
suite cat´egoris´es selon leur fr´equence et leur gravit´e.
L’ensemble des incidents sont pilot´es via un processus de validation permettant de diff´erentier
entre les incidents justifi´es et ceux non justifi´es. Les incidents non justifi´es seront de
ce fait utilis´es pour l’estimation de calcul de perte selon deux m´ethodes (la m´ethode
avanc´ee et la m´ethode standard).[5]
• Moyens de Paiement
La solution Carthago int`egre un ensemble de modules qui permettent de g´erer les
op´erations sur les march´es de capitaux (march´e primaires et march´e secondaires) avec une
couverture globale de la totalit´e du cycle de d´enouement de l’ensemble des op´erations.
◦ Carthago-Titres : Le Module Carthago-Titres est un progiciel qui est sp´ecialis´e dans
le m´etier titres et bourse en englobant tous ses aspects. Il g`ere notamment les op´erations
sur Le march´e primaire (traitement des ordres en bourse, transactions de bourse, ins-
tructions client`ele, gestion des OST) le march´e secondaire (gestion des OPV) avec les
aspects Front/Back Office et suivant les r´eglementations en vigueur.
Il propose de plus la gestion des portefeuilles titre, des porteurs de part (souscrip-
tions/rachats par OPCVM) et des ´emissions (actions et obligations).
Carthago-Titres assure plusieurs services compl´ementaires tels que : reporting,
comptabilit´e mati`ere et esp`ece, et Bourse en ligne (site web pour l’activit´e bourse), Swift
(envoi et r´eception), ESB (module d’interfac¸age), Carthago-Trading (interface avec
la bourse selon le protocole FIX).
◦ Carthago-OPCVM : Le Module Carthago-OPCVM est un progiciel de gestion
int´egr´e sp´ecialis´e dans les services OPCVM qui a pour vocation la gestion d’OPCVM
pour les gestionnaires de fonds ou bien le contrˆole de gestionnaires d’OPCVM (admi-
nistration et comptabilit´e) pour les services de contrˆole. Il g`ere les op´erations de l’ad-
ministration et de comptabilit´e, des op´erations simples et structur´ees sur l’ensemble des
march´es financiers.
Les fonctionnalit´es permettent, outre le calcul de la valeur liquidative et la tenue de
la comptabilit´e, de suivre les contraintes r´eglementaires, d’effectuer des simulations de
calcul des valeur liquidatives et de restituer l’information aux services OPCVM. Le
Module Carthago-OPCVM est multi-march´es et multi-portefeuilles. Tout ceci en
r´epondant aux exigences d’´evolution des services OPCVM.
◦ Carthago-SVT : Le Module Carthago-SVT Le recours accru du Tr´esor aux march´es
mon´etaires et financiers et le suivi des r´eformes applicables `a l’organisation des march´es
11

25. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
conf`erent aux march´es des valeurs du Tr´esor une tˆache d’innovation et d’entraˆınement
dans le cadre de la r´enovation de la place financi`ere.[6]
Cette ´evolution augmente les risques de cette activit´e. Simultan´ement, elle entraˆıne l’ac-
croissement du volume des op´erations et donc leurs coˆuts. Carthago-SVT est la
solution de BFI pour faire face aux diff´erents d´efis possibles. Pour g´erer une journ´ee
de Sp´ecialiste en Valeurs de Tr´esor, la solution englobe les fonctionnalit´es n´ecessaires
suivants :
- La gestion des op´erations sur les march´es (adjudications) et secondaire (transactions
et instructions client`ele, refinancement...),
- La simulation des acquisitions et des cessions des valeurs de Tr´esor,
- La gestion de comptes propres et client`eles,
- La gestion des OST,
- Comptabilisation,
- La r´e´evaluation de la position titres,
- Reporting
• Gestion des Moyens G´en´eraux
Dans le cadre de la gestion des moyens g´en´eraux, la solution Carthago propose deux
modules :
- Carthago-Immobilisations : Carthago-Immobilisations assure la gestion des immo-
bilisations avec un suivi `a partir de leurs entr´ees dans l’actif de la banque jusqu’`a leurs
sorties de son patrimoine. Il supporte les fonctionnalit´es suivantes :
- Gestion des acquisitions et des sorties des immobilisations (Cession, Mise au rebut,
Perte ou vol et Echange) avec un passage automatique d’un statut `a un autre;
- Restitution des ´etats du patrimoine par type d’immobilisation, par nature, par famille,
par centre d’affectation, etc. tout en offrant vue globale et d´etaill´ee sur l’ensemble des
donn´ees et op´erations de chaque immobilisation.
- Calcul des amortissements (selon des p´eriodicit´es param´etrables), des dotations aux pro-
visions, des reprises, etc.
- Gestion des stocks.
- Gestion des avances sur les immobilisations en cours.
- Gestion des d´epenses post´erieures.
- Carthago-Achats-Stocks : Ce module assure la gestion des processus des d´epenses.
ainsi que la gestion des stocks. Il supporte les fonctionnalit´es suivantes :
- Gestion des expressions des besoins d’achat avec une r´eservation budg´etaire automa-
tique.
12

26. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
- R`eglement des avances et des factures.
- Gestion demandes d’engagement avec un engagement budg´etaire automatique.
- Gestion des supports d’engagement.
- Gestion des avances.
- Gestion des demandes de devis et enregistrement des devis retenus.
- Gestion des r´eceptions.
- Enregistrement des factures avec impact automatique des r´ealisations.[7]
1.4 Organigramme de BFI
Le groupe BFI est command´e par la direction g´en´erale compos´ee elle-mˆeme par le directeur
g´en´eral et ses chefs des directions en collaboration avec les managers.
La figure 1.2 pr´esente l’organigramme de l’organisme d’accueil `a savoir BFI :
FIGURE 1.2 – Organigramme g´en´eral de BFI
- Pˆole commercial : Veille `a la commercialisation des services offerts aux particuliers.
- Pˆole secr´etariat g´en´eral : Abrite les fonctions supports comme les bˆatisseurs, les n´egociateurs
et les services veillant `a la s´ecurit´e de la banque.
- Pˆole support et op´erations : S’occupe des traitements des dossiers des clients et assure le
recouvrement des cr´eances douteuses.
- Pˆole entreprises : Commercialise les produits et les services aux entreprises et aux banques.
13

27. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
2 ´Etude de l’existant
Cette section nous permettra d’analyser le syst`eme actuel de notre organisme d’accueil avant
de d´etailler les probl`emes ´eventuels et les solutions qui peuvent y rem´edier.
2.1 Analyse de l’existant
Comme pour la plupart des grandes entreprises, le pˆole support client et op´erations joue un
rˆole tr`es important dans la partie d´eveloppement et m´etiers de l’organisme.
Dans le cas d’une ´etude ou d’une analyse nos client se retrouvent forc´ees d’utiliser le tableau
Excel pour d´eterminer les chiffres et les analyses des op´erations et module avec une quantit´e
importante des donn´ees.
Pour faire une analyse l’agent passe par les ´etapes suivantes :
- Acc´edez au module
- Acc´edez au masque
- Extraire les r´esultats sous format Excel
- Appliquez les r`egles et les formules
Cette proc´edure donne naissance `a de fausses analyse et fausses d´ecisions chez nos clients.
2.2 Probl´ematique
La solution existante consiste `a cr´eer des tableaux Excel contenant des analyses mais celles-ci
n’offrent pas une plateforme d´ecisionnelle centralis´ee servant `a collecter les donn´ees n´ecessaires
pour la r´ealisation des tableaux de bords de statistiques pouss´ees en se basant sur des indicateurs
de performance cl´e.
En effet, les utilisateurs de la partie back office des modules ont g´en´eralement tendance `a se
mettre en difficult´e pour g´en´erer des analyses sur leur ´etat actuel.
Ceci est dˆu au fait que les donn´ees sont bien pr´esentes mais elles ne sont pas trait´ees ni pour les
bonnes causes ni aux bons moments. Ceci engendre plusieurs anomalies potentielles telles que :
- L’impossibilit´e de r´ealiser des tableaux de bords.
- Les donn´ees ne sont pas accessibles qu’`a partir des masques des modules Megara-Forex.
- Les op´erations `a appliquer sur les donn´ees sont tr`es difficiles `a r´ealiser et parfois impos-
sibles.
- Les statistiques sont parfois impossibles `a r´ealiser du fait de la nature et la diversit´e des
sources de donn´ees qui vont servir aux rapprochements et aux audits.
14

28. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
2.3 Solution propos´ee
Afin de pouvoir ´eviter les probl`emes du syst`eme existant nous proposons de mettre en place et
d’impl´ementer un nouveau syst`eme d´ecisionnel qui aura pour but de :
- Rendre accessibles les informations relatives aux modules Megara-Forex
- Constituer la base d´ecisionnelle des d´ecideurs
- Baser les r´esultats des tableaux de bords sur les calculs des indicateurs de performance pour
optimiser les r´esultats.
3 Analyse du projet
3.1 Description du projet
3.1.1 Contexte du projet
Avant que BFI investisse dans un projet de syst`eme d’information d´ecisionnel existant n’offrait
pas la chance de r´ealiser des rapports et des tableaux de bords qui soient interactifs impliquant
plus de fluidit´e dans les processus d’aide `a la prise de d´ecision. Il ne comportait pas ´egalement
des fonctions d’historisation des diff´erentes op´erations ce qui ne faisait pas de lui une plateforme
centralis´ee.
Ceci a pouss´e BFI `a penser `a la cr´eation d’une application d’aide `a la d´ecision regroupant
l’ensemble des fonctionnalit´es qui se rapportent aux op´erations faites dans Megara-Forex `a tra-
vers le d´eveloppement de tableaux de bords optimisant l’affectation des diff´erentes ressources qui
interviennent dans ce processus.
C’est dans cette optique que BFI nous a propos´e la mission de concevoir et mettre en place une
base d´ecisionnelle accordant la possibilit´e de g´erer, suivre et optimiser l’ensemble des tˆaches com-
posant les fonctionnalit´es du Megara-Forex en adoptant l’approche de l’informatique d´ecisionnelle.
3.1.2 Objectifs du projet
Le projet a pour objectif principal de d´evelopper des interfaces de manipulations des op´erations
SPOT et Tr´esorerie Devise au sein de la banque et d’offrir une vue d´etaill´ee sur l’avancement des
ressources impliqu´es dans les op´erations bancaire faites sur Megara-Forex.
3.2 Analyse des risques
Afin de pouvoir impl´ementer notre projet de fac¸on optimis´ee et dans le but de bien nous
pr´eparer `a la totalit´e de ses phases, nous proc´ederons `a l’identification des diff´erents risques que
15

29. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
nous essayerons de franchir lors de notre r´ealisation.
Le tableau 1.1 pr´esente l’´evaluation des risques de notre projet :
1 : Tr`es faible 2 : Faible 3 : Moyen 4 : ´Elev´e 5 : Tr`es ´elev´e
Importance
du risque
Description de l’´etape Strat´egie de r´ealisation
3 Les modifications : Des adaptations peuvent
nous ˆetre demand´ees durant ou apr`es la
r´ealisation des tableaux de bords.
Additionnellement, on peut nous demander
de nouvelles sp´ecifications mˆeme en plein
d´eveloppement.
Choisir un mod`ele fluide `a
impl´ementer afin de r´eagir aux
demandes impr´evues.
4 Difficult´e technique : Vue le manque
d’exp´erience en termes de manipulation des
environnements de r´ealisation des projets
D’informatique d´ecisionnelle, sans oublier
le domaine en lui-mˆeme. Plusieurs nou-
velles notions doivent ˆetre acquises pour la
r´ealisation des tableaux de bords.
De ce fait nous allons pr´evoir un d´elai addi-
tionnel pour la phase de r´ealisation.
Documentation sur le domaine
du BI ainsi que sur les envi-
ronnements techniques. R´ealiser
un cas d’utilisation simplifie pour
nous familiariser avec les outils de
r´ealisation.
R´ealiser un cas d’utilisation sim-
plifi´e pour nous familiariser avec
les outils de r´ealisation.
3 Interfac¸age : La r´ealisation de la jointure
entre l’ERP Delta et l’application Megara Fo-
rex avec ses diff´erents modules avec deux
SGBD diff´erents (Oracle, SQL Server) afin
de pouvoir extraire des informations crois´ees
avant de les int´egrer dans le DW.
Demande de la structure exis-
tante des deux bases pour pou-
voir respecter leurs sch´emas. Tes-
ter l’avancement sur un environ-
nement semblable `a l’environne-
ment de production au fur et `a me-
sure.
TABLE 1.1 – ´Evaluation des risques du projet
3.3 P´erim`etre du projet
La section suivante fait l’objet de la port´ee du p´erim`etre de notre r´ealisation qui doit n´ecessite
d’ˆetre mise en place, de ce fait notre syst`eme doit se bˆatir selon les piliers suivants, ceci dans le
but d’ˆetre en phase avec la sp´ecification qui rec¸ue de la part de BFI :
16

30. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
- La mise en place d’une source fluide et robuste des donn´ees rec¸ues `a partir des applications
Megara-Forex.
- La construction d’une base d´ecisionnelle utilisable par l’entreprise.
- Interpr´etation des donn´ees stuqu´ees dans les bases des applications.
- Conception et impl´ementation des tableaux de bords.
3.4 Besoins non fonctionnels
Notre syst`eme sera d´evelopp´e de mani`ere `a assurer les besoins non fonctionnels suivant orient´es
vers ses utilisateurs.
La solution permettra d’assurer ces besoins non fonctionnels :
• Fiabilit´e : Nous devons mettre en place une zone de stockage temporelle entre les sources
et la base du syst`eme pour minimiser le risque de perte de donn´ees en route.
• Ergonomie : Le syst`eme que nous allons impl´ementer doit ˆetre offrir un bon placement des
composants et widgets avec des couleurs et polices claires et facilement interpr´etables par
les utilisateurs finaux afin de faciliter l’exp´erience utilisateur de la solution.
• Performance et extensibilit´e : Les outils que nous allons utiliser pour la r´ealisation de notre
syst`eme doivent ˆetre robustes et permettent de pouvoir optimiser les temps de traitement
des donn´ees en des temps courts.
4 Choix de la m´ethodologie
Une bonne m´ethodologie de d´eveloppement contribue consid´erablement au succ`es d’un projet
D´ecisionnel.
Pourtant, on ne peut pas vraiment affirmer que les projets d´ecisionnels une fois achev´es soient
de franches r´eussites. Par manque de m´ethode adapt´ee, trop de projets s’av`erent de v´eritables
´echecs en termes de r´eponse aux attentes des utilisateurs.
De ce fait on a d´ecouvert les m´ethodologies pour fluidifier les processus m´etiers et optimiser
les besoins et les tˆaches r´ealis´es.
Le r´esultat est une BI plus flexible et plus efficace qui permet `a l’organisation se positionner
sur une tendance de constante ´evolution.
Dans cette optique nous avons d´ecid´e de choisir une m´ethodologie avant de commencer notre
r´ealisation afin de pouvoir analyser et impl´ementer les besoins demand´es.
En ce qui concerne le secteur de l’informatique d´ecisionnelle, les m´ethodologies les plus
connues sont :
17

31. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
• La m´ethode Business Dimentional Lifecycle de Ralph Kimball : Cette m´ethodologie a
´et´e invent´ee par Ralph Kimball dans les ann´ees 1980 par des membres du Kimball Group.
Ralph Kimball est l’un des architectes les plus renomm´es dans le monde des technolo-
gies de donn´ees. Ses directives pour concevoir un entrepˆot de donn´ees, souvent appel´e
m´ethodologie Kimball, sont devenues l’une des m´ethodes les plus suivies par les experts
techniques dans la construction d’un syst`eme d’aide `a la d´ecision dans toute l’organisation.
La m´ethodologie Kimball est destin´ee `a la conception, au d´eveloppement et au d´eploiement
de syst`emes d’entrepˆot de donn´ees / d’intelligence d’affaires, comme d´ecrit dans The Data
Warehouse Lifecycle Toolkit. Il y a d’autres noms pour l’approche Kimball dont nous dis-
cuterons sous peu.
- Approche ascendante pour l’entreposage de donn´ees
- Mod´elisation dimensionnelle de Kimball
- Mod`ele de cycle de vie de l’entrepˆot de donn´ees par Kimball
R´esum´e de la m´ethodologie Kimball.
- Commence avec un data Mart (ex. Ventes); plus tard, des magasins de donn´ees suppl´ementaires
sont ajout´es (ex. collecte, marketing, etc.)
- Les donn´ees circulent de la source vers les data marts, puis vers l’entrepˆot de donn´ees
- L’approche Kimball est plus rapide `a mettre en œuvre car elle est mise en œuvre par
´etapes
Le succ`es du projet d´epend d’une solide compr´ehension des exigences de l’entreprise. Com-
prendre les facteurs cl´es de l’entreprise est essentiel pour r´eussir `a traduire les exigences de
l’entreprise en consid´erations de conception...
L’approche Kimball Lifecycle est illustr´ee dans le diagramme suivant. Il fournit une feuille
de route globale d´ecrivant la s´equence des tˆaches de haut niveau requises pour la r´eussite
des projets DW / BI.
La figure 1.3 pr´esente le cycle de la m´ethodologie de Ralph Kimball :
18

32. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
FIGURE 1.3 – Diagramme de cycle de vie de Ralph Kimball
• La m´ethode AgileBI : La Business Intelligence agile est une m´ethode productive de travail
en cycles courts, qui est le fruit de plusieurs crit`eres et qui est `a l’inverse de la m´ethode
classique qui demande davantage de temps pour la mise en application. Elle est caract´eris´ee
par des it´erations simplifi´ees de la gestion de projet pour en optimiser les avanc´ees, ainsi
que des r´esultats visibles en quasi-instantan´eit´e.
Dans le cadre d’un processus classique, le projet de Business Intelligence se d´eroule ´etapes
apr`es ´etapes, et ne fournit les premiers r´esultats qu’apr`es avoir franchi toutes les ´etapes. A
l’inverse, la BI agile propose une strat´egie dont les premiers r´esultats commencent `a ˆetre
perc¸us plus rapidement. Le mod`ele est ensuite enrichi progressivement.
La figure 1.4 pr´esente le diagramme de la m´ethodologie Agile BI :
19

33. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
FIGURE 1.4 – Cycle de vie Agile BI
• La m´ethode GIMSI G´en´eralisation Information M´ethode Syst`eme Individualit´e :
Le tableau de bord est un moyen strat´egique qui nous permet d’avoir une visibilit´e sur l’activit´e
de l’entreprise sur le long et moyen terme, il nous assure une vision coh´erente par rapport aux
objectifs et une mesure des performances en fonction des informations pertinentes qui nous aide
`a la prise de d´ecision.
Structur´ee en 10 ´etapes, la m´ethode est construite sur un principe de gouvernance g´en´eralis´ee
favorisant la prise de d´ecision distribu´ee en multipliant les preneurs de d´ecisions et leurs empla-
cements afin de favoriser la coop´eration entre les d´ecideurs et le partage de leurs connaissances
respectives. [8]
Chacune des 10 ´etapes traite une ´etape distinctive d´ecrivant un seuil bien d´etermine dans la
r´ealisation du projet.
Etape 1 : Environnement de l’entreprise
Cette ´etape consiste `a l’observation des sp´ecificit´es de l’entreprise en terme de (manage-
ment, environnement, produits, ressources, services) et l’´etude de sa d´emarche strat´egique.
Etape 2 : Identification de l’entreprise
20

34. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
Cette ´etape constitue une Analyse d´etaill´ee des m´etiers de l’entreprise et de ses processus
critiques concern´es par le projet ainsi de ses activit´es pour d´egager les fonctions critiques `a
cibler.
Etape 3 : D´efinition des objectifs
Action simultan´ee pour identifier et choisir les objectifs `a suivre pour atteindre les bonnes
finalit´es. En r´esultat, chaque groupe de travail dispose de la description de ses quelques
objectifs de progr`es.
Etape 4 : Conception de tableau de bord
Au cours de cette deuxi`eme ´etape de conception, il faut choisir les m´ethodes a adopter pour
r´ealiser les tableaux de bords afin de supporter les preneurs de d´ecision de fac¸on efficiente.
Etape 5 : Choix des indicateurs
Identification des KPIs : chaque indicateur sera caract´eris´e et ´evalu´e en compagnie des
d´ecideurs afin de disposer des indicateurs pertinents en fonction de ses objectifs de progr`es.
Etape 6 : Collecte des informations
Aller en reconnaissance et r´eunir les informations requises pour le pilotage des d´ecisions.
Cette phase est la plus importante pour bˆatir les indicateurs et utilise des outils de type ETL
lors de sa r´ealisation.
Etape 7 : le syst`eme de tableau de bord
Partager les connaissances extraites et ´echanger les informations construites et analys´ees
pour optimiser le processus d’aide `a la d´ecision en ´etudiant les interactions entre les tableaux
de bords.
Etape 08 : Choix du progiciel
Choix des outils Business intelligence les plus adapt´es aux besoins et selon les crit`eres de
choix propres `a l’entreprise plus impl´ementation de la solution.
Etape 9 : Int´egration & D´eploiement de la solution
Configuration et d´eploiement de la solution `a la carte pour une mise en œuvre personnalis´ee
sur le terrain.
Etape 10 : audit du syst`eme
L’audit a pour objectif d’identifier les axes n´ecessaires d’am´elioration, de garantir en continu
la performance de la solution et de v´erifier p´eriodiquement son ad´equation avec les besoins
de l’entreprise.
Pour la r´ealisation de notre projet nous avons opt´e pour la m´ethodologie GIMSI car elle
nous permettra d’avoir une vue claire `a propos de la solution d`es le d´ebut de r´ealisation de
notre projet.
21

35. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
5 Planification
Dans tout les projets informatiques on doit toujours commencer par planifier les ´etapes par
lesquelles on va passer ainsi que son cycle d’impl´ementation dans le but de savoir estimer sa
dur´ee et ses fonctionnalit´es d`es le d´epart.
Ceci fait l’objet de cette section durant laquelle nous allons d´ecrire les phases de r´ealisation de
notre syst`eme ainsi que les taches `a r´ealiser pour chacune d’entre elles.
Phase 1 : Initialisation du projet
- Lancement du projet : R´eunions de d´emarrage avec M. Anis Khlif qui est mon encadrant
professionnel.
- Planification du projet : D´efinition des besoins et planification des phases et de la d´emarche
`a suivre.
Phase 2 : Documentation et formation
- ´Etude approfondie du cahier de charge et compr´ehension des besoins sp´ecifique du
client.
- Formation sur les outils utilis´es par BFI dans le d´eveloppement des applications.
- Recherches d´etaill´ees sur les concepts de l’informatique d´ecisionnelle.
- ´Etude comparative et choix des outils d’ETL, d’analyse et de restitution.
- Formation sur les outils s´electionn´ees.
Phase 3 : Installation
- Installation des environnements et des outils de d´eveloppement (Eclipse Magic Draw,
JBoss, etc.)
- Installation des environnements et des outils d’impl´ementation (SGBD, EDI, ETL, etc.).
- Param´etrage des outils mentionn´ees.
Phase 4 : Elaboration
- Pr´eparation de la conception de la partie d´eveloppement du projet comme une premi`ere
´etape.
- D´eveloppement des interfaces de la partie front-office et back-office ainsi les fonction-
nalit´es demand´ees par le client dans le cahier de charge.
- Capture des sources potentielles de donn´ees : L’une des phases les plus importantes dans
tous les projets de d´eveloppement et d’informatique d´ecisionnelle consiste `a capturer et
analyser les sources de donn´ees.
Ainsi cette ´etape nous servira comme support pour analyser les donn´ees que nous al-
lons collecter des sources utilis´ees et de v´erifier qu’elles ne vont pas pr´esenter aucun
probl`eme lors des chargements futurs de notre entrepˆot de donn´ees.
22

36. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
- Transformation et chargement des donn´ees dans l’entrepˆot de donn´ees : Suite `a l’obten-
tion des donn´ees, l’´etape suivante aura pour objectif d’alimenter la base interm´ediaire
juste apr`es les op´erations de normalisation et de structuration des ´el´ements provenant
des diff´erentes sources.
Puis nous allons passer `a l’´etape de chargement au cours de laquelle nous allons ali-
menter l’entrepˆot avec les donn´ees qui seront utilis´ees pour le calcul des indicateurs de
performance cl´es.
Phase 5 : D´eveloppement et d´eploiement
- Tests des interfaces : Cette tˆache consiste `a v´erifier et valider les interfaces d´evelopp´ees
ainsi les fonctionnalit´es de chaque interface avec le client en formant chaque ´equipe
(front office et back office) sur les masques qui seront utilis´es.
- Impl´ementation des tableaux de bords : Suite `a l’extraction des donn´ees `a partir de leurs
diff´erentes sources, de leur stockage dans la base interm´ediaire pour leur normalisation,
de leurs transformations et de leur chargement au sein de l’entrepˆot de donn´ees, on doit
pouvoir ˆetre capable d’utiliser ces donn´ees pour calculer des KPI et d’impl´ementer des
tableaux de bords qui se basent dessus.
- Tests d’int´egration : R´ealis´ee en mettant en place la solution dans un environnement
similaire `a celui de l’organisme d’accueil pour d´egager les incompatibilit´es avant la
mise en production.
- Tests d’acceptation : Ce test est r´ealis´e pour v´erifier que le syst`eme d´evelopp´e r´epond
d’une part `a la conception r´ealis´ee et d’autre part aux besoins de la soci´et´e.
- Tests unitaires r´ealis´e afin d’´eviter toute ´eventualit´e de bug ult´erieur dans la solution que
nous allons livrer.
6 Organisation du rapport
A cet instant nous avons pr´esent´e l’organisme au sein duquel nous avons effectu´e notre projet
de fin d’´etudes `a savoir BFI ainsi que les produits offerts par l’entreprise. Puis nous avons ´etudi´e la
solution actuelle afin de d´egager ses lacunes et ses principales probl´ematiques ce qui nous a men´e
`a la solution que nous avons propos´e et qui permettra d’am´eliorer le syst`eme Megara Forex.
Ensuite nous nous sommes focalis´e sur l’analyse et sur le contexte dans lequel `a ´et´e propos´e
notre projet suivi de la sp´ecification de ses besoins fonctionnels et non fonctionnels. Ceci nous a
men´e `a la fixation du p´erim`etre du projet et au choix de la m´ethodologie `a adopter.
Dans les chapitres suivants nous allons tout d’abord pr´esenter les concepts th´eoriques du do-
maine de l’informatique d´ecisionnelle afin de nous familiariser avec ce dernier.
23

37. CHAPITRE 1. CADRE G´EN´ERAL DU PROJET
Ensuite est venue l’´etape de choix de la m´ethodologie avec laquelle nous allons r´ealiser notre
projet.
Le chapitre suivant fera l’objet de l’initialisation du projet via la sp´ecification des besoins et
leurs analyses en plus de l’exposition du domaine de l’informatique d´ecisionnelle ce qui nous
facilitera la tˆache de choix des outils avec lesquels nous allons impl´ementer notre solution.
Au cours du troisi`eme chapitre nous allons nous int´eresser `a la phase de d´eveloppent du mo-
dule Spot, tr´esorerie et devise au sein duquel nous allons analyser, concevoir et impl´ementer la
r´ealisation.
Le quatri`eme et dernier chapitre fera l’objet de la partie technique de la solution d´ecisionnelle
qui sera coupl´ee avec le module impl´ement´e lors de la phase pr´ec´edente.
Conclusion
Au cours de chapitre nous avons tout d’abord pr´esent´e la soci´et´e dans laquelle nous avons
r´ealis´e notre projet `a savoir BFI. Puis nous avons ´etudi´e sa solution actuelle qui est Megara Forex
dans le but de savoir les difficult´es desquelles elle souffre.
24

38. Chapitre 2
Initialisation du projet
25

39. CHAPITRE 2. INITIALISATION DU PROJET
Introduction
Dans ce pr´esent chapitre nous allons d´ecrire les notions th´eoriques de notre solution ensuite
nous avons sp´ecifi´e nos sources de donn´ees `a savoir l’application Megara Forex et l’ERP de BFI.
1 Concepts de l’informatique d´ecisionnelle
Au cours de cette partie nous allons ´evoquer et d´efinir les concepts et des termes qui font partie
des projets d’informatique d´ecisionnelle, de ce fait nous allons ´etudier les diff´erents outils utilis´es
dans les diff´erentes phases de r´ealisation de notre projet.
1.1 Syst`emes d’informations d´ecisionnels
Au sein de toute entreprise, le syst`eme d’information (SI) sert `a faciliter l’´etablissement et la
mise en place de la politique de l’entreprise, en particulier de couvrir et englober les op´erations
effectu´ees. Ce syst`eme est mis en place selon des besoins bien d´etermin´es. Ces derniers traduisent
l’ensemble des services de l’entreprise, il peut ˆetre ´egalement pr´esent´e comme ´etant l’ensemble
des moyens (humains, logiciels, mat´eriels) utilis´es pour collecter, stocker, traiter et communiquer
les informations. [9]
Il existe principalement trois types de syst`emes d’informations mis en place au sein des diff´erentes
entreprises ou organismes `a savoir; les SI industriels, les SI de gestion et les SI de conception des
produits ou des services.
Ces trois types de syst`emes d’informations couvrent la totalit´e des processus de gestion de
l’entreprise (ressources humaines, achats, ventes, commerciales, marketing, comptables, finance,
etc) et peuvent se diviser en deux sous-syst`emes informations :
- Un SI op´erationnel qui prend en charge essentiellement l’impl´ementation des fonctionna-
lit´es offertes par l’entreprise.
Utilisateurs : Nombreux
Donn´ees : d´etaill´ees / volumineuses /internes
Dur´ee de vie : Longue
- Un SI d´ecisionnel, g´en´eralement utilis´e dans le but d’offrir les bonnes informations aux
personnes hautement plac´ees au sein de l’entreprise d´ecideurs) pour sp´ecifier et mettre en
place la strat´egie, guider les processus et analyser les r´esultats.
Utilisateurs : Peux nombreux
Donn´ees : Agr´eg´ees / Internes et externes
26

40. CHAPITRE 2. INITIALISATION DU PROJET
Dur´ee de vie : Courte
Du coup les SID repr´esentent un moyen pour simplifier la sp´ecification et la l’impl´ementation
des objectifs strat´egiques et de continuellement les adapter `a l’environnement de l’organisme, ceci
pour l’aider `a am´eliorer la sp´ecification et au pilotage des actions.
1.2 L’informatique d´ecisionnelle
1.2.1 D´efinition de l’informatique d´ecisionnelle
L’informatique d´ecisionnelle – ou BI (Business Intelligence) – est un ensemble de processus
technologiques qui permettent aux organismes et aux entreprises d’analyser leurs donn´ees `a des
fins de prise de d´ecisions (les dirigeants, les cadres commerciaux, etc...).
L’informatique d´ecisionnelle est un terme g´en´erique d´ecrivant l’utilisation des ressources en
informations internes et externes de l’entreprise pour am´eliorer la prise de d´ecision. Ralph KIM-
BALL[10]
L’informatique d´ecisionnelle, ou encore business intelligence (BI), repr´esente un ensemble de
m´ethodologies, de techniques et de solutions informatiques adopt´es dans le but de piloter une
entreprise et aider `a la prise de d´ecision `a travers l’adoption et l’utilisation de tableaux de bord,
rapports analytiques et prospectifs.
Elle est bas´ee simultan´ement sur la collecte, la mod´elisation et la restitution des donn´ees
´eparses, d´estructur´ees et h´et´erog`enes que g´en`ere une entreprise ou un organisme : archives pa-
pier, donn´ees stock´ees dans des bases de donn´ees, feuilles de calcul, donn´ees clients collect´es via
un service en ligne, etc. Tout ceci est g´er´e par des solutions d’extraction, de transfert et de conso-
lidation (en anglais Extract Transform Load, ETL) mises en place afin de normaliser ces sources
et mettre en place une coh´erence entre elles.
L’informatique d´ecisionnelle procure aux d´ecideurs des outils d’analyse et des indicateurs de
performance sur lesquels ils peuvent se baser afin de d´eterminer les orientations strat´egiques de
leurs organismes sans avoir `a g´erer tous les aspects techniques de ces actions.
Au sein de ces syst`emes les donn´ees sont g´en´eralement stock´ees et trait´ees dans des structures
appel´ees entrepˆots de donn´ees que l’on appelle aussi data Warehouse. Il y a ´egalement des bases
plus sp´ecifiques contenant des donn´ees plus cibl´ees, les magasins de donn´ees ou datamart, qui
ciblent des fonctionnalit´es plus pr´ecises de l’entreprise comme le d´epartement marketing dans
une agence de communication ou le d´epartement finance d’une banque.
27

41. CHAPITRE 2. INITIALISATION DU PROJET
1.2.2 Avantages de l’informatique d´ecisionnelle
Les solutions d’informatique d´ecisionnelle peuvent procurer de nombreux avantages pour l’en-
treprise. Ils permettent entre autres d’acc´el´erer et d’am´eliorer les processus de prise de d´ecision,
d’optimiser les flux internes, d’augmenter l’efficacit´e d’exploitation sans oublier le fait de g´en´erer
de nouveaux revenus ou encore de prendre l’avantage sur la concurrence.
Les solutions d’informatique d´ecisionnelle aident ´egalement les entreprises `a identifier les ten-
dances du march´e et `a rep´erer les probl`emes qui n´ecessitent une r´esolution urgente.
Les donn´ees servant aux syst`emes d’informatique d´ecisionnelle peuvent contenir des informa-
tions `a propos de l’historique, mais aussi de nouvelles donn´ees en provenance de syst`emes sources,
collect´ees d`es qu’elles sont g´en´er´ees. Ainsi, les op´erations d’analyse permettent de prendre aussi
bien des d´ecisions tactiques que des d´ecisions strat´egiques.
Initialement, les solutions d’informatique d´ecisionnelle ´etaient principalement utilis´ees par les
analystes de donn´ees et les personnes sp´ecialis´ee qui s’en servaient pour analyser les donn´ees et
g´en´erer des rapports. Par contre, de plus en plus d’ex´ecutifs et d’employ´es utilisent les logiciels
BI eux-mˆemes, notamment grˆace `a l’´emergence du self-service BI et des outils de d´ecouverte de
donn´ees.
1.2.3 Inconv´enients de l’informatique d´ecisionnelle
Comme exemple de limites apport´ees par les projets d’informatique d´ecisionnelle il y a :
• Complexit´e : Les projets d’informatique d´ecisionnelle sont souvent tr`es complexes ceci est
visible lors des op´erations de collecte et de traitement des donn´ees ce qui peut dans plusieurs
cas repr´esenter un risque majeur `a la r´ealisation du projet.
• Lenteur : Le temps n´ecessaire pour impl´ementer un projet d’informatique d´ecisionnelle est
tr`es long, ceci n’est pas une option pour certaines entreprises qui n’ont pas les moyens pour
investir `a long terme.
1.3 Syst`eme op´erationnels et syst`emes d´ecisionnels
Les syst`emes informatiques se r´epartissent en deux types, les syst`emes transactionnels (op´erationnels)
ou encore appel´es OLTP et les syst`emes analytique (d´ecisionnels) appel´es OLAP.
Les syst`emes d´ecisionnels OLAP sont g´en´eralement d´edi´es au pilotage des diff´erentes activit´es
de l’entreprise, et pour aider dans la gestion via une vision transversale de l’entreprise.
De l’autre cˆot´e les syst`emes d´ecisionnels nomm´es OLTP sont responsables du cot´e m´etier
de l’entreprise pour effectuer les tˆaches quotidiennes, r´ep´etitives et atomiques. Ces tˆaches sont
28

42. CHAPITRE 2. INITIALISATION DU PROJET
g´en´eralement assur´ees par des solutions appel´ees progiciels de gestion int´egr´es qui permettent
de regrouper les logiciels de gestion (les logiciels de finances, ressources humaines, logistique,
ventes, etc..) d’une entreprise dans une seule base de donn´ees.
Sys`eme op´erationnel (OLTP) Sys`eme d´ecisionnel (OLAP)
Donn´ees
- Donn´ees atomiques : On manipule un
article, une ligne, une commande, une
pi`ece.
- Donn´ees g´en´erales : Les d´ecideurs
veulent voir l’ensemble des activit´es.
- Bases de donn´ees normalis´ees. - Bases de donn´ees d´enormalis´ees.
- Anciennet´e des donn´ees : Les
donn´ees ne sont conserv´ees que sur
une courte p´eriode
- Anciennet´e des donn´ees : les
donn´ees sont historis´ees et peuvent
ˆetre agr´eg´ees
- Type d’acc`es : Lecture et ´ecriture. - Type d’acc`es : Lecture
Utilisateurs
- Grand public : Destin´e aux utili-
sateurs qui effectuent les diff´erents
tˆaches op´erationnelles.
- Quelques personnes (d´ecideurs).
- Le niveau des besoins analytiques est
bas.
- Le niveau des besoins analytiques est
haut.
- Une seule vision m´etier. - Plusieurs visions m´etiers.
Syst`eme
- Vitesse de traitement : G´en´eralement
tr`es rapide.
- Vitesse de traitement : D´epend de la
quantit´e de donn´ees impliqu´ees
- Ferm´es : Pas d’improvisation, les uti-
lisateurs sont guid´es par les processus.
- Ouverts : Acc`es simplifi´e aux
donn´ees.
- Transactionnels - Non transactionnels.
- D´ecentralis´es sauf dans le cas des
ERP.
- Centralis´es : Toutes les donn´ees sont
regroup´ees dans un mˆeme emplace-
ment.
TABLE 2.1 – Tableau comparatif entre les syst`emes op´erationnel et d´ecisionnel
1.4 Entrepˆots de donn´ees ou DW
Le Data Warehousing (DW) est un processus de collecte et de gestion de donn´ees qui pro-
viennent de sources diff´erentes (Big Data) pour aboutir `a des informations significatives qui ont
plus de valeur.
29

43. CHAPITRE 2. INITIALISATION DU PROJET
Un entrepˆot de donn´ees est g´en´eralement utilis´e pour connecter et analyser des donn´ees d’en-
treprise issues de sources h´et´erog`enes. Le Datawarehousee est le cœur du syst`eme de BI (Business
Intelligence) qui est conc¸u pour l’analyse des donn´ees et le reporting.
C’est un m´elange de technologies et de composants qui facilite l’utilisation strat´egique des
donn´ees. Il s’agit du stockage ´electronique d’une grande quantit´e d’informations par une entre-
prise, conc¸u pour ˆetre interrog´e et analys´e au lieu du traitement des transactions.
Il est d´efini comme ´etant un ensemble de bases de donn´ees permettant de stocker des donn´ees
historiques structur´ees non volatiles orient´ees sujet afin de les analyser.
Les donn´ees sont extraites, transform´ees et ing´er´ees afin que les utilisateurs puissent y acc´eder
via des outils de Business Intelligence, des clients SQL et des feuilles de calcul.
Un entrepˆot de donn´ees fusionne les informations provenant de diff´erentes sources dans une
base de donn´ees compl`ete.
La figure 2.1 pr´esente un sch´ema de description de l’architecture d’un syst`eme d´ecisionnel :
FIGURE 2.1 – Architecture d’un SID
1.5 Types d’entrepˆots de donn´ees
Les trois principaux types d’entrepˆots de donn´ees sont pr´esent´es dans la figure 2.2 :
30

44. CHAPITRE 2. INITIALISATION DU PROJET
FIGURE 2.2 – Types d’entrepˆots de donn´ees
- Datawarehouse d’entreprise : C’est un Data Warehouse centralis´e qui est utilis´e afin de
fournit un service d’aide `a la d´ecision dans toute l’entreprise. Il permet d’offrir une approche
d´edi´ee `a l’organisation et `a la repr´esentation des donn´ees. Il offre ´egalement la possibilit´e
de classer les donn´ees en fonction du sujet et de donner acc`es en fonction de ces divisions.
- Magasin de donn´ees op´erationnelles : Le magasin de donn´ees op´erationnelles, ou encore
ODS est un magasin de donn´ees utilis´e lorsque ni l’entrepˆot de donn´ees ni les syst`emes
OLTP ne permettent de g´erer les besoins l’entreprise en termes de stockage.
- Data mart : En adoptant l’approche ODS, l’entrepˆot de donn´ees est actualis´e en temps
r´eel. Par cons´equent, il est plus utilis´e avec les activit´es de routine comme le stockage des
donn´ees qui sont couramment utilis´ees ou qui ont une importance plus ´elev´ee afin d’´eviter
tout risque de perte.
1.6 Chaine d´ecisionnelle
Afin de pouvoir utiliser les donn´ees collect´ees des sources externes ou internes `a l’entreprise,
on doit passer par les quatre ´etapes suivantes pour r´ealiser un projet d’informatique d´ecisionnelle.
1.6.1 Alimentation du datawarehouse
Collecter, extraire, nettoyer et consolider les donn´ees des syst`emes de production et les adapter
`a un usage d´ecisionnel. La collecte des donn´ees est une fonction assur´ee par une famille d’outils
d´enomm´ee outils ETL pour Extract Transform load.
31

45. CHAPITRE 2. INITIALISATION DU PROJET
Avant d’ˆetre utilisables, ces donn´ees seront format´ees, nettoy´ees et consolid´ees. Les outils
d’ETL permettent de faciliter ces traitements et de g´erer les flux de donn´ees alimentant les bases
de stockage : Data Warehouse ou Datamart.
La collecte s’effectue `a partir de donn´ees appel´ees : donn´ees sources. Ces derni`eres peuvent se
pr´esenter sous diff´erents formats. Il peut s’agir de fichiers ”plats” (fichiers CSV avec s´eparateurs,
fichiers XML, fichiers ASCII...) mais aussi de fichiers SQL provenant de bases de donn´ees
(MySQL, PostgreSQL, ORACLE, etc). Ensuite on doit les int´egrer afin de pouvoir les manipuler
avant de les stocker dans notre syst`eme d´ecisionnel.
1.6.2 Mod´elisation des donn´ees
Pour un usage d´ecisionnel il faut avant tout que les donn´ees soient structur´ees et trait´ees avant
d’ˆetre stock´ees et sauvegard´ees afin qu’elles soient utilis´ees de fac¸on optimis´ee. La deuxi`eme
couche logicielle est n´ecessaire.
Cette couche interm´ediaire s’appelle l’ODS ou encore Operational Data Store qui fait of-
fice de structure interm´ediaire destin´ee `a stocker les donn´ees issues des syst`emes de production
op´erationnelle. C’est en quelque sorte une zone de pr´eparation avant l’int´egration des donn´ees
dans le DW.
1.6.3 Restitution des donn´ees
Cette phase permet de distribuer ou de faciliter l’accessibilit´e des informations selon les fonc-
tions et les types d’utilisation. Cette phase est la troisi`eme et qui permet de stocker les donn´ees
dans un entrepˆot.
Celui-ci contient les donn´ees orient´ees m´etier, non volatiles (dat´ees), historis´ees et docu-
ment´ees et il est utilis´e pour optimiser les temps de r´eponses lorsque l’on fait des analyses de
type OLAP qui se r´ef`erent `a une base de donn´ees multidimensionnelle (aussi appel´ee cube ou
hypercube).
Une fois ces donn´ees stock´ees dans le Datawarehouse, on va pouvoir cr´eer des magasins de
donn´ees d´edi´es `a une fonction de l’entreprise pour des raisons d’accessibilit´e, de facilit´e d’utili-
sation ou de performance. Les donn´ees sont g´en´eralement ´equivalentes `a celles pr´esentes dans le
DW principal mais elles sont repr´esent´ees de fac¸on adapt´ee aux besoins sp´ecifiques de la fonction
et/ou du domaine utilisateur.
32

46. CHAPITRE 2. INITIALISATION DU PROJET
1.6.4 Analyse et pr´evision
Cette phase d´esigne le fait d’exploiter ou assister du mieux possible l’utilisateur afin qu’il
puisse extraire la substance ou la connaissance de l’information `a partir des donn´ees stock´ees `a
cet usage. Elle est plus focalis´ee sur les op´erations de restitution des r´esultats, on distingue `a ce
niveau plusieurs types d’outils diff´erents :
- Les outils de reporting et de requˆetes
- Les outils d’analyse
- La phase de Datamining
Dans notre cas nous allons utiliser le premier type d’outils `a savoir outils de reporting
permettent la mise `a disposition de rapports p´eriodiques, pr´eformat´es et param´etrables par les
op´erationnels. Ils offrent une couche d’abstraction orient´ee m´etier pour faciliter la cr´eation de
rapports par les utilisateurs eux-mˆemes en interrogeant le datawarehouse grˆace `a des analyses
crois´ees.
Ils offrent ´egalement la possibilit´e de production de tableaux de bord avec des indicateurs de
haut niveau pour les managers, synth´etisant diff´erents crit`eres ou indicateurs de performance.
2 Sources de donn´ees
Pour l’alimentation de notre datawarehouse nous allons utiliser le progiciel de gestion int`egre
adopt´e par BFI et l’application de Megara-Forex.
L’ERP est interfac´e avec une base de donn´ees oracle client ainsi que l’application interne elle
aussi qui utilise le mˆeme SGBD pour le stockage et l’acc`es aux donn´ees Oracle Database est un
syst`eme de gestion de base de donn´ees fourni par Oracle Corporation. C’est l’un des SGBD les
plus populaires au niveau mondial.
Il fonctionne sur un syst`eme relationnel et mˆeme sur un mod`ele relationnel objet depuis la
version 8.
Ce syst`eme propri´etaire a ´et´e d´evelopp´e notamment par Larry Ellison, le co-fondateur de l’en-
treprise Oracle.[11]
Oracle propose 4 types de licences :
- ´Edition standard : Contient les fonctions de base de gestion de base de donn´ees pour les
petites et moyennes entreprises avec des limites sur les ressources offertes.
33

47. CHAPITRE 2. INITIALISATION DU PROJET
- ´Edition entreprise : Propose une vaste gamme d’outils pour les grandes entreprises.
- ´Edition standard One : Oracle SEO est sp´ecialement conc¸u pour les serveurs `a processeur
unique utilis´es par les petites entreprises.
- ´Edition express : Oracle Express contient certaines fonctionnalit´es DBA, notamment la
r´eplication de base en lecture seule.
Oracle Instant Client permet aux applications de se connecter `a une solution Oracle Database
locale ou distante pour le d´eveloppement et le d´eploiement en production. Les biblioth`eques Ins-
tant Client fournissent la connectivit´e r´eseau n´ecessaire, ainsi que des fonctionnalit´es de donn´ees
de base et haut de gamme, pour exploiter pleinement Oracle Database. Il est `a la base des API
Oracle des langages et environnements populaires, notamment Node.js, Python et PHP, et fournit
´egalement un acc`es aux applications OCI, OCCI, JDBC, ODBC et Pro*C. [12]
De ce fait nous allons utiliser les deux bases comme ´etant nos sources des donn´ees qui vont
ˆetre extraites par l’outil ETL avant de les transformer et charger dans l’entrepˆot de donn´ees.
3 Processus et choix ETL
3.1 D´efinition du processus ETL
Le processus d’extraction est la compilation des donn´ees brutes, qui sont transform´ees pour
les rendre intelligibles, et leur chargement dans un syst`eme cible, tel qu’une base de donn´ees ou
un entrepˆot de donn´ees pour un acc`es et une analyse optimis´ee.
Ce type d’outils est connu sous le nom de solution ETL ou encore Extract - Transform - Load,
Process est un composant important de l’´ecosyst`eme de donn´ees de toute entreprise moderne et
principalement utilis´e pour le traitement OLAP dans un entrepˆot de donn´ees.
´Etant donn´e que les donn´ees proviennent de plusieurs sources et de sch´emas diff´erents, chaque
ensemble de donn´ees doit ˆetre transform´e diff´eremment avant de pouvoir ˆetre utilis´e pour la BI et
l’analyse.
34

48. CHAPITRE 2. INITIALISATION DU PROJET
3.2 ´Etapes du processus ETL
L’ETL est une op´eration qui permet de traiter des donn´ees `a travers trois ´etapes :
Extraction
La premi`ere ´etape avant de pouvoir commencer `a organiser les donn´ees consiste `a extraire
les donn´ees de toutes les sources pertinentes et `a les compiler. Cette exigence ETL et ce
processus de collecte comprendront la pr´eparation n´ecessaire pour effectuer l’int´egration
des donn´ees dont es sources peuvent inclure des bases de donn´ees sur site, des syst`emes
CRM, des plateformes d’automatisation du marketing, des entrepˆots de donn´ees cloud, des
fichiers non structur´es et structur´es, les applications cloud et toute autre source de donn´ees
`a partir de laquelle on peut tirer des informations via un traitement analytique.
Transformation des donn´ees
La transformation des donn´ees est la deuxi`eme ´etape du processus ETL dans les int´egrations
de donn´ees. Maintenant, dans la deuxi`eme ´etape, les donn´ees extraites des sources sont
compil´ees, converties, reformat´ees et nettoy´ees dans la zone de transit pour ˆetre introduites
dans la base de donn´ees cible `a l’´etape suivante.
L’´etape de transformation consiste `a effectuer une s´erie de manipulations ou transformations
et `a y appliquer un ensemble de r`egles aux donn´ees extraites, ceci pour les convertir `a un
format standard afin de r´epondre aux exigences du datawarehouse.
Chargement
L’´etape finale consiste `a charger la totalit´e des donn´ees qui ont ´et´e extraites et transform´ees
plus tˆot, au sein de la base de donn´ees cible.
La figure 2.3 pr´esente un sch´ema du processus ETL :
FIGURE 2.3 – Processus ETL
35

49. CHAPITRE 2. INITIALISATION DU PROJET
3.3 Choix de l’outil ETL
Un logiciel ETL (Extract Transform Load) permet d’extraire des donn´ees brutes depuis une
base de donn´ees, pour ensuite les restructurer, et enfin les charger dans une Data Warehouse. Ces
logiciels existent depuis bien longtemps, mais ont beaucoup ´evolu´e pour r´epondre aux nouveaux
besoins li´es `a l’essor du Cloud, des SaaS (logiciels en tant que service) et du Big Data.
Le tableau 2.2 illustre une ´etude comparative des outils ETL qui sont susceptibles d’ˆetre uti-
lis´ees dans le cadre de notre projet :
Crit`ere Microsoft SSIS Talend Integration Suite Pentaho
Facilit´e d’utilisation G G
Travail collaboratif G
Interface utilisateur Web
Performance sur les grands vo-
lumes
G G G
Regroupement et r´epartition G G
M´eta-mod´elisation G
Planificateur int´egr´e G
Client de services Web G G
Jointure de plusieurs sources G G G
Validation des donn´ees G G G
Pr´evisualisation des sources de
donn´ees
G G
Alertes et notifications G G
Open source G G
Connexion `a des logiciels ex-
ternes
G
Connecteurs no SQL G G
Interface graphique G G G
Deploiement sur le cloud G G
TABLE 2.2 – Tableau comparatif entre les outils ETL [18]
Ainsi, apr`es notre comparaison des diff´erents outils ETL nous avons remarqu´e que la solution
Talend open studio for data integration est la plus adapt´ee pour notre besoin en terme de connec-
tivit´e et pour les ex´ecutions ult´erieures des jobs. Ceci nous permettra apr`es la r´ealisation de notre
36

50. CHAPITRE 2. INITIALISATION DU PROJET
solution de planifier des ex´ecutions automatiques ou d’interfacer le processus ETL avec une autre
application qui permettra de le g´erer.
Notre choix s’est port´e sur l’outil Talend open studio pour la phase ETL de notre solution. Ce
choix est ´egalement bas´e sur son classement publi´e par Gartner qui est l’un des premiers. [13]
FIGURE 2.4 – Logo Talend
Les principales caract´eristiques de Talend sont :
- Interfac¸age facile avec une multitude de types de sources de donn´ees.
- Impl´ementation graphique.
- Mod´elisation des processus m´etiers.
- Ex´ecution et d´ebugage en temps r´eel.
- Codage des fonctionnalit´es sp´ecifiques en JAVA.
- Une palette tr`es riche en composants prˆets `a l’emploi.
La figure 2.5 pr´esente l’architecture technique de l’outil Talend Open Studio :
FIGURE 2.5 – Architecture Talend Open Studio
37

51. CHAPITRE 2. INITIALISATION DU PROJET
La solution Talend est bas´e sur une version d’eclipse qui prend en charge les d´eveloppements
orient´es ETL. Il est ´egalement efficace vu qu’il offre des outils stock´ees sous format XML conver-
tibles en code Java lors des ex´ecutions des Jobs.
4 Mod´elisation du datawarehouse
L’entrepˆot de donn´ees est le composant le plus important dans la chaine de tout projet d’in-
formatique d´ecisionnelle et constitue l’un des meilleurs moyens ou structures pour mod´eliser les
informations pour des fins analytiques. De ce fait il faut bien ´etudier les fac¸ons avec lesquelles
cette structure peut ˆetre construite afin de pouvoir utiliser les donn´ees collect´ees de mani`ere effi-
cace car celles-ci vont intervenir dans les processus d´ecisionnels.
En adoptant une approche de datawarehouse on peut se retrouver avec une quantit´e ´enorme
de donn´ees, du coup il est pr´ef´erable de diviser cette structure selon les objectifs strat´egiques de
l’entreprise. Ceci peut ˆetre r´ealis´e avec des structures plus souples et sp´ecifiques qui sont appel´ees
des data marts ou magasins de donn´ees.
Ces derniers sont une version all´eg´ee du DW et peuvent porter sur chacun des d´epartements
de l’entreprise. Comme c¸a le projet deviendra moins lourd et plus rapidement men´e. La diff´erence
entre une base de donn´ees relationnelle et un entrepˆot de donn´ees r´eside dans la mod´elisation de
ces deux structures.
La diff´erence entre une base de donn´ees relationnelle et un entrepˆot de donn´ees r´eside dans la
mod´elisation de ces deux structures. Lorsqu’on parle des bases de donn´ees classiques on parle de
tables et de relations, les table sont les repr´esentations des entit´es et les relations servent `a leurs
liaisons. Ainsi on peut distinguer les types de table suivantes :
- Tables de dimensions : Contient les axes d’analyse selon lesquels on veut ´etudier des
donn´ees observables (les faits) qui, soumises `a une analyse multidimensionnelle, donnent
aux utilisateurs des renseignements n´ecessaires `a la prise de d´ecision.
- Tables de faits : Stockent les indicateurs analys´es et repr´esentent le contenu qui fera l’objet
de l’analyse. Ces tables recouvrent les informations op´erationnelles qui refl`etent les pro-
cessus de l’entreprise.Utilis´e pour la sauvegarde des indicateurs et d´ecrivent les processus
m´etiers des organismes sur lesquels on va r´ealiser les analyses.
Les DW servent aussi `a la sauvegarde des tables de configuration qui ne peuvent pas servir
aux analyses :
- Tables r´ef´erentielles : Repr´esente une structure de stockage des donn´ees n´ecessaires aux
conversions ou pour g´erer la politique de s´ecurit´e de la solution.
- Tables de param´etrage : Regroupent des crit`eres sur lesquels d´ependent les donn´ees
38