Asmae LOUTFI INTEGRYTIS

Ecole Nationale Supérieure d’Informatique
et d’Analyse des Systèmes
Mémoire de Projet de Fin d’Études
Pour l’Obtention du Titre
D’Ingénieur d’État en Informatique

Option
Business Intelligence
Sujet
Conception et réalisation d’un DataMart Risque de

crédit pour le compte d’une banque marocaine
Soutenu par : Membre de jury : Sous la direction de :

Mme Asmae LOUTFI M. Said ACHCHAB (Président du Jury) Mme Houda BENBRAHIM(ENSIAS)
Mme Naima ELHAOUD (Examinatrice) Mme Soumia BOUCHOUARI(Integrytis)
Mme Houda BENBRAHIM (Encadrante) Mme Asmae DOUMAL(Integrytis)
M. Khalid SOLH(Integrytis)
Année Universitaire 2014-2015

Dédicace
A ma chère mère
A mon cher père
Je ne serai exprimer ma gratitude pour vos sacrifices, votre amour, vos
prières et vos soutiens tout au long de mon cursus. A ceux qui ont attendu
avec patience les fruits de leur bonne éducation...
Nul mot et aucune dédicace ne saurait exprimer mes sentiments, mon
respect, ma considération et ma grande admiration.
A ma fille Soraya
A ma petite famille
Je ne pourrai exprimer ma reconnaissance pour tout amour et soutien, et
tous vos sacrifices.
A mes sœurs : Kawtar et Ikhlass

Je vous remercie pour tout ce que vous avez fait pour moi
A toute ma famille.
A mes chers amis

Pour tout le soutien que vous m’avez offert je vous dis MERCI.
A tous ceux qui m’aiment, je dédie ce travail.
Asmae
Remerciements
Il m’est agréable de m’acquitter d’une dette de reconnaissance auprès de toutes les personnes,
dont l’intervention au cours de ce projet a favorisé son aboutissement.
De prime à bord, je tiens à présenter mes plus sincères remerciements à M. Ilias BENSAID et
M. Dominique COSTARDI, directeurs associés d’INTEGRYTIS et M. Khalid SOLH,
directeur adjoint d’INTEGRYTIS pour leur accueil chaleureux au sein de la société, pour
m’avoir proposé un sujet si passionnant et intéressant et pour m’avoir permis de vivre une
expérience professionnelle tellement enrichissante. Je tiens à présenter également mes
sincères remerciements à Mme Soumia BOUCHOUARI, Consultante fonctionnelle et Mme.
Asmae DOUMAL, Consultante BI, pour leurs prestigieux encadrements, leurs soutiens, leurs
conseils directifs, leurs orientations et leurs explications enrichissantes.
J’adresse également mes remerciements à Mme Houda BENBRAHIM pour avoir encadrée
mon projet de fin d’études, je la remercie vivement pour sa disponibilité et tous ses conseils
avisés concernant les missions évoquées dans ce rapport. Mes plus vifs remerciements sont
aussi adressés au personnel d’INTEGRYTIS, pour l’intérêt qu’ils m’ont apporté durant ces
quatre mois de stage, ainsi que pour leurs aides et soutiens. J’adresse également mes
remerciements à Mme Naima EL HAOUD, la présidente de jury et M. Said ACHCHAB
d’avoir bien voulu accepter d’examiner et évaluer notre travail de stage.
Je tiens à exprimer ma gratitude à tout le corps professoral de l’Ecole Nationale Supérieure

d’Informatique et d’Analyse des Systèmes (ENSIAS) pour l’intérêt qu’ils manifestent dans la
formation des futurs ingénieurs.
Que tous ceux et celles qui ont contribué de près ou de loin à l’accomplissement de ce travail
trouvent l’expression de mes remerciements les plus chaleureux.
Projet de Fin d’Etudes 4 2014-2015

Résumé
Le secteur bancaire marocain « n'est pas touché par la crise financière internationale actuelle
et demeure entièrement mobilisé pour soutenir le développement économique et social du
Royaume »1. Cependant, il reste toujours sous la menace d’exposition au risque de crédit.
Le présent rapport est la synthèse de notre travail dans le cadre du projet de fin d’études
effectué au sein d’INTEGRYTIS. Ce projet a pour objectif la mise en place des outils de
pilotage et de Reporting associés afin d’avoir un suivi du processus de gestion du risque de
crédit d’une banque marocaine (client d’INTEGRYTIS).
Pour ce faire, nous commençons par la phase de l’étude du système opérationnel existant chez
notre client et l’analyse de ses besoins. Cette phase permet d’établir les indicateurs et axes
d’analyse nécessaires au suivi de l’activité de gestion de risque de crédit afin de proposer la
modélisation dimensionnelle du DataMart Risque de crédit qui répond aux besoins de notre
client. Ensuite, nous concrétisons notre proposition par la phase de mise en œuvre démarrant
avec l’extraction des données nécessaires et leurs chargements par le biais de processus ETL
pour ainsi réaliser des tableaux de bord dédiés au département Risques GROUPE de notre
client.
Quant à l’environnement technologique du projet, nous avons profité des possibilités

fonctionnelles et techniques offertes par Oracle Data Integrator pour la partie ETL et l’outil de
Reporting de Microsoft SSRS pour la partie restitution.
Mots-clés : INTEGRYTIS, Banque marocaine, Risque de crédit, DataMart, ETL, Oracle Data
Integrator, SSRS.
1
Nous rassure le Groupement Professionnel des Banques du Maroc (GPBM)

Abstract
The Moroccan banking sector “is not affected by the current international financial crisis and
remains fully mobilized to support the economic and social development of the Kingdom”2.
However, it’s still under the threat of exposure to credit risk.
This report is the synthesis of our capstone project carried out within INTEGRYTIS. This
project aims the development of management and Reporting tools in order to have a follow-
up of the credit risk management process within a moroccan bank (customer of
INTEGRYTIS).
To do this, we start by studying our customer’s existing operational system and analyzing its
needs. This phase establish the indicators and analysis axes necessary for credit risk
management, to offer dimensional modeling of Credit Risk DataMart that meets the needs of
our client. Then we implement our proposal. We start the realization phase with the
extraction of the necessary data and loading them through ETL, and then we construct the
dashboards dedicated to credit risk department of our client.
As to the technological environment of the project, we relied on the functional and technical
possibilities offered by Oracle Data Integrator for the ETL part, and we used Microsoft SSRS
for the restitution part as a Reporting tool.
Keywords: INTEGRYTIS, Moroccan Bank, Credit Risk, DataMart, ETL, Oracle Data
Integrator, SSRS.
2
We reassured the Professional Group of Banks in Morocco (GPBM)

Liste des abréviations
BI Business Intelligence
CRM Customer Relationship Management
EAD Exposure-At-Default
E-LT Extract, Load and Transform
ETL Extract Transform Load
IRB Internal Ratings Based Foundation
KM Knowledge Modules
LGD Loss-Given-Default
NI Notation Interne
ODI Oracle Data Integrator
PD Probability of Default
PME Petite Moyenne Entreprise
SAS DDS SAS®Detail Data Store
SGBDR Système de Gestion de Base de Données

Relationnelle
SK Surrogate Key
TPE Très Petite Entreprise

Table des figures
Figure 1: Les cinq phases de l'approche INTEGRYTIS ....................................................................... 17

Figure 2: Organigramme du client d’Integrytis ..................................................................................... 19
Figure 3: Diagramme GANTT du projet ............................................................................................... 22
Figure 4: Différents usages des stress tests ........................................................................................... 27
Figure 6: Entrées et sorties de l'application Fermat du client ................................................................ 28
Figure 7: Les tables alimentées du modèle logique de données DDS ................................................... 29
Figure 8: Schéma des besoins couverts par le DataMart Risque de crédit ............................................ 31
Figure 10: Table dimension Tiers.......................................................................................................... 39
Figure 11: Table dimension Provision .................................................................................................. 40
Figure 12: Table dimension Pays .......................................................................................................... 40
Figure 13: Table dimension Contrat crédit ............................................................................................ 40
Figure 14: Table dimension Garantie .................................................................................................... 41
Figure 15: Table dimension Classe risque............................................................................................. 41
Figure 16: Les classes de risque de l'organisme bancaire ..................................................................... 42
Figure 17: Table dimension Statut ........................................................................................................ 42
Figure 18: Table dimension Facilite crédit ............................................................................................ 43
Figure 19: Table dimension Type Exposition ....................................................................................... 43
Figure 20: Table dimension Classe exposition ...................................................................................... 43
Figure 21: Table dimension Catégorie fonds propres ........................................................................... 44
Figure 22: Table dimension Date .......................................................................................................... 44
Figure 23: Table dimension Nature engagement................................................................................... 44
Figure 24: Table de faits FactOperationCredit ...................................................................................... 45
Figure 25: Table de faits FactEngagements .......................................................................................... 45
Figure 26: Table de faits FactImpayesCreancesDouteuses ................................................................... 46
Figure 27: Table de faits FactExpositionPortefeuille ............................................................................ 46
Figure 28: Table de faits FactExigenceFondsPropres ........................................................................... 47
Figure 29: Modèle flocon de la table de faits Opération crédit ............................................................. 48
Figure 30: Modèle en étoile de la table de faits Engagements .............................................................. 49
Figure 31: Modèle flocon de la table de faits Impayés et Créances douteuses ..................................... 50
Figure 32: Modèle en étoile de la table de faits Exposition des portefeuilles ....................................... 51
Figure 33: Modèle en étoile de la table de faits Exigence en fonds propre ........................................... 51
Figure 34: Modèle logique du DataMart Risque de crédit .................................................................... 52
Figure 35: Architecture applicative de la solution ................................................................................ 56
Figure 36: Différence entre l’approche ETL et l’approche E-LT d'ODI ............................................... 58
Figure 37: Architecture physique et logique de la base de données Oracle .......................................... 59
Figure 38: Création de la structure de données d'un fichier plat sous ODI ........................................... 60
Figure 39: Modules de connaissances importés .................................................................................... 61
Figure 40: Séquences créées pour les dimensions du DataMart ........................................................... 62
Figure 41: Mapping de l’interface d’alimentation de la table de correspondance garantie................... 62
Figure 42: Mapping de l’interface d’alimentation de la table de dimension Tiers ................................ 63
Figure 43: Flux de l'interface d'alimentation de la table de dimension gage ......................................... 64

Figure 44: Flux de l’interface d'alimentation de la table de faits Opération crédit ............................... 64
Figure 45: Mapping de l’interface d’alimentation de la table de faits Opération crédit........................ 65
Figure 46: Mapping de l'interface du fichier Input COLLATERAL de l'application Fermat ............... 65
Figure 47: Package d'alimentation du DataMart ................................................................................... 67
Figure 48: Package de génération des fichiers Input de l'application Fermat ....................................... 67
Figure 49: Tableau de bord de l'évolution mensuelle du portefeuille d'engagement ............................ 68
Figure 50: Tableau de bord ventilation mensuelle par risque de crédit................................................. 69
Figure 51: Tableau de bord de la situation des impayés par ancienneté et par catégorie de clientèle... 70
Figure 52: Architecture générale d'ODI[3]............................................................................................ 81
Figure 53: Architecture détaillée d'ODI[3]............................................................................................ 82

Liste des tableaux
Tableau 1: Livrables du projet............................................................................................................... 23

Tableau 2: Indicateurs du DataMart Risque de crédit ........................................................................... 33
Tableau 3: Axes d'analyse du DataMart Risque de crédit ..................................................................... 34
Tableau 4: Matrice de croisement DataMart Risque de crédit .............................................................. 34
Tableau 5: Conception « rapport Evolution mensuel du portefeuille d'engagement » .......................... 53
Tableau 6: Conception « rapport Ventilation des engagements par classe de risque de crédit » .......... 53
Tableau 7: Conception « rapport Situation des impayés par ancienneté et par catégorie de clientèle » 53
Tableau 8: Les trois piliers de l'accord Bâle 2....................................................................................... 77
Tableau 9: Description des différents modules de connaissances utilisés dans la mise en œuvre du
projet [Oracle] ....................................................................................................................................... 85

Table des matières
Table des matières

Liste des abréviations .............................................................................................................................. 7
Table des figures...................................................................................................................................... 8
Liste des tableaux .................................................................................................................................. 10
Table des matières ................................................................................................................................ 11
Introduction générale............................................................................................................................ 13
Chapitre 1 ............................................................................................................................................... 15
1. Contexte général du projet ......................................................................................................... 16
1.1. Organisme d’accueil : Présentation d’INTEGRYTIS .............................................................. 16
1.1.1. L’approche INTEGRYTIS ................................................................................................ 16
1.1.2. Divisions ........................................................................................................................ 17
1.1.3. Références..................................................................................................................... 18
1.2. Cadre général du projet ...................................................................................................... 18
1.2.1. Présentation générale de l’organisme bancaire ........................................................ 18
1.2.2. Contexte du projet ....................................................................................................... 19
1.2.3. Objectifs du projet....................................................................................................... 20
1.2.4. Conduite du projet ...................................................................................................... 21
Chapitre 2 ............................................................................................................................................... 24
2. Analyse et Spécification .............................................................................................................. 25
2.1. Vue générale sur le risque de crédit .................................................................................... 25
2.1.1. Définition du risque de crédit ..................................................................................... 25
2.1.2. Cadre réglementaire.................................................................................................... 25
2.1.3. Mesure de risque de crédit.......................................................................................... 26
2.1.4. Stress test ...................................................................................................................... 26
2.2. Analyse de l’existant ............................................................................................................. 27
2.2.1. Dispositif de gestion de risque de crédit .................................................................... 28
2.3. Expression des besoins ......................................................................................................... 30
2.3.1. Conception et réalisation d’un DataMart risque de crédit ...................................... 30
2.3.2. Spécifications fonctionnelles ....................................................................................... 32
2.3.3. Spécifications techniques ............................................................................................ 35
Chapitre 3 ............................................................................................................................................... 37
3. Conception ................................................................................................................................... 38
3.1. Définition des entrepôts de données................................................................................... 38

Table des matières
3.2. Conception du DataMart ...................................................................................................... 38

3.2.1. Les tables du DataMart............................................................................................... 38
3.2.2. La modélisation multidimensionnelle ........................................................................ 47
3.3. Conception des rapports ...................................................................................................... 53
Chapitre 4 ............................................................................................................................................... 55
4. Réalisation .................................................................................................................................... 56
4.1. Présentation de l’environnement de travail........................................................................ 56
4.1.1. Base de données: Oracle ............................................................................................. 57
4.1.2. Extraction, Transformation and Loading (ETL): ODI ........................................... 57
4.1.3. Restitution des données: SSRS ................................................................................... 58
4.2. Mise en œuvre ...................................................................................................................... 59
4.2.1. Développement des flux ETL ..................................................................................... 59
4.2.2. Edition des rapports .................................................................................................... 67
Conclusion générale .............................................................................................................................. 72
Bibliographie.......................................................................................................................................... 73
Webographie ......................................................................................................................................... 73
Annexes ................................................................................................................................................ 74
Réglementation de Bâle ...................................................................................................................... 75
Oracle Data Integrator ........................................................................................................................ 80

Introduction générale
Le secteur bancaire se distingue particulièrement des autres secteurs économiques, tant par ses
caractéristiques intrinsèques que par son impact sur le développement du Royaume. Il occupe
un rôle central dans le financement de l’économie et apporte une contribution significative à
l’accompagnement des politiques publiques et sectorielles menées par le gouvernement.
Le secteur bancaire marocain s’est doté d’une organisation moderne3. Il est régi par un cadre
législatif et réglementaire, inspiré de meilleures pratiques internationales, notamment la
régulation prudentielle, la supervision bancaire, le dispositif de gestion des risques et la
réglementation Bâle II et III [Annexe A]. Ledit secteur dispose d’une solidité financière
reconnue, permettant de faire face, en période de crise internationale, aux exigences de
sécurité financière de plus en plus croissantes.
Le rôle de Bank Al-Maghreb dans la régularisation du secteur bancaire a été renforcé à travers
la loi 76-03, portant statut de la Banque Centrale, et la loi 34-03 relative aux établissements de
crédit, qui ont consacré l’indépendance de l’Institut d’émission, notamment pour la conduite
de la politique monétaire, et affirmé son autonomie pour la supervision du système bancaire.
Bank Al-Maghreb suit également d’une manière rigoureuse l’activité des établissements de
crédit et publie, depuis 2005, un rapport annuel sur la supervision bancaire, qui traite
notamment de la réglementation bancaire et des relations banques-clients ; ce rapport retrace
aussi l’évolution de l’activité et des résultats du secteur bancaire et informe sur la
concentration bancaire.
Cependant, le secteur bancaire reste toujours sous la menace d’exposition aux risques. En
effet, la banque en tant qu’intermédiaire financier est au cœur du système de financement de
l’économie. Pour accéder au marché de la dette, les différents porteurs de projets (particuliers,
professionnels, entreprises, collectivités et Etats) demandent à leurs banques de les financer.
Ceci augmente le risque induit par le manque de certitude d’honorer les échéances des prêts.
Cette incertitude est due préalablement au risque intrinsèque de chaque client.
3
L’organisation repose sur la loi bancaire de 2006 qui vient compléter et corriger celle du 6 juillet 1993 relative
à l’activité et au contrôle des établissements de crédit.

Il est devenu impératif aux banques, dans ce contexte, de gérer son risque de crédit. C’est
dans ce cadre que s’inscrit notre projet de fin d’études au sein de la société INTEGRYTIS et
qui consiste à la mise en œuvre d’un DataMart Risque de crédit au bénéfice d’un organisme
bancaire (client d’INTEGRYTIS).
Notre champ d’application dans ce projet est tout d’abord la conception du DataMart Risque
de crédit afin de répondre aux exigences réglementaires et de suivre les engagements et les
expositions de la banque. Nous identifions tout d’abord les indicateurs et les axes d’analyse.
Ensuite nous alimentons le DataMart conçu et mis en place à travers des flux ETL avec
l’outil spécifié par le client, et enfin nous éditons des rapports de suivi des expositions et
engagements de la banque afin de gérer au mieux son risque de crédit.
Ce rapport décline les différentes phases de notre projet. Il est ainsi organisé en quatre
chapitres :
Le premier chapitre aborde le contexte général du projet. Il présente la société INTEGRYTIS

où se déroule notre projet de fin d’études et expose le cadre général du projet, ses objectifs,
ainsi que l’approche adoptée pour sa conduite.
Le deuxième chapitre présente une description des systèmes existants chez le client et expose
les besoins de l’organisme bancaire.
Le troisième chapitre se focalise sur la conception. Il explicite les concepts de la modélisation

multidimensionnelle ainsi que la modélisation du DataMart Risque de crédit. La conception
des différents rapports est ensuite abordée.
Le dernier chapitre est consacré à la mise en œuvre de la solution en se basant sur la phase
d’analyse et de conception. D’abord, nous donnons un aperçu sur les technologies utilisées,
puis nous présentons la partie de la réalisation des processus ETL, et finalement, nous traitons
la partie Reporting, en exposant quelques modèles de rapports réalisés.

Chapitre 1
Contexte général du projet
Ce chapitre introductif a pour objet d’exposer le cadre général du projet en présentant

l’organisme d’accueil, notre client, le contexte du projet et l’objectif de ce dernier. La
conduite proposée pour la réalisation de ce projet en termes de phases, de planning et
des livrables est également détaillée dans ce premier chapitre.

Chapitre 1 Contexte général du projet
1. Contexte général du projet

Dans ce chapitre nous présentons le projet dans son cadre général à savoir : l’organisme
d’accueil, la banque marocaine (notre client), le contexte du projet, ses objectifs et la conduite
de sa réalisation.
1.1. Organisme d’accueil : Présentation d’INTEGRYTIS
INTEGRYTIS est une société de conseil et de service, spécialisée en business intelligence

(BI) et en gestion de la relation client (CRM). Créée en 2004, elle regroupe une trentaine de
salariés et son siège social se trouve à Paris. Elle accompagne les entreprises dans leur
mutation stratégique vers la nouvelle économie et offre des services principalement axés sur
la valorisation du capital client, tels que Web Services et Business Intelligence, consulting en
innovation, Management de la Relation Client, mise à disposition d’indicateurs de pilotage.
INTEGRYTIS participe à l’amélioration des performances des entreprises en travaillant avec

ses clients sur l’optimisation de leurs indicateurs techniques, fonctionnels et métiers,
INTEGRYTIS offre également à ses clients une approche très différente grâce à une méthode
"collaborative" mettant l’accent sur le transfert de compétences et propose une offre cohérente
allant du conseil jusqu’à l’externalisation en passant par la réalisation et la formation.
INTEGRYTIS a choisi d’offrir à ses clients français la possibilité d’externaliser au Maroc
certaines parties ou la totalité de leurs projets BI ou CRM à travers sa filiale marocaine « ID
SOLUTION » dans des conditions de qualité optimales tout en bénéficiant d’une structure
française assurant le front-office client, la relation avec les utilisateurs, ainsi que la direction
de projet.
1.1.1. L’approche INTEGRYTIS

L’approche INTEGRYTIS consiste en un ensemble de méthodologies éprouvées avec
différents outils, optimisant la démarche d’intervention et de mise en œuvre.

Figure 1: Les cinq phases de l'approche INTEGRYTIS
Cette approche permet d’améliorer les performances des entreprises en travaillant avec ses
clients sur l’optimisation de leurs indicateurs techniques, fonctionnels et métiers [Figure 1].
1.1.2. Divisions
a. Division Business Intelligence

De par son expérience, son savoir-faire et la multiplicité de ses compétences techniques et
fonctionnelles, INTEGRYTIS apporte à ses clients le conseil nécessaire afin de faire du projet
BI une réelle réussite d’entreprise autant de point de vue utilisateur que de point de vue
informatique, et cela dans les domaines d’audit et proposition d’évolution, d’assistance au
choix d’outils, d’assistance à la maîtrise d’ouvrage, de cahier des charges, d’expertise
technique, d’architecture décisionnelle, de modélisation décisionnelle et de mise en place de
DataWarehouse et de DataMart.
Notre projet de fin d’études est mis en place en collaboration avec l’équipe de la division
Business Intelligence, qui met en avant une grande expertise fonctionnelle et technique dans
le domaine du risque de crédit et la mise en place des systèmes décisionnels.
b. Division CRM
Les systèmes d’information traditionnels renseignent très peu sur le « Client ». Grâce à sa
méthodologie CRM, INTEGRYTIS accompagne ses clients pour la réorganisation et la
réorientation «Client» dans leur système d’information. En effet, le CRM recouvre l'ensemble
des fonctions de l'entreprise visant à conquérir, connaître, cibler et fidéliser sa clientèle. Le
CRM regroupe la gestion des opérations de marketing, l'automatisation des forces de vente, le
service client, le centre d'appel et la BI. Forte de son expertise dans la valorisation du

potentiel « Client », elle accompagne ses clients sur toutes les phases de leur projet CRM,
grâce à un conseil méthodologique, pratique et orienté résultats.
1.1.3. Références
INTEGRYTIS bénéficie des compétences de consultants capitalisant de nombreuses années
d’expérience dans le domaine du CRM et du BI. Elle a pu par conséquence mener avec succès
de multiples projets pour ses clients, notamment MIF Assurances, Orange Telecom, Banque
de France, Groupe Caisse d’Epargne, Saint-Gobain PSA Peugeot Citroën et Méditel.
1.2. Cadre général du projet

1.2.1. Présentation générale de l’organisme bancaire
Notre client est un groupe bancaire marocain, un des leaders au Maroc. Il a pour ambition de
renforcer son positionnement à l’international, avec un ensemble de valeurs : transparence,
succession, excellence, performance, synergie et mobilité. Notre client s’est affirmé depuis sa
privatisation, en tant qu’institution de dimension internationale, qui s’appuie sur un modèle de
banque universelle. Ce sont près de 13 000 collaborateurs, présents dans une trentaine de
pays, qui accompagnent 6 millions de clients à travers un réseau multi-marchés de 1 400
agences. Il capitalise sur un modèle régionalisé couvrant l’ensemble du Royaume, et un
positionnement fort qui s’étend aux zones géographiques de l’Afrique, l’Europe, l’Asie et
l’Amérique du Nord.
Notre client offre toute une gamme de services et produits, réalisé par les personnes de la
banque afin de faire venir les clients et de les rendre fidèles, visant toutes les couches de
population tels que les comptes bancaires, les paiements scripturaux, la bancassurance, les
crédits, les virements et la compensation automatique.
• Organigramme du client :

Direction
Générale
DG Banque des DG Information

DG Banque de DG Finances et
Particuliers & Technology &
l'entreprise Risques GROUPE
Professionnels Process GROUPE
Risques GROUPE Finances GROUPE
Management des
Management des Analyse et suivi
risques à
Risques Maroc des engagements
l'internationnal
Figure 2: Organigramme du client d’Integrytis
La Direction générale de notre client est composée de quatre branches : Banque des
particuliers et professionnels, Banque de l’entreprise, Finances et Risques GROUPE et
Information Technology & Process GROUPE. Chacune de ces branches dirige des
départements comprenant des services.
Notre projet consiste à la mise en œuvre des outils décisionnels nécessaires afin de contrôler
et piloter les activités du département Risques GROUPE.
1.2.2. Contexte du projet

Au cours de ces dernières années marquées par une conjoncture économique moins favorable,
les banques ont poursuivi le développement de leur réseau tant à l’échelle nationale
qu’internationale, témoignant de leur volonté de capter de nouveaux clients et couvrir de
nouveaux marchés.
Cependant, le secteur reste toujours sous la menace d’exposition aux risques, ce qui nécessite
l’adéquation d’une méthodologie de gestion pour faire face à tout risque qui peut affecter la
chronique des flux à recevoir par un établissement bancaire.
Dans le cadre des activités des organismes bancaires, on distingue classiquement différents
types de risques: risque de crédit, risque de marché, risque opérationnel…
Le portefeuille bancaire est particulièrement risqué puisque l’enregistrement des prêts

bancaire au bilan comptable de la banque est une opération caractérisée par une incertitude
élevé sur les remboursements futurs. Cette incertitude est due principalement au risque

intrinsèque de chaque client et de chaque prêt. La gestion de ce risque de crédit est devenue
ainsi un besoin voire une obligation inéluctable.
Dans le souci de s'aligner aux normes internationales en matière de gestion de risque, les
institutions financières ainsi que les banques marocaines ont adopté des directives de Bâle II
[Annexe A] qui permettent une gestion plus optimale du risque de crédit.
Les réglementations prudentielles telles que Bâle II, imposent aux acteurs de marché des
contraintes strictes dans le pilotage de leurs risques et l’allocation des fonds propres. Ainsi,
l’évaluation du risque de crédit est une problématique centrale des organismes bancaires et
des investisseurs sur le marché de la dette qui doivent analyser le risque individuel de chacun
de leurs clients et le risque global de leur portefeuille de crédit.
Nous nous inscrivons donc dans la logique suivante : Afin de mieux gérer le risque de crédit,
il est nécessaire d’effectuer le suivi des expositions et des engagements de la banque. C’est
dans ce cadre que s’inscrit notre projet de fin d’études qui consiste à concevoir un DataMart
permettant la gestion du risque de crédit.
1.2.3. Objectifs du projet

Notre client souhaite se doter d’un DataMart regroupant toutes les informations autour des
expositions et des engagements de la banque, pour cerner au mieux le risque de crédit.
En réponse à ce besoin, il s’avère nécessaire de concevoir un DataMart Risque de Crédit, qui

centralise les données de la banque nécessaires pour la gestion de ce risque. En effet ce
DataMart doit regrouper de façon cohérente et uniforme l’ensemble des données éparpillées
dans les différents systèmes opérationnels de la banque. Il doit aussi permettre l’élaboration
des états de restitution au département Risques GROUPE de notre client pour le suivi de son
activité.
A travers cette solution, notre client souhaite atteindre les objectifs suivants :
• Avoir un DataMart centralisant les données indispensables à la gestion de crédit.
• Détenir un DataMart historisant les données de gestion de crédit.
• Suivre l’évolution des engagements de la banque à travers des rapports.

1.2.4. Conduite du projet

a. Phases du projet
Pour assurer le bon déroulement du projet, nous avons opté pour le choix du diagramme
GANTT pour évaluer la durée du projet tout en précisant les tâches de chaque phase. Dans ce
qui suit, nous présentons une brève description de ces phases :
• Formation en Oracle Data Integrator : Une plate-forme complète d'intégration de

données couvrant toutes les exigences en matière d'intégration de données.
L'architecture E-LT (extraction, chargement et transformation) d'Oracle Data
Integrator exploite des moteurs de SGBDR disparates pour traiter et transformer les
données ; une approche qui optimise les performances et l'évolutivité, et réduit les
coûts globaux.
• Analyse de l’existant : Cette phase consiste en la connaissance parfaite des
différentes structures de données du client qui alimentent le DataMart, ainsi que la
structure des entrées d’une application alimentée par le DataMart Risque de Crédit.
• Spécification des besoins : Cette étape consiste à bien comprendre et analyser les
besoins du client afin d’aboutir à une solution s’alignant parfaitement avec ses
attentes.
• Conception: Une étape importante à la conception d’un DataMart et des tableaux de
bord est de déterminer en clair l’objectif de ces derniers afin d’avoir la version du
modèle de DataMart la plus adaptée au client et des rapports nécessaire à la meilleure
gestion du risque de crédit de notre client.
• Phase de développement : Cette phase consiste à extraire, nettoyer et transformer les
données en utilisant un ETL « Extract, Transform, Load » émanant de diverses
sources pour ensuite les insérer dans le DataMart, qui nous servent pour l’élaboration
des rapports aux utilisateurs finaux
• Tests et validation: Ils sont réalisés à la fin de chacune des étapes pour valider le
travail avec le client.
b. Planning du projet
Le diagramme de GANTT suivant présente les différentes phases de projet tout en spécifiant
les tâches et les périodes relatives à chacune.

Figure 3: Diagramme GANTT du projet
Le déroulement de notre projet démarre par une formation sur le domaine fonctionnel du
risque de crédit et l’outil ETL que nous utilisons qui prend environ 11% de la durée du projet,
ensuite nous analysons le système existant chez notre client et nous spécifions les besoins de
ce dernier avec 16% de temps du projet, par la suite la phase la plus importante qu’est la
conception du DataMart et des tableaux de bord qui occupe environ 14% du projet et enfin la
phase de développement et des tests avec un pourcentage de 57% de la durée du projet.
c. Livrables du projet
Les livrables représentent les résultats attendus après l’achèvement des différentes parties du
projet. La liste et la description des livrables de chaque phase sont détaillées dans le tableau
ci-dessous.
Etape Livrables
Formation Oracle Data Integrator Document d’installation d’Oracle Data
Integrator
Spécification des besoins Dossier de Conception :

• Matrice des besoins regroupant les

indicateurs et les axes d’analyse
Conception du DataMart et des rapports Dossier de Conception :
• Schéma du DataMart
• Liste détaillée des règles
d’alimentation
• Maquette des rapports
Phase Développement Dossier d’ETL :
• Description des sources de données

• Description des flux ETL
Elaboration des rapports
Tests et validation Rapports de tests

Tableau 1: Livrables du projet
Conclusion
Le premier chapitre présente l’organisme d’accueil et positionne le projet dans son cadre
général. Notre projet consiste à la réalisation d’un DataMart destiné au département Risques
GROUPE de notre client pour le suivi de son activité de gestion de risque de crédit. Pour la
concrétisation de notre projet, un planning est élaboré afin de fixer les différentes phases de ce
dernier, tout en précisant les différents livrables de chaque phase.
Dans le chapitre suivant, nous allons exposer l’étude de l’existant et l’analyse des différents
besoins fonctionnels et techniques que l’organisme bancaire souhaite implémenter.

Chapitre 2
Analyse et spécification
Ce chapitre a pour but de définir le domaine fonctionnel du risque de crédit et d’étudier le

système existant du client et d’analyser par la suite les objectifs du projet et les besoins de
notre client.

Chapitre 2 Analyse et spécification
2. Analyse et Spécification
Dans ce chapitre nous analysons les différents systèmes existants chez notre client pour la
gestion de risque de crédit afin de déterminer les besoins et les objectifs à réaliser.
2.1. Vue générale sur le risque de crédit
2.1.1. Définition du risque de crédit

Le risque de crédit se définit comme étant la probabilité qu’un débiteur soit dans l’incapacité
de faire face au remboursement du crédit octroyé par une institution financière. Le risque de
crédit est fonction de la qualité de l’emprunteur.
2.1.2. Cadre réglementaire

En vue de rassurer les déposants et de se prémunir contre une crise financière majeure, les
pays se sont dotés de structures indépendantes chargées de surveiller la santé de leur système
financier.
Le principe général de la réglementation bancaire est de requérir des réserves de la part des
banques afin de couvrir les pertes éventuelles non anticipées.
C’est dans ce sens que les accords de Bâle II ont été signés en 2004 par les gouverneurs des
banques centrales du comité de Bâle. Ils proposent un certain nombre de normes prudentielles
pour limiter les risques bancaires comme le risque de crédit ou de contrepartie, en jouant sur
les exigences de capitaux propres. En particulier, ils proposent la mise en place du ratio
McDonough, qui limite le montant des prêts accordés en fonction du niveau des capitaux
propres et du risque des prêts.
Le comité de Bâle n'a aucun pouvoir législatif ou réglementaire. Pour son application, Bâle II
nécessite une transposition législative et réglementaire dans chaque pays. Ses nouvelles
directives relatives aux fonds propres à l'échelle internationale ont valeur de
recommandations. Il appartient donc aux différentes banques centrales des les adapter à leur
système.
Au Maroc, Bank Al Maghreb a arrêté en tant que banque centrale les dispositions requises
pour l'application des directives Bâloises au niveau des banques marocaines. En effet, elle a
organisé des ateliers de travail pour fixer les discrétions nationales. Ainsi, plusieurs circulaires
ont été diffusées, notamment celles relatives à la gestion des risques (risque opérationnel,
risque de marché et risque de crédit).

Dans le cadre des exigences bâloises en matière de gestion des risques, les banques
marocaines ont vu naitre de nouveaux besoins relatifs à la mise en place du système de
gestion du risque de crédit selon l'approche standard fixée par Bank Al Maghreb comme
phase préliminaire, pour passer par la suite à l’approche avancée.
2.1.3. Mesure de risque de crédit

Les banques ont le choix entre diverses approches pour déterminer leur niveau de fonds
propres requis : elles peuvent utiliser soit les évaluations des agences de notation externe
(approche standard), soit leur modèle de notation interne (NI). Par ailleurs, nous distinguons
deux approches pour calculer l’exigence en fonds propres réglementaires : approche standard
et approche avancée.
• Approche standard
L’approche standard par défaut servant à calculer les actifs pondérés en fonction des risques.
En vertu de cette approche, nous nous servons des évaluations faites par des organismes de
notation admissibles pour déterminer les coefficients de pondération des risques liés aux
éléments suivants : créances d’emprunteurs souverains et de banques centrales, d’entités du
secteur public n’appartenant pas à une administration centrale, des banques multilatérales de
développement, de banques et entreprises d’investissement.
• Approche avancée
L’approche avancée est fondée sur les notations internes (NI) (Internal Ratings Based
Foundation, IRB) est la deuxième façon d’évaluer le risque de crédit et accorde à celui-ci une
importance nettement plus grande que l’approche standard dans le calcul de la dotation en
fonds propres. Les pondérations des risques s’appuient sur les évaluations ou notation interne
des banques.
En effet avec l’approche avancée, la pondération des risques est fonction des variables et de
classes d’exposition (grandes entreprises, petites et moyennes entreprises, emprunteurs
souverains). Les variables sont les suivantes : Probabilité de défaut (PD, Probability of
Default), Perte en cas de défaut (LGD, Loss-Given-Defaut), Exposition en cas de défaut
(EAD, Exposure-At-Default).
2.1.4. Stress test

Stress test [1] est une technique de simulation utilisée sur les portefeuilles d'actifs et de passifs
pour déterminer leurs réactions à différentes situations financières, est une méthode utile pour

déterminer comment un ensemble de crédits se comportera pendant une période de crise

financière. Ils sont généralement des modèles de simulation générés par ordinateur qui testent
des scénarios hypothétiques.
Un stress test est également utilisé pour évaluer la solidité des institutions face au changement
des facteurs de stress comme les taux d’intérêt, le taux de chômage, conditions de prêt. Les
banques appliquent souvent ces tests sur elles-mêmes.
Un stress test est donc une procédure visant à créer des simulations de crise, à travers des
scénarii de stress qui peuvent être de nature variée :
- Scénarii dit historiques, c’est-à-dire basés sur des expériences passées

- Scénarii dit hypothétiques, c’est-à-dire basés sur des événements jugés possibles à
l’avenir : changements éventuels des facteurs macroéconomiques, sociologiques
ou politiques
- Tests de sensibilité pouvant consister à augmenter ou à dégrader instantanément
des paramètres de risque, préalablement définis, d’un ou plusieurs grades ou en
termes de pourcentage directement sur les paramètres bâlois PD / LGD
ou indirectement sur les facteurs sous-jacents au calcul de ces paramètres
Figure 4: Différents usages des stress tests
2.2. Analyse de l’existant

La connaissance de l’existant est une phase indispensable qui sert de base pour accompagner
le client dans la réalisation de ses besoins afin d’améliorer son système tout en gardant les
fonctionnalités principales existantes.

2.2.1. Dispositif de gestion de risque de crédit

Notre client possède des applications qui lui permettent de gérer son risque de crédit, nous en
citons l’application Fermat pour le calcul des fonds propres pour faire face à des éventuelles
pertes.
• Application Fermat
Fermat est une solution de gestion de risques de crédit, une référence quant à sa performance,
fiabilité et cohérence sur le marché mondial. Avec l’arrivé des normes dites de Bâle II, Fermat
devient l’un des rares spécialistes. Cette application évalue l’exposition au risque de crédit et
au suivi des limites de ce dernier et permet aussi la gestion des actifs et passifs à travers la
gestion des risques et du pilotage stratégique dans le domaine financier.
Fermat offre une application permettant le calcul des exigences en termes de fonds propres
(calcul des expositions brutes, des pondérations…), en utilisant 42 fichiers comme Input
[Figure 6] concernant les engagements, les provisions, les garanties, les clients…, y compris
ceux concernant la partie filiale.
La fréquence des calculs de Fermat est mensuelle, parce que les données relatives à la gestion
de crédit s’évaluent mensuellement.
Figure 5: Entrées et sorties de l'application Fermat du client
• SAS DDS
L’application FERMAT utilise une approche standard, l’objectif de notre client est de se doter
des moyens nécessaires pour aller vers l’approche avancée en intégrant les données FERMAT
(Input et Output) dans l’entrepôt risque de crédit.
Pour atteindre cet objectif, le client a fait un choix de se référer à l’expertise SAS moyennant
le référentiel central SAS®Detail Data Store for Banking appelé fréquemment DDS for
Banking. Il englobe le détail des données issues des différents systèmes opérationnels. C’est
un produit SAS qui garantit l’uniformité, l’exactitude et la cohérence des données qui sont des
informations fondamentales autour desquels la banque structure son activité.

A la fin du développement du projet « Mise en place d’un entrepôt de données SAS®Detail

Data Store for Banking », la recette de cette solution démarre et depuis lors des manques sont
constatés sur la solution SAS DDS, nous pouvons citer quelques unes :
• Pour le besoin de gestion de risque de crédit, le client n’alimente que le tiers des
champs du modèle de données du référentiel, en plus il a besoin d’ajouter des modules
supplémentaires pour les informations non couvertes par le modèle nécessaire à la
gestion du risque, afin de couvrir l’écart entre ce modèle DDS et les données dont le
clients a besoin pour gérer son risque de crédit.
Figure 6: Les tables alimentées du modèle logique de données DDS
• Actuellement notre client utilise l’approche standard, et il a un objectif de passer à

l’approche avancée. Pour ce faire, notre client doit se doter d’un historique de cinq ans
minimum des calculs fournit par Fermat et des données concernant les crédits de ces
clients. En effet, la solution de SAS DDS permet de faire cette historisation, sauf
qu’elle ne contient pas une table ou une dimension ‘Date’ qui pourra faciliter des

analyses dans le temps des données du risque de crédit et la récupération de certaines

informations pour y effectuer des stress tests.
• Le développement et la maintenance de la solution SAS DDS de notre client devient
difficile, du fait de la complexité du référentiel SAS®Detail Data Store for Banking,
que nous l’utilisons pas complètement, et le rajout de modules supplémentaires pour
couvrir le besoin du risque de crédit. Cette difficulté rend la durée du projet « Mise en
place d’un entrepôt de données SAS®Detail Data Store for Banking » supérieur au
délai prévu par le département Risques GROUPE pour la mise en place d’un modèle
de données répondant à ses besoins.
De ce fait, notre client suggère d’abandonner l’entrepôt de données SAS®Detail Data Store
for Banking et de mettre en place un DataMart risque de crédit qui répond au mieux aux
spécificités de son besoin. A cet égard, nous alimentons notre DataMart de différentes sources
de données opérationnelles de notre client, puisque le référentiel SAS DDS n’est plus en
place.
2.3. Expression des besoins
2.3.1. Conception et réalisation d’un DataMart risque de crédit
Notre client décide de se tendre vers le choix de la méthode avancée afin d’être plus près de la
réalité. Cette approche permet à chaque banque de réaliser ses propres évaluations du risque
de crédit. Pour ce faire, la banque a besoin d’un entrepôt de données qui permet de gérer et
historiser de milliers d’enregistrements sur chacun des crédits accordés de manière centralisée
au moyen d’un système automatisé.
Ce DataMart va pouvoir centraliser les données autour du risque de crédit, en commençant

par la connaissance détaillée de la clientèle de la banque, les crédits octroyés à ces derniers,
les garanties déposées pour obtenir ces crédits et les provisions mis par la banque pour faire
face à l’insolvabilité de ces clients. Ensuite, les données d’engagements des clients, en suivant
les encours des clients et les autorisations accordées aux clients (comme les découverts,
prélèvement automatique). Enfin, les données autour des expositions de la banque, en ayant
une vision sur les créances douteuses et litigieuses et la situation des impayés.
L'enjeu d'implémentation de la réglementation bâloise avec l’application Fermat, a fait naître

le besoin d’un assainissement des entrepôts de données de la clientèle pour fournir des

données très précises et d’une grande qualité lors du processus de calcul de risque de crédit
par cette application. Et donc, la mise en place d’un entrepôt de données fournissant les
informations de qualité nécessaires pour Fermat, est un des principaux besoins de notre client.
L’historisation des calculs des exigences de réglementation bâloise en termes de fonds

propres effectués par l’application Fermat, est un besoin de poids du client. En effet, sur ces
exigences que notre client effectue des stress tests, en plus de l’importance du suivi de
l’évolution de ces calculs pour la banque puisqu’il renseigne sur sa situation financière, sa
capacité à faire face à l’insolvabilité de ses clients.
Le suivi des engagements et des expositions de la banque permet de gérer au mieux les crédits
octroyés. Notre client souhaite à travers le DataMart Risque de crédit, de restituer des
tableaux de bord de suivi de ces engagements et de ces expositions utilisables au niveau des
différents services du département Risques GROUPE.
Le DataMart Risque de crédit répond aux besoins de la figure suivante :
Figure 7: Schéma des besoins couverts par le DataMart Risque de crédit
Les besoins de notre client pour le DataMart Risque de crédit sont définis comme suit :
- Un DataMart pour les données autour du métier de gestion de risque.

- Un DataMart contenant les données Input Fermat.

- Un historique des calculs fournit par Fermat.
- Le suivi des engagements et des expositions de la banque à travers des tableaux de
bord.
2.3.2. Spécifications fonctionnelles
Une bonne gestion de risque de crédit nécessite un référentiel unique qui retrace toutes les
opérations effectuées après l’obtention d’un contrat de crédit et l’évolution du portefeuille
d’engagements et d’expositions. Ce référentiel est un DataMart défini par des tables de faits
qui contiennent des indicateurs et des tables de dimension qui permettent le calcul des
mesures. Ci-après une liste non exhaustive de ces indicateurs :
• Indicateurs
Indicateurs Description Enjeux Règles de gestion

Montant impayé Le montant impayé Ce montant est comparé avec les La somme des
des prêts provisions afin de les réajuster. Il impayés des clients
permet aussi d’avoir une vision
sur les crédits qui sont à risque
Montant intérêt Le montant des Ce montant représente les La somme des
impayé intérêts impayés bénéfices non payés de la banque. intérêts impayés des
des prêts Il indique les pertes générées par clients
les impayés
Montant solde Le solde de cartes Ce montant indique les prêts non La soustraction du
de crédit, ou le remboursés, qu’est un actif détenu débit du crédit du
montant encours par la banque. Il correspond à compte des clients
des prêts l’argent qui a été mobilisé et qui
n’a pas encore été récupéré
Evolution Evolution du Cet indicateur met en évidence (le nombre
nombre nombre de clients l’évolution mensuelle du nombre d’engagements de ce
ayant un prêt d’engagements de la banque. Il est mois – le nombre
engagement
à noter que les engagements sont d’engagements du
une source de revenu pour la mois précédent)/ le
banque nombre
d’engagements du
mois précédent
Evolution total Evolution du Cet indicateur renseigne (le total
engagement montant des prêts l’évolution mensuelle des d’engagements de ce
des clients de la montants d’engagements de la mois – le total
banque banque. Il permet de voir si les d’engagements du
engagements de la banque sont en mois précédent) / le
hausse ou en baisse, afin de total d’engagements
penser à une nouvelle stratégie de du mois précédent
marketing
Montant Montant des Ce montant permet de savoir les La somme des

garantie garanties de la ressources matérielles possédées montants de

banque par la banque pour faire face à garanties déposées
l’insolvabilité des clients. En effet par les clients
les garanties est un des
atténuateurs de risque de crédit
Montant suretés Montant des Comme l’indicateur précédent (les La somme des
financières sûretés financières sûretés financières sont aussi des montants de
que possède la atténuateurs de risque de crédit), il garanties de type
banque indique les ressources financières sûreté financière des
possédées par la banque pour faire clients
face à l’insolvabilité des clients
Risques Montant du risque Cet indicateur reflète les risques Calculé par
pondères de la banque que la banque encourt selon les l’application Fermat
classes d’exposition
Montant Montant des Ce montant permet de suivre les La somme de
exposition expositions de la expositions au risque de défaut de l’argent investi et
banque la banque l’argent prêté
Montant fonds Montant des fonds Cet indicateur nous donne une Calculé par
propre propres vision sur la liquidité d’assurance l’application Fermat
contre les dépréciations non
anticipés des actifs du bilan de la
banque
Tableau 2: Indicateurs du DataMart Risque de crédit
• Axes d’analyse
Le tableau suivant représente les axes d’analyse retenu pour les indicateurs ci-dessus :
Axe d’analyse Description

Tiers Les clients, le personnel et les garants de la
banque
Pays Les pays des clients de la banque
Contrat crédit Les contrats signés lors d'un octroi d'un
crédit, ou les facilités sur les cartes de crédit
Garantie Les garanties déposées pour obtenir un crédit
ou une carte de crédit
Statut Le statut du prêt (sain, impayé, pré-douteux,
douteux, compromis...)
Provision Les provisions de la banque pour faire face à
l'insolvabilité d'un client
Facilite crédit Les facilités ou autorisations assignées à un
crédit ou à une carte de crédit
Nature engagement Les engagements sains et les engagements en
souffrance
Type exposition Les expositions du Bilan et les expositions
Hors-bilan
Classe exposition Les classes d’expositions sont les créances
sur les différents types de clientèle (créances

sur les emprunteurs souverains, créances sur

les institutions, créances sur la grande
entreprise...)
Catégorie fonds propres Les différentes catégories de fonds propres
(fonds propres de base, complémentaires
admissibles, surcomplémentaires
admissibles)
Maturité résidentielle (dimension Le reste du temps jusqu’à la fin du contrat du
dégénérée) crédit. Il renseigne sur le délai qui reste à
courir avant la fin du contrat
Date Les dates des événements dans le DataMart
Tableau 3: Axes d'analyse du DataMart Risque de crédit
• Matrice de croisement
En croisant les mesures avec les différents axes d’analyses, nous obtenons la matrice
présentée dans la figure ci-dessous. Cette matrice nous permet de regrouper les mesures en
tables de faits entourées par les axes d’analyse pour concevoir le DataMart Risque de crédit.
Contrat Crédit
Axes analyse
Facilite crédit
fonds propres
résidentielle
engagement
exposition
exposition
Indicateurs
Catégorie
Provision
Garantie
Maturité
Nature
Classe
Statut
Tiers
Type
Date
Pays
Montant impayé X X X X X X X X
Montant intérêt X X X X X X X X
impayé
Montant solde X X X X X X X X
Evolution nombre X
engagement
Evolution total X
engagement
Montant garantie X X X
Montant sûretés X X X
financières
Risques pondères X X X
Montant X X X
exposition
Montant fonds X
propres
Tableau 4: Matrice de croisement DataMart Risque de crédit

2.3.3. Spécifications techniques
Une fois les spécifications fonctionnelles sont déterminées, nous passons aux spécifications
techniques de l’architecture de notre projet, qui respecte les phases habituelles de la chaîne
décisionnelle allant de l’extraction jusqu’à la restitution des données.
Le choix des solutions logicielles pour chaque étape de la chaîne décisionnelle peut
s’effectuer une fois l’analyse du besoin achevé. Dans ce qui suit nous présentons les outils
choisis avec leurs justifications
• Base de données et ETL:
Nous adoptons la base d’Oracle et l’ETL Oracle Data Integrator comme choix technique
justifié en premier lieu par la détention de licences Oracle par le client ainsi que les
administrateurs d’Oracle Database et d’Oracle Data Integrator assurant l’installation et le bon
fonctionnement de la base de données Oracle et de l’ETL Oracle Data Integrator, et en
deuxième lieu la simplicité des deux phases dans le cycle de vie de notre projet de mise en
œuvre du DataMart Risque de crédit :
- Phase d’intégration :
Puisque la plupart des applications et bases de données de notre client sont mises en œuvre
sous Oracle, nous avons donc l’expertise nécessaire pour le déploiement de notre DataMart au
sein du système d’information de notre client.
- Phase d’exploitation :
Après déploiement du DataMart en production, la gestion des incidents sera confiée au

service chargé du support informatique du client. En outre, puisque notre client a une
compétence confirmée en Oracle, il sera relativement autonome de réaliser la maintenance
évolutive.
• Restitution des données:
Pour l’outil de restitution de données nous sommes en face d’un choix entre deux outils de
Reporting OBIEE d’Oracle et SSRS de Microsoft. En effet, l’installation de l’OBIEE est peu
pratique par rapport à SSRS. En plus, l’outil de Reporting de Microsoft SSRS offre plus de

fonctionnalités de production de rapports ergonomique que l’outil de Reporting d’Oracle

OBIEE. Ce dernier outil permet de produire des rapports de sources différentes, à la
différence de SSRS, sauf que nous n’avons qu’une source de données qu’est le DataMart mis
en place. Enfin, nous citons le coût d’implémentation d’OBIEE qu’est élevé vu l’effort
important fourni par les administrateurs durant l’installation et la maintenance par rapport à
SSRS qui nécessite juste le coût de licence.
De ce fait, il nous paraît évident de choisir SSRS puisque les deux outils offrent les mêmes
fonctionnalités d’élaboration de rapports, sauf qu’OBIEE nécessite un effort supplémentaire
des administrateurs de base de données lors de la maintenance de l’outil et par conséquent un
coût supplémentaire.
Conclusion
Ce chapitre présente la phase d’analyse et de spécification avec l’objectif d’éclaircir le besoin
de notre client. La description des méthodes de gestion du risque de crédit de notre client et
les solutions existantes de ce dernier, nous a permis de proposer l’architecture de la solution
répondant au besoin de notre client à mettre en place. Pour le suivi de l’activité de gestion de
risque de crédit, nous avons présenté les indicateurs et les axes d’analyse associés. Enfin, afin
de mettre en place notre solution, nous avons effectué un choix technique tout en tenant
compte des technologies existantes chez notre client.
Dans ce qui suit, nous présenterons la partie conception et modélisation de la solution objet de
notre projet.

Chapitre 3
Conception
Ce chapitre a pour objectif d’exposer la modélisation du DataMart Risque de crédit et la

conception des rapports après avoir présenté les concepts de la modélisation
multidimensionnelle.

Chapitre 3 Conception
3. Conception
Dans ce chapitre nous allons exposer les concepts généraux de la modélisation

multidimensionnelle, présenter la modélisation du DataMart solution, et enfin définir la
conception des tableaux de bord demandés par notre client.
3.1. Définition des entrepôts de données
Les entrepôts de données sont définis par Bill Inmon dans son ouvrage « Using the Data
Warehouse-1994- » comme étant une collection de données orientées sujet, intégrées, non
volatiles, historisées et organisées pour le support d’un processus d’aide à la décision.
Cependant dans la pratique il existe également ce qu'on appelle des DataMarts ou magasins de
données, c'est-à-dire des sous-ensembles d'un entrepôt de données, contenant des informations
se rapportant à un secteur d'activité particulier. Ils sont définis comme étant un extrait de
l'entrepôt des données où les données extraites sont adaptées à une classe de décideurs ou à un
usage particulier.
Les DataMarts peuvent être perçus comme des petits entrepôts constitués d'un ensemble de
données correspondant à un sujet précis, rendant très rapide les temps de réponse aux
requêtes.
Comme notre projet est structuré autour du domaine d’analyse des risques de crédit, nous
allons concevoir un DataMart spécifique à ce domaine.
3.2. Conception du DataMart
3.2.1. Les tables du DataMart
Conceptuellement, les données du DataMart sont interprétées sous forme d’indicateurs

répartis selon des axes d’analyse. Ainsi techniquement, la modélisation du DataMart,
regroupe les indicateurs sous forme de tables nommées faits, et les axes d’analyse sous forme
de tables nommées dimensions.

• Tables de faits: La table de faits contient les indicateurs relatifs au domaine. Elle se
trouve au centre de notre modèle de données et est liée aux dimensions par des
relations de référence.
• Tables de dimensions : Les tables de dimensions sont les tables qui entourent les
tables de faits. Ce sont plus particulièrement les axes d’analyse des indicateurs.
Contrairement aux tables de faits qui contiennent l’information mesurable à observer,
les tables de dimensions sont composées d’attributs qui servent de descriptifs aux faits.
Dans ce qui suit, nous présentons l’ensemble des tables du DataMart Risque de crédit:
La table de dimension Tiers :
Figure 8: Table dimension Tiers
Source : élaboration personnelle
La table de dimension Tiers contient les informations des clients de la banque, notamment les
individus, les entreprises, les garants des prêteurs et le personnel de la banque. Cette table
contient les attributs d’un tiers et nous différencions les différents types de ce dernier par des
flags : flag individu, flag entreprise, flag personnel, flag garant.

La table de dimension Provision :
Figure 9: Table dimension Provision
La table de dimension Provision est liée à un Tiers, et représente le montant de provision

réservé par la banque pour faire face à l’insolvabilité de ce Tiers.
La table de dimension Pays :
Figure 10: Table dimension Pays
La table de dimension Pays est aussi liée à la table Tiers, et contient les pays des différents
Tiers avec une notation donnée par la banque à ce pays.
La table de dimension Contrat Crédit :
Figure 11: Table dimension Contrat crédit

La table de dimension Contrat crédit contient les différents contrats établis pour l’obtention
des crédits. Elle inclut les informations suivantes :
- Catégorie de contrat permet de distinguer entre un prêt immobilier, un prêt de

consommation, une carte de crédit, un découvert et un crédit documentaire import ou
export.
- Type de contrat associé à chaque catégorie de contrat
- Montant, devise et durée du contrat
- Dates du contrat : la date de signature du contrat, date du remboursement de la totalité
du prêt
La table de dimension Garantie :
Figure 12: Table dimension Garantie
La table de dimension Garantie est liée à Contrat crédit, et qui représente les garanties
déposées pour l’obtention d’un crédit. La garantie peut être de plusieurs types : hypothèque,
titre, collatéral financier. Ces types de crédit se distinguent avec l’attribut id_typeGarantie.
La table de dimension Classe risque :
Figure 13: Table dimension Classe risque

La table de dimension Classe risque regroupe les classes de risque interne à la banque se
trouvant dans la colonne ‘Catégorie’ de la figure suivante :
Figure 14: Les classes de risque de l'organisme bancaire
La table de dimension Statut :
Figure 15: Table dimension Statut
La table de dimension Statut regroupe les statuts d’un prêt considéré par la banque qui peut
être : sain, impayé, pré-douteux, douteux ou compromis.

La table de dimension Facilite Crédit :
Figure 16: Table dimension Facilite crédit
La table de dimension Facilité crédit est liée au contrat de crédit et contenant la facilité
associée à ce crédit.
La table de dimension Type exposition :
Figure 17: Table dimension Type Exposition
La table de dimension Type exposition représente les éléments du bilan et hors-bilan de la

banque.
La table de dimension Classe exposition :
Figure 18: Table dimension Classe exposition
La table de dimension Classe exposition représente les créances sur les différentes catégories
de clientèles, à savoir la clientèle de détail, les établissements de crédit, les emprunteurs
souverains, les grandes entreprises, les institutions, les petites et moyennes entreprises (PME)
ou les très petites entreprises (TPE).

La table de dimension Catégorie fonds propres :
Figure 19: Table dimension Catégorie fonds propres
La table de dimension Catégorie fonds propres contient les différentes catégories de fonds
propres : fonds propres de base, complémentaires admissibles, sur-complémentaires
admissibles.
La table de dimension Date :
Figure 20: Table dimension Date
La table de dimension Date est une table qui se présente pratiquement dans tous les entrepôts
de données, vu qu’elle permet l’historisation des indicateurs durant le temps.
La table de dimension Nature engagements :
Figure 21: Table dimension Nature engagement
La table de dimension Nature engagement regroupe les différents engagements que peut avoir
un tiers avec la banque tels que : Engagements sains par caisse (Crédits de campagne,
Comptes ordinaires débiteurs…), Engagements sains par signature, Engagements en
souffrance par caisse, Engagements en souffrance par signature.

La table de faits Fact Opération Crédit:
Figure 22: Table de faits FactOperationCredit
La table de faits Fact Opération Crédit contient les indicateurs calculés après que le client
effectue un certain nombre d’opérations que ça soit des retraits de carte de crédit ou des
remboursements. Ces indicateurs sont : le montant impayé, le montant des intérêts impayés, le
montant solde (solde de carte de crédit, ou l’encours du prêt).
La table de faits Fact Engagements :
Figure 23: Table de faits FactEngagements
La table de faits Fact Engagements contient les indicateurs pour suivre la structure et
l’évolution mensuelle du portefeuille d’engagements. Elle permet aussi la visualisation de la
concentration des engagements par client, par catégorie de clientèle, par groupe d’affaires, par
secteur d’activité ou par filiales, et enfin la mesure de la ventilation des engagements par
classe de risque de crédit. Ces indicateurs sont : le nombre d’engagements et ses montants
ainsi que leur évolution, le poids des montants et l’évolution du poids.

La table de faits Fact Impayés Créances Douteuses:
Figure 24: Table de faits FactImpayesCreancesDouteuses
La table de faits Fact Impayés et Créances Douteuses contient les indicateurs pour suivre la
situation des impayés et créances litigieuses et douteuses, ainsi que le taux de sinistralité.
Cette table contient les mesures suivantes : le total des montants, le poids des montants,
l’évolution du nombre, l’évolution du total et l’évolution du poids.
La table de fait Fact Exposition Portefeuille :
Figure 25: Table de faits FactExpositionPortefeuille

La table de faits Fact exposition portefeuille regroupe les indicateurs qui permettent de suivre
l’ensemble des créances accordées, que ce soit sous forme de prêts, d’acquisitions ou bien
encore de détention d’obligations.
La table de fait Fact Exigence Fonds Propres :
Figure 26: Table de faits FactExigenceFondsPropres
La table de faits Fact Exigence fonds propres permet de contenir un historique de fonds
propre résultant des calculs de Fermat et des stress tests effectués à des dates différentes.
3.2.2. La modélisation multidimensionnelle
Il existe différents modèles de conception à savoir : le modèle en étoile, en flocon et en

constellation. Nous citons les spécificités de chacun de ces modèles :
- Modèle en étoile : L’architecture de ce modèle est standard: Une table située au

centre de l’étoile, c’est la table des faits et des tables situées aux extrémités de la table
centrale, ce sont les dimensions.
- Modèle en flocon : Le modèle de données dit en flocon est une variante du modèle en
étoile : chaque table de dimension est ré-normalisée pour faire apparaître la hiérarchie
sous-jacente.
- Modèle en constellation : Dans un schéma en constellation, plusieurs modèles
dimensionnels se partagent les mêmes dimensions, c'est-à-dire, les tables de faits ont
des tables de dimensions en commun.
Pour notre projet, le modèle en flocon et le modèle en constellation s’avère les plus adaptés.
En effet, notre modèle est constituer de plusieurs table de faits, et pour chaque table de faits,
nous nous intéressons à la limitation de l’espace de stockage qu’à l’augmentation des
performances d’accès, vu que les données sont très volumineuses et que l’outil choisi permet
de traiter le côté de performance.

Dans ce qui suit nous présentons les différents modèles adoptés pour nos tables de faits.
• Le modèle flocon de la table de faits FactOperationCredit :
Figure 27: Modèle flocon de la table de faits Opération crédit

La table de faits Opération crédit contient les informations détaillées à propos des
engagements effectués par les clients de la banque. En effet, elle permet d’avoir une
connaissance pointue sur la clientèle à travers la dimension Tiers qui est normalisée avec les
tables de pays, notation externe (donnée par les agences de notation tel que Standard and
Poor’s), provision, bilans des entreprises. Nous pouvons également avoir une idée sur les
atténuateurs de risque que dispose la banque à travers la dimension contrat de crédit qui
expose les garanties déposées pour obtenir ce crédit. Enfin ce modèle va permettre
d’alimenter l’application Fermat du client.
• Le modèle en étoile de la table de faits FactEngagements :
Figure 28: Modèle en étoile de la table de faits Engagements

Ce modèle nous permet de suivre l’évolution des engagements de la banque selon plusieurs
dimensions : Tiers, Pays, Catégorie de clientèle, Facilité de crédit, Classe de risque, Nature
d’engagements et enfin la dimension Date mensuelle.
• Le modèle flocon de la table de faits FactImpayesCreancesDouteuses :
Figure 29: Modèle flocon de la table de faits Impayés et Créances douteuses
Ce modèle nous permet de suivre l’évolution des montants impayés des clients ainsi que les
créances douteuses de la banque selon plusieurs dimensions : Tiers, Catégorie de clientèle,
Durée d’impayé, Nature d’engagements et enfin la dimension Date mensuelle.
• Le modèle en étoile de la table de faits FactExpositionPotefeuille :

Figure 30: Modèle en étoile de la table de faits Exposition des portefeuilles
Ce modèle permet d’avoir les expositions de la banque calculées par l’application Fermat de
notre client.
• Le modèle en étoile de la table de faits FactExigenceFondsPropre :
Figure 31: Modèle en étoile de la table de faits Exigence en fonds propre
Ce modèle permet de disposer des différents fonds propres exigés pour faire face au risque de
crédit. Ils sont calculés par l’application Fermat de la banque.
La figure suivante représente le DataMart Risque de crédit :

Figure 32: Modèle logique du DataMart Risque de crédit

3.3. Conception des rapports
Le rapport est composé d’un ensemble d’indicateurs conçus pour permettre aux gestionnaires
de prendre connaissance de l’état et de l’évolution des systèmes qu’ils pilotent et d’identifier
les tendances qui les influenceront sur un horizon cohérent avec la nature de leurs fonctions.
C’est un outil de pilotage qui souligne l’état d’avancement dans lequel se trouve le processus
afin de permettre aux responsables de mettre en place des actions correctives.
Les tableaux suivants présentent les détails de la conception de quelques rapports relatifs au
processus de gestion de risque de crédit:
Indicateurs Axes d’analyse Objectifs et résultats attendus

Montant engagement mois Catégorie clientèle Permet de visualiser les montants
courant d’engagements et leur évolution par
Nature engagement rapport au mois dernier.
Montant engagement mois
avant
Evolution Montant
engagement
Tableau 5: Conception « rapport Evolution mensuel du portefeuille d'engagement »

Montant Encours Classe de risque Ce rapport permet d’avoir un aperçu
sur la ventilation des engagements
Poids du montant Encours par risque de crédit.
Evolution Montant Encours
Evolution Poids du montant

Encours
Tableau 6: Conception « rapport Ventilation des engagements par classe de risque de
crédit »

Nombre impayé Catégorie clientèle Ce rapport nous donne une vision sur
la situation des impayés par
Montant impayé Ancienneté ancienneté et catégorie de clientèle.
Evolution nombre impayé
Evolution montant impayé

Tableau 7: Conception « rapport Situation des impayés par ancienneté et par catégorie
de clientèle »

Les tableaux ci-dessus présentent quelques tableaux de bord utilisés par le département
Risques GROUPE pour suivre au mieux le risque de crédit. En effet, avec ces rapports nous
visualisons les engagements de la banque et ses évolutions, nous pouvons également ventiler
les engagements par classe de risque (les engagements les moins risqués aux engagements les
plus risqués), et enfin de situer les impayés par catégorie de clientèle et par durée d’impayé.
Conclusion
Ce chapitre décrit la phase de conception. Nous nous sommes focalisés sur la modélisation de
notre DataMart Risque de crédit. Ce dernier est composé de tables de faits contenant les
indicateurs et les dimensions associées pour la gestion du risque de crédit. Nous avons
également conçu les tableaux de bord nécessaires pour le département Risques GROUPE de
notre client afin de suivre son activité de gestion de risque de crédit.
Cette phase est primordiale dans la mesure où elle nous a permis de délimiter le projet et de
mettre en œuvre le fruit de nos études et analyses durant la période de stage. Ce chapitre sera
la base de la mise en œuvre de la solution par la suite.

Chapitre 4
Réalisation
Ce chapitre a pour objet de présenter la phase de réalisation qui concrétise la conception

exposée lors du chapitre précédent, après l’énonciation de l’architecture applicative de la
solution. Nous présentons également quelques exemples de rapports réalisés.

Chapitre 4 Réalisation
4. Réalisation
Ce chapitre est dédié à la partie mise en œuvre, tout d’abord nous présentons l’environnement
de travail en mettant en avance l’architecture applicative de notre projet, pour passer par la
suite à exposer les différents flux ETL élaborés pour l’alimentation du DataMart Risque de
crédit, et enfin afficher les tableaux de bord élaborés.
4.1. Présentation de l’environnement de travail
Le développement de la solution DataMart Risque de crédit fait appel à des outils et des
environnements de travail, qui figurent ci-dessous:
Figure 33: Architecture applicative de la solution
Comme spécifié dans le chapitre 2, notre client possède l’application Fermat que notre
DataMart va pouvoir l’alimenter ainsi que les sources de données sous différentes formes (des
bases de données sous Oracle, des fichiers .txt et des fichiers .csv). Pour notre solution, nous
décidons d’implémenter notre DataMart sous Oracle Database, en l’alimentant avec des flux
ETL sous Oracle Data Integrator et restituer les tableaux de bord à l’aide de l’outil de
Reporting SSRS.

4.1.1. Base de données: Oracle
Oracle Database est le système de gestion de base de données relationnelle

(SGBDR). Nous l’utilisons pour l’implémentation du DataMart.
Oracle Database, qui depuis l'introduction du support du modèle objet dans sa version 8 peut
être aussi qualifié de système de gestion de base de données relationnelle-objet (SGBDRO).
Fourni par Oracle Corporation, il a été développé par Larry Ellison, accompagné d'autres
personnes telles que Bob Miner et Ed Oates [2].
Ce système offre les fonctionnalités suivantes : la définition et la manipulation des données, la

cohérence des données, la confidentialité des données, l'intégrité des données, la sauvegarde
et la restauration des données, la gestion des accès concurrents.
4.1.2. Extraction, Transformation and Loading (ETL): ODI
• ETL :
ETL (Extract, Transform and Load), comme son nom l’indique, il permet la consolidation des
données à l’aide des trois opérations suivantes:
- Extraction: identifier et extraire les données de sources ayant subi une

modification depuis la dernière exécution;
- Transformation: appliquer diverses transformations aux données pour les nettoyer,
les intégrer et les agréger;
- Chargement: insérer les données transformées dans l’entrepôt et gérer les
changements aux données existantes.
• Oracle Data Integrator: ODI
Nous choisissons ODI pour la phase d’ETL, comme précisé lors des spécifications
techniques.
ODI possède une architecture E-LT (Extract, Load, Transform : extraction, chargement,
transformation) qui s'appuie sur divers moteurs de SGBDR (systèmes de gestion de bases de
données relationnelles) pour traiter et transformer les données. Cette approche optimise la

performance et l'évolutivité tout en réduisant les coûts de la solution. Plutôt que de s'appuyer
sur un serveur de transformation ETL séparé et conventionnel, l'architecture d'E-LT d'Oracle
Data Integrator génère du code natif pour divers moteurs de SGBDR (SQL et scripts de
chargement par lots par exemple). L'architecture d'E-LT extrait les données des sources, les
charge dans une cible et les transforme en utilisant la puissance de la base de données.
La figure qui suit montre la différence entre l’approche traditionnelle d’ETL et la nouvelle
approche d’ODI.
Figure 34: Différence entre l’approche ETL et l’approche E-LT d'ODI
L’ODI permet de constituer un ensemble homogène de données à partir des sources

hétérogènes (différentes bases de données SQL ou non, fichiers plats…). L’utilisation de
modules de connaissances (KM - Knowlegde Module), composants préprogrammés d’ODI,
rend ce logiciel extrêmement flexible et modulable.
4.1.3. Restitution des données: SSRS
SSRS est une plateforme serveur qui permet de mettre les données à disposition des
utilisateurs. Il fournit des fonctionnalités complètes de création de rapports pour différentes
sources de données. Reporting Services inclut un jeu complet d'outils à utiliser pour créer,
gérer et remettre des rapports, et des interfaces de programmation d'application (API) qui
permettent aux développeurs d'intégrer ou d'étendre le traitement des rapports et des données
dans les applications personnalisées. Les outils Reporting Services fonctionnent au sein de
l'environnement Microsoft Visual Studio et sont totalement intégrés aux outils et composants
de SQL Server.

Avec Reporting Services, on peut créer des rapports de type interactif, tabulaire, graphique ou
libre à partir de sources de données XML, relationnelles et multidimensionnelles. On peut
aussi publier des rapports, planifier le traitement de rapports ou accéder à des rapports à la
demande.
4.2. Mise en œuvre
4.2.1. Développement des flux ETL
La réalisation de notre DataMart fait appel à la phase d’ETL, cette dernière nous permet
d’alimenter notre DataMart et de générer les fichiers Input de Fermat.
Selon l’architecture d’ODI [Annexe B], le développement des flux ETL suit les étapes
suivantes :
• Création des architectures pour les données :
Pour connecter l’ODI avec les sources de données et les destinations de données, la création
de l’architecture physique et logique est nécessaire pour chacune des bases de données que ce
soit les bases de données du client, la base de données du DataMart et les fichiers Input de
Fermat. La figure suivante montre l’architecture physique et logique créée pour la base de
données Oracle.
Figure 35: Architecture physique et logique de la base de données Oracle

• Création des modèles de données :
La structure de données de chaque table des sources et du DataMart ainsi que des fichiers
plats de l’application Fermat, se fait au niveau de la zone ‘Modèles’ du projet crée sous ODI.
Par exemple, pour le fichier Input Fermat BBK_ACCOUNT, nous saisissons manuellement
les colonnes de ce fichier comme le montre la figure suivante. Par contre, pour les bases de
données Oracle, nous pouvons effectuer un ‘Reverse-engineering’ et obtenir les structures de
données des tables sous Oracle.
Figure 36: Création de la structure de données d'un fichier plat sous ODI
• Importation des modules de connaissances :
Les modules de connaissance sont des composants prédéfinis relatifs à certaines technologies
contenant des informations ODI qui servent pour un processus de génération dédié à cette
technologie, pour un traitement précis. ODI offre cinq types de modules de connaissances
[Annexe B], nous exposons dans ce qui suit les modules de connaissances que nous utilisons
pour l’alimentation du DataMart et la génération des fichiers Input de Fermat.
- Load knowledge module (LKM) : ce type de module de connaissance permet de

charger les données à partir d’une ou plusieurs sources de données. Pour ce type nous
utilisons : LKM SQL to SQL.

- Check Knowledge Module (CKM) : ce type de module de connaissance permet de

contrôler les données et de vérifier leur intégrité. Pour ce type nous utilisons : CKM
SQL et CKM Oracle.
- Integration knowledge module (IKM) : ce type de module de connaissance permet
d’intégrer les données dans la base cible. Pour ce type nous utilisons : IKM SQL to
File Append, IKM Oracle Incremental Update, IKM SQL Control Append.
Figure 37: Modules de connaissances importés
• Création des séquences :
Les dimensions du DataMart Risque de crédit sont structurées de la façon suivante : clé de
substitution SK (Surrogate Key), clé de production et les informations décrivant la dimension.
Les champs des dimensions s’alimentent de la source de données sauf les clés de substitution,
qu’eux ont besoin d’un générateur d’entiers qu’est la séquence. ODI permet de créer des
séquences dans notre projet. La figure suivante présente les séquences créées pour chaque
dimension du DataMart.

Figure 38: Séquences créées pour les dimensions du DataMart
• Création des interfaces :
Une interface est un élément graphique contenant un ou plusieurs sources de données et une
seule cible de données, elle permet de faire le Mapping entre la source et la cible, ainsi de
définir les transformations et les règles de gestion à appliquer.
- Interface d’alimentation de la table de correspondance garantie :
La table de correspondance garantie est une table permettant d’effectuer le lien entre
l’identifiant de la nature de garantie et la nature de garantie. Cette interface permet tout
simplement d’extraire les données d’un fichier Excel et les mettre dans une table Oracle.
Figure 39: Mapping de l’interface d’alimentation de la table de correspondance garantie

- Interface d’alimentation de la table dimension Tiers :
Afin d’alimenter la dimension Tiers, une jointure est nécessaire entre deux tables de notre
client contenant les informations de ses clients. Pour alimenter la clé étrangère de Tiers qui
fait référence à une notation externe, un Lookup sur la table notation externe (table en vert de
la figure) est nécessaire. La figure suivante est le Mapping entre les sources de données et la
cible qu’est la table de dimension Tiers.
Figure 40: Mapping de l’interface d’alimentation de la table de dimension Tiers
Pour remplir les champs vides sur le Mapping, nous utilisons un déclencheur lors de
l’insertion dans la table dimension Tiers. Ce déclencheur permet d’indiquer le type du Tiers
(individu, entreprise, personnel, client de la banque ou garant) à travers le positionnement
d’un ‘1’ ou ‘0’ sur les champs ‘flag’.
- Interface d’alimentation de la table dimension gage:
Le gage est le contrat de dépôt de garantie pour l’obtention d’un crédit. La table dimension
gage contient une clé étrangère vers le garant qui se trouve dans la table Tiers, les
informations du gage sont dans la table de la banque Centrale de Garantie et une clé étrangère
vers la garantie déposée dans la table garantie.

Figure 41: Flux de l'interface d'alimentation de la table de dimension gage
- Interface d’alimentation de la table faits Opération crédit:
L’alimentation de la table de faits opération crédit se fait en joignant deux tables de la base de
données du client : CRI (Compte rendu d’inventaires) et CDL (Créances douteuses et
litigieuses), afin de calculer les mesures contenues dans la table de faits. Les clés étrangères
de la table de faits sont les clés des tables de dimensions liées à cette table de faits en utilisant
des jointures entre ces tables, comme le montre les deux figures suivantes du flux et du
Mapping de l’interface d’alimentation de la table de faits Opération crédit.
Figure 42: Flux de l’interface d'alimentation de la table de faits Opération crédit

Figure 43: Mapping de l’interface d’alimentation de la table de faits Opération crédit
- Interface de génération du fichier Input COLLATERAL de l’application Fermat:
COLLATERAL est un type de garantie, il comprend les liquidités et assimilés, droits sur
établissements de crédit et créances d’exploitation. Afin de remplir le fichier avec les
informations sur les collatéraux du DataMart, nous utilisons deux tables de dimension la
garantie et le gage, et nous y effectuons un filtre sur le type de garantie qui doit être un
collatéral. Nous utilisons également la table de correspondance pour remplir les champs flag
de la cible, et nous utilisons également la table de faits pour récupérer l’identifiant du tiers, la
personne qui a déposé la garantie. La figure suivante illustre le Mapping entre les sources de
données (la table de dimension garantie, la table de dimension gage, la table de faits opération
crédit, la table de correspondance de la Centrale de Garantie de la banque) et la cible qu’est le
fichier Input Fermat COLLATERAL.
Figure 44: Mapping de l'interface du fichier Input COLLATERAL de l'application Fermat

• Création des packages :
Le package est la plus grande unité d'exécution dans Oracle Data Integrator. Un package est
constitué d'une séquence d'étapes organisée en un diagramme d'exécution. Chaque étape peut
soit réussir ou échouer son exécution. En fonction du résultat d'exécution d’une étape (succès
ou échec), cette dernière peut se brancher sur une autre étape.
Nous présentons deux packages réalisés lors de notre projet dans ce rapport. Le premier pour
l’alimentation de la table de faits Opération crédit et les tables de dimensions associées, et le
second pour la génération des fichiers Input de Fermat.
Le package d’alimentation de la table de faits Opération crédit est constitué d’une suite
d’étapes [figure 45] :
- En premier lieu, les tables de dimension Notation externe, Nature de garantie et

Facilité de crédit doivent être alimentées. En cas d’échec, un mail de notification est
envoyé.
- Ensuite, l’alimentation des tables de dimension Tiers, Garantie et Contrat crédit
s’effectue. En cas d’échec, une notification est effectuée par e-mail.
- Après l’alimentation des tables de dimension Tiers et Garantie, la table de dimension
Gage peut être alimentée puisqu’elle fait le lien entre la garantie et le garant. Dans le
cas d’échec d’une de ces étapes, un mail de notification d’erreur est transmis.
- Enfin, toutes les tables de dimension remplies, il est temps de charger les données
calculées dans la table de faits Opération crédit. En cas d’échec de cette opération, une
notification d’erreur est envoyée.

Figure 45: Package d'alimentation du DataMart
Le second package de génération des fichiers Input de l’application Fermat, la génération des
fichiers se fait séquentiellement comme le montre la figure suivante, et en cas d’échec un mail
de notification s’envoie.
Figure 46: Package de génération des fichiers Input de l'application Fermat
4.2.2. Edition des rapports
La dernière phase concerne la restitution des résultats à travers l’outil spécifié SSRS. Le
besoin de notre client est de générer des tableaux de bord et de les envoyer aux responsables
du risque de crédit. Pour ce faire, nous modélisons les tableaux de bord sous SSRS et nous
exportons le résultat généré en un PDF afin de l’émettre à son utilisateur.

Dans ce qui suit nous illustrons quelque tableaux de bord rassurant le suivi de la gestion du
risque de crédit. Ces tableaux de bord permettent de visualiser l’intérêt du travail en termes
d’ETL puisque les données sont issues de notre DataMart Risque de crédit.
• Tableau de bord évolution du portefeuille d’engagement :
Le tableau de bord « Evolution du portefeuille d’engagement » joue un rôle primordial dans le

pilotage de l’activité de gestion des crédits. En effet, les engagements d’une banque est une
source de revenus, et donc joue le rôle d’atténuateur de risque de crédit puisqu’il permet
d’avoir une idée sur la liquidité future de la banque pour couvrir le risque de crédit potentiel.
Ce tableau de bord permet de visualiser les montants d’engagements du mois courant et du
mois précédent, ainsi que leur évolution par rapport au mois dernier avec différents niveaux
d’agrégation.
Figure 47: Tableau de bord de l'évolution mensuelle du portefeuille d'engagement
Ce tableau de bord indique une évolution importante des engagements en souffrance par
caisse et les engagements en souffrance par signature ainsi que les provisions disposées pour
couvrir l’insolvabilité des clients. C’est un résultat inquiétant du fait que les engagements en
souffrance augmentent, et un résultat logique du fait que la banque a mis à sa disposition les
provisions nécessaires pour faire face à l’insolvabilité de ces clients. Pour les engagements
sains, une stabilité est remarquée pour les engagements sains par caisse, et une augmentation

importante sur les engagements sains par signature qu’est un indicateur de bonne situation
puisque les revenus de la banque sont en hausse.
• Tableau de bord ventilation mensuelle par risque de crédit :
Le classement des engagements par classe de risque est un élément de grande importance
dans la gestion de risque de crédit. En effet, les bénéfices les plus élevé de la banque sont
ceux des crédits les plus risqués puisque le taux d’intérêt est le plus élevé sauf que ce risque a
aussi un coût dans le cas d’insolvabilité des clients. Un compromis entre ces deux derniers
points doit être effectué, d’où l’intérêt de ce tableau de bord qui réparti les engagements du
moins risqué au plus risqué de ce mois et le mois d’avant tout en mettant en exergue
l’évolution de ces engagements.
Figure 48: Tableau de bord ventilation mensuelle par risque de crédit
Cet exemple de ce tableau de bord met en avant les encours les plus élevés dans la classe la
moins risquée avec un poids de 16.16%, ensuite les encours en deuxième niveau sont dans la
classe la plus élevé avec un poids de 14.80%. Ces deux chiffres permettent de conclure une
balance entre les encours les plus risqués (et donc les plus rémunérateurs) et les encours les

moins risqués (et donc les moins rémunérateurs). Vu que les engagements, sont en hausse par
rapport au mois précédent, une augmentation sur les encours est aussi constatée.
• Tableau de bord de la situation des impayés par ancienneté et par catégorie de

clientèle :
Les impayés est un élément qui entre enjeu dans le risque de crédit. Puisque ce dernier vient
du constat que les clients ne paient plus leurs échéances. Ce tableau de bord joue alors un rôle
important, du fait qu’il permet de visualiser les impayés par ancienneté (ou nombre
d’échéances non payées) et catégorie de clientèle. Avec ce tableau de bord, une alerte peut
être déclenchée dans le cas où les impayés dont la durée est supérieure à six mois est élevé,
car dans ce cas nous serons face à un risque de crédit élevé.
Figure 49: Tableau de bord de la situation des impayés par ancienneté et par catégorie
de clientèle
Ce tableau de bord généré montre la concentration des impayés qui se positionne au niveau de
la catégorie de clientèle « Autre Retail », et que les impayés sont peu dans la durée de 1 à 2
mois avec une augmentation très faible lors des autres durées d’impayé. Avec ce dernier

constat, le département Risques GROUPE décidera à ce que les impayés doivent être traités
dès leurs premières échéances avec leurs clients au lieu d’attendre une durée plus grande.
Conclusion
Ce chapitre met en avant la phase de développement. Nous avons exposé l’architecture
applicative de la solution proposée lors des spécifications techniques. La réalisation de notre
projet s’effectue selon différentes phases. L’alimentation du DataMart Risque de crédit qu’est
réalisée avec l’E-LT d’Oracle (Oracle Data Integrator) permet de générer les fichiers d’entrée
de l’application Fermat avec le même outil ODI, et d’élaborer les tableaux de bord pour le
suivi de l’activité de gestion de risque de crédit.
Nous clôturons ce rapport par une conclusion générale, relatant les différents aspects de ce
stage de fin d’études, les apports professionnels, techniques et humains, et enfin les
perspectives du projet.

Conclusion
Conclusion générale
L’objectif de notre projet de fin d’études fût la mise en œuvre d’un DataMart pour le compte
d’une banque marocaine, un client d’INTEGRYTIS, afin de suivre les engagements et les
expositions de ladite banque pour une bonne gestion du risque de crédit. Ce DataMart a pour
objectifs de fournir les informations d’entrée de l’application Fermat, ainsi l’historisation des
calculs produits par Fermat et enfin de centraliser et de structurer les données de la gestion du
risque de crédit en vue de restituer des tableaux de bord pour le département Risques
GROUPE de notre client.
Pour ce faire, nous avons suivi le cycle classique de projet décisionnel. Nous avons étudié et
analysé les besoins du département Risques GROUPE en termes d’indicateurs de suivi du
risque de crédit selon des axes d’analyse, afin de suivre l’activité de gestion de risque de
crédit. Ces indicateurs permettent de concevoir un DataMart Risque de crédit et des tableaux
de bord répondant aux besoins de notre client. En effet, la mise en œuvre du DataMart
nécessite la réalisation d’un processus ETL moyennant l’outil Oracle Data Integrator. Enfin,
le résultat visible de notre projet est l’élaboration des états de restitution, à l’aide de l’outil de
Reporting de Microsoft SSRS, pour le suivi de l’activité de gestion de risque de crédit.
Par ailleurs, durant ce projet, nous avons procédé à une bonne maîtrise fonctionnelle de
l’environnement de travail du client notamment lors des spécifications des besoins à travers
les consultants fonctionnels d’INTEGRYTIS. En outre, ce stage nous a permis également de
renforcer nos acquis en termes de formation à l’ENSIAS notamment ceux concernant la BI.
C’est aussi une occasion de maîtriser l’outil Oracle Data Integrator et Microsoft SSRS.
En perspective, après la validation de ce premier DataMart relatif au métier de risque de

crédit, nous envisageons d’atteler les autres DataMarts de la banque. Cet ensemble de
DataMarts permettra d’élaborer le nouveau référentiel de données de la banque. En effet,
notre client a confirmé la démarche proposée par INTEGRYTIS d’élaboration de son
DataWarehouse en intégrant l’ensemble des DataMarts réalisés pour chacune des équipes
métiers selon la démarche pensée par Ralph Kimball4.
4
La démarche pensée par Ralph Kimball consiste à la mise en place des DataMarts spécifiques à chaque
métiers et les intégrer par la suite.

Bibliographie et Webographie
Bibliographie
[M. et Conseil de la concurrence] MAZARS et Conseil de la concurrence, Réalisation d’une

étude sur la concurrentiabilité du secteur bancaire : Rapport de synthèse des volets I et II,
Mars 2013, 72p.
[H. Rachida] Hennani Rachida, De Bâle I à Bâle II : les principales avancées des accords
prudentiel pour un système financier plus résilient, Janvier 2005, 102p.
[V. Brunel] Vivien Brunel, Gestion des risques et risque de crédit, 28 janvier 2009, 58p.
[V. Rougès] Véronique Rougès, Gestion bancaire du risque de non-remboursement des

crédits aux entreprises : Une revue de la littérature, 2011, 19p.
[C. Gouriéreux et A. Tiomo] Christian Gouriéreux et André Tiomo, Risque de crédit : Une
approche avancée, 2007, 384p
[Oracle] Oracle Data Integrator: Administration and Development, Student guide, June 2007.
[Oracle] Oracle Data Integrator: Knowledge Modules Reference Guide, June 2009.
Webographie
[1] Stress Testing : usage et bon pratique, Disponible sur : http://www.iotafinance.com/

Article-Stress-Testing-Usage-et-bonnes-Pratiques.html
[2] Oracle, CRM : un outil uniquement pour les grands. Disponible sur: http://ubimen.fr/
dev/node/56, Oracle corporate, 2013
[3] Thibaut COSSAVELLA, Oracle Data Integrator, 2010, Disponible sur: http://fr.
slideshare.net/HichamLamriui/part1-odi-siad

Annexes
Annexes
Annexe A: Réglementation de Bâle

Annexe B: Oracle Data Integrator

Annexe A Réglementation de Bâle
Annexe A
Réglementation de Bâle

Réglementation de Bâle
Aux cours du comité de Bâle qui rassemble les plus grandes banques centrales. Les autorités
prudentielles ont décidé d’instaurer un ensemble de règles aux banques pour stabiliser le
système bancaire. Ces accords de Bâle visent à instaurer des normes internationales de
renforcement de chaque établissement financier afin d’éviter des crises de plus en plus
importante.
Les recommandations de Bâle sont revues régulièrement pour devenir peu à peu une
obligation harmonisée à l’ensemble des banques. De Bâle I à Bâle II, puis Bâle III les banques
doivent anticiper la feuille de route pour respect la règlementation prudentielle à temps.
1. Bâle 1
Le comité de Bâle est lancé en 1988 après une période de dérèglementation financière qui a
permis aux banques de constituer des conglomérats internationaux regroupant de nombreux
métiers tels que la banque de détail, la finance d’entreprise et particulièrement la finance de
marché. Face à cette croissante débordante des établissements financiers, les autorités
prudentielles ont souhaité encadrer la profession en instaurant des contraintes règlementaires
en fonds propres, on parle du ratio Cooke qui exige 8% de fonds propres par rapport aux
engagements de la banque.
2. Bâle 2
L’approche des risques évolue et le comité de Bâle introduit la notion de risque

opérationnel en 2007. Les banques doivent aussi organiser leur surveillance interne des
risques, cette mesure permet d’assurer le bon suivi des risques dans chaque établissement et
l’évaluation de la qualité de leurs actifs. Le ratio Cooke devient le ratio McDonough (toujours
8%), la mesure des fonds propres est alors plus fine notamment avec l’intégration du risque
opérationnel et la notion de fonds propres Tier One : les fonds propres durs.
Bâle II s’organise alors en trois piliers :
Pilier1 : il consiste en une exigence minimale en fonds propres rénovée. C’est le calcul du
ratio proprement dit. La logique reste la même, c’est-à-dire un rapport entre des fonds propres

et un encours de risques. L’appréciation de ces derniers est cependant modifiée par une
reconnaissance des techniques de réduction des risques et par la définition d’une charge en
fonds propre pour les risques opérationnels. Au total, toute banque doit avoir, au titre des
exigences minimales en fonds propres, un ratio égal ou supérieur à 8%.
Pilier2 : il règle le processus de contrôle de la gestion de risques et de la couverture en capital

par les autorités prudentielles nationales. Les autorités de contrôle examinent de façon
qualitative les procédures internes mises en place par les banques pour évaluer l’adéquation
des fonds propres aux risques en fonction de leurs appréciations, elles peuvent exiger un ratio
de solvabilité supérieur au minimum réglementaire 8%.
Pilier3 : Ce pilier renforce la discipline des marchés et établit des règles en matière
d’information publiée.
Pilier1 Pilier2 Pilier3

Exigences minimales de Surveillance par les autorités Transparence et discipline de
fonds propres prudentielles marché
- Risque de crédit Evaluation des risques et Obligation accrue de
- Risque de marché dotation en capital publication (sur la dotation
- Risque opérationnel spécifiques à chaque banque en fonds propres
et les méthodes d’évaluation des risques)
Tableau 8: Les trois piliers de l'accord Bâle 2
• Ratio des fonds propres :
Dans Bâle II, le ratio de solvabilité prend en compte d’autres catégories de risque que le
risque de crédit, à savoir le risque de marché et le risque opérationnel et s’exprime de la façon
suivante :
é
= ≥ 8%
é + ℎé + é
Où les éléments du dénominateur sont :
- Le risque de crédit : les actifs pondérés en fonction de leur risque ;

- Le risque de marché : le capital requis pour la couverture du risque de marché ;
- Le risque opérationnel : le capital requis pour la couverture du risque opérationnel.

Pour préserver la cohérence du calcul, les montants de fonds propres requis aux titres du
risque de marché et du risque opérationnel par 12.5, soit l’inverse de 8% avant de les
incorporer au calcul du ratio final.
- Les fonds propres réglementaires :
Les fonds propres réglementaires correspondent aux fonds propres que doivent détenir les
établissements financiers en lien avec l’exigence réglementaire définie par le Comité de Bâle.
Commençons par présenter le numérateur du ratio McDonough, c'est-à-dire les fonds propres
réglementaires. Le dispositif réglementaire intègre dans les fonds propre réglementaires les
éléments du bilan suivant :
Les fonds propre de base : Elles comprennent le capital social ou assimilé (actions,
certificats d’investissements, action à dividende prioritaire), le résultat non distribué
de l’exercice et les réserves consolidés, et déduisent les actions en fonds propre et la
partie non libérée du capital.
Les fonds propre complémentaires : Elles sont soit de premier niveau incluant des
titres hybrides, c’est-à-dire comportant des options, présentant certaines conditions,
durée indéterminée entre autres, soit de deuxième niveau incluant des dettes dont la
durée contractuelle initiale est supérieur à cinq ans.
3. Bâle 3
La réforme dite de « Bâle III », qui constitue la réponse du Comité de Bâle à la crise
financière, vise principalement à :
- Renforcer le niveau et la qualité des fonds propres (« tier one et core tier one ») ;
- Mettre en place un ratio de levier (« leverage ratio ») ;
- Améliorer la gestion du risque de liquidité par la création de deux ratios de liquidité
(ratio de liquidité à un mois « Liquidity coverage ratio » et ratio de liquidité à un an
« Net stable funding ratio ») ;
- Renforcer les exigences prudentielles concernant le risque de contrepartie.
Elle vient compléter une première série d’amendements à l’accord de Bâle II intervenus en
juillet 2009 relatifs au risque de marché visant à renforcer le suivi des activités de marché.

L’accord de Bâle III comprend un ensemble de mesures destinées à renforcer la résilience des
grandes banques internationales ainsi que des mesures spécifiques sur le risque de liquidités.
Une version révisée de l’Accord de Bâle III complétée sur le risque de contrepartie a été
publié le 1er juin 2011. Une version amendée du standard relatif à la liquidité à court terme
(LCR) a été publiée le 6 janvier 2013. Sa mise en œuvre sera progressive :
- Les premières mesures sont entrées en vigueur le 1er janvier 2013 ;

- L’ensemble des mesures devront être appliquées au 1er janvier 2019.

Annexe B Oracle Data Integrator
Annexe B
Oracle Data Integrator

Oracle Data Integrator

Oracle Data Integrator est un EL-T, il se différencie des autres ETL par son architecture et les
modules de connaissances qu’il propose que nous exposons dans ce qui suit.
1. Architecture ODI
Oracle Data Integrator possède une architecture spécifique que nous présentons dans les deux
figures suivantes :
Figure 50: Architecture générale d'ODI[3]
Une plate-forme ODI est organisée autour d’un référentiel central [figure 52] accédé en mode
client/serveur par des composants entièrement écrits en Java :
- Les modules d’interface graphique dédiés aux utilisateurs de la plate-forme ODI.

- Les agents d’exécution en charge de jouer les traitements implémentés.

Les référentiels ODI sont constitués d’un Référentiel Maître stockant et exposant toute la
typologie du système décisionnel (serveurs physiques, bases physiques et logiques, agents
ODI) et de plusieurs Référentiels de Travail stockant et exposant toutes les métadonnées des
projets d’alimentation ainsi que toutes les informations nécessaires à leur exploitation
(planification, ordonnancement et compte-rendu d’exécution). La figure suivante met en
avance la constitution des référentiels ODI.
Figure 51: Architecture détaillée d'ODI[3]
En effet, les référentiels (Maître & de travail) s'installent sur tout moteur de base de données
relationnel supportant la syntaxe ANSI ISO 89, tel qu’Oracle, Microsoft SQL Server, Sybase
AS Enterprise, IBM DB2 UDB, IBM DB2/400 etc. Les espaces de stockage préconisés pour
les référentiels ODI sont les suivants :
- Référentiel Maître : prévoir environ 1 Go d'espace de stockage.

- Référentiel de Travail : prévoir environ 5 Go d'espace de stockage par référentiel de
travail.

Notez que l'espace de stockage requis dépend de la taille des projets et modèles, et du volume
des journaux d'exécution qui doivent être conservés.
L’ODI comporte différents module de développement et d’administration :
ODI Designer: Création des flux

ODI Operator: Mise en production, planification, exploration et offre un
compte rendu d’exécution des flux
ODI Security: Gestion de la sécurité et des droits d’utilisateurs
ODI Topology : Description du système d’information
ODI Agent : Lien entre différents référentiels, exécution des interfaces et
traitements, mise à jour des journaux d’exécutions
2. Les modules de connaissances d’ODI
Les modules de connaissance sont des composants prédéfinis relatifs à certaines technologies
contenant des informations ODI qui servent pour un processus de génération pour cette
technologie, pour une fonction précise.
En effet, les modules de connaissances sont des commandes (systèmes, procédures, requêtes)
nécessaire à l’exécution d’une tâche d’intégration et permettant de capitaliser sur les
connaissances techniques et fonctionnelles.
Oracle Data Integrator offre cinq types de modules de connaissances (Knowledge Modules –
KM) : Reverse KM (RKM), Journal KM (JKM), Load KM (LKM), Check KM (CKM),
Integration KM (IKM).
- RKM : Reverse KM : permettent de faire des reverse engineering à partir d'une base
de données existante
- JKM : Journal KM : permettent de stocker et présenter les résultats d'exécution
- LKM : Load KM : permettent de charger les données à partir d'une ou plusieurs
tables sources
- CKM : Check KM : permettent de contrôler les données et vérifier l'intégrité
référentielle
- IKM : Integration KM : permettent d'intégrer les données dans la base cible

Le tableau ci-dessous présente les modules de connaissances relatifs aux fichiers, objets SQL,
et à la base de données Oracle Database que nous avons utilisés lors de la mise en œuvre du
projet.
Type Le module de Description

connaissance
Reverse KM RKM File (FROM EXCEL) Récupère les métadonnées des fichiers à
partir d'une feuille de calcul Microsoft
Excel. Ce KM est utilisé dans le cas de
maintenance de la définition de la
structure de fichiers dans un tableur Excel
séparé.
Check KM CKM SQL Vérifie l’intégrité des données définie
dans les contraintes des Datastores.
Rejette les enregistrements non valides

dans la table d'erreur créée
dynamiquement. Peut être utilisé pour les
contrôles statiques ainsi que des flux
contrôles.
Integration KM IKM SQL Control Append Intègre les données dans une table SQL
cible en mode ajouter ou remplacer.
Lorsque le flux de données doit être
vérifié en utilisant un CKM, cet IKM est
crée temporairement avant d'invoquer
l'CKM.
Integration KM IKM SQL Incremental Update Intègre les données dans une table cible
SQL suivant le mode de mise à jour
incrémental. Ceci crée une table
temporaire pour la mise en scène du flux
de données. Il compare ensuite son
contenu avec celui de la table cible afin
de deviner les éléments à insérer
directement et ceux à mettre à jour. Il

permet également d’effectuer le contrôle

d'intégrité des données en invoquant le
module CKM.
Integration KM IKM SQL to SQL Append Intègre les données dans une table cible
SQL à partir de n'importe quelle zone de
transit SQL en mode de remplacement.
Load KM LKM SQL to SQL Charge les données provenant d'une base
de données SQL compatible à une zone
de transit SQL. Ce LKM utilise l'agent
pour la lecture des données sélectionnées
à partir de la base de données source et
l’écriture du résultat dans la table
temporaire créée dynamiquement.
Integration KM IKM SQL to File Append Intègre les données dans un fichier cible
compatible à la zone de transit SQL e
mode remplacer.
Check KM CKM Oracle Vérifie contre l’intégrité des données à
travers les contraintes définies sur une
Table Oracle. Rejette les enregistrements
non valides dans la table d'erreur créée
dynamiquement. Peut être utilisé pour les
contrôles statiques ainsi que des contrôles
de flux de données.
Integration KM IKM Oracle Incremental Update Intègre les données dans une table cible
Oracle en mode mise à jour incrémental.
Cet IKM crée une table temporaire pour
la mise en scène du flux de données. Il
compare ensuite son contenu à la table
cible afin de deviner quels documents
doivent être insérés et mis à jour. Il
permet également d'effectuer l'intégrité
des données invoquant le CKM.
Tableau 9: Description des différents modules de connaissances utilisés dans la mise en
œuvre du projet [Oracle]

Asmae LOUTFI INTEGRYTIS

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Asmae LOUTFI INTEGRYTIS

Transféré par

Droits d'auteur :

Formats disponibles

Ecole Nationale Supérieure d’Informatique

et d’Analyse des Systèmes

Mémoire de Projet de Fin d’Études

Pour l’Obtention du Titre

D’Ingénieur d’État en Informatique

Conception et réalisation d’un DataMart Risque de

Soutenu par : Membre de jury : Sous la direction de :

Mme Naima ELHAOUD (Examinatrice) Mme Soumia BOUCHOUARI(Integrytis)

Mme Houda BENBRAHIM (Encadrante) Mme Asmae DOUMAL(Integrytis)

Année Universitaire 2014-2015

A mes sœurs : Kawtar et Ikhlass

A mes chers amis

A tous ceux qui m’aiment, je dédie ce travail.

Je tiens à exprimer ma gratitude à tout le corps professoral de l’Ecole Nationale Supérieure

Projet de Fin d’Etudes 4 2014-2015

Quant à l’environnement technologique du projet, nous avons profité des possibilités

Projet de Fin d’Etudes 5 2014-2015

Projet de Fin d’Etudes 6 2014-2015

CRM Customer Relationship Management

E-LT Extract, Load and Transform

ETL Extract Transform Load

IRB Internal Ratings Based Foundation

ODI Oracle Data Integrator

PME Petite Moyenne Entreprise

SAS DDS SAS®Detail Data Store

SGBDR Système de Gestion de Base de Données

TPE Très Petite Entreprise

Projet de Fin d’Etudes 7 2014-2015

Figure 1: Les cinq phases de l'approche INTEGRYTIS ....................................................................... 17

Projet de Fin d’Etudes 8 2014-2015

Projet de Fin d’Etudes 9 2014-2015

Tableau 1: Livrables du projet............................................................................................................... 23

Projet de Fin d’Etudes 10 2014-2015

Table des matières

Projet de Fin d’Etudes 11 2014-2015

3.2. Conception du DataMart ...................................................................................................... 38

Projet de Fin d’Etudes 12 2014-2015

Projet de Fin d’Etudes 13 2014-2015

Le premier chapitre aborde le contexte général du projet. Il présente la société INTEGRYTIS

Le troisième chapitre se focalise sur la conception. Il explicite les concepts de la modélisation

Projet de Fin d’Etudes 14 2014-2015

Contexte général du projet

Ce chapitre introductif a pour objet d’exposer le cadre général du projet en présentant

Projet de Fin d’Etudes 15 2014-2015

1. Contexte général du projet

1.1. Organisme d’accueil : Présentation d’INTEGRYTIS

INTEGRYTIS est une société de conseil et de service, spécialisée en business intelligence

INTEGRYTIS participe à l’amélioration des performances des entreprises en travaillant avec

1.1.1. L’approche INTEGRYTIS

Projet de Fin d’Etudes 16 2014-2015

Figure 1: Les cinq phases de l'approche INTEGRYTIS

a. Division Business Intelligence

Projet de Fin d’Etudes 17 2014-2015

1.2. Cadre général du projet

Projet de Fin d’Etudes 18 2014-2015

DG Banque des DG Information

Risques GROUPE Finances GROUPE

Figure 2: Organigramme du client d’Integrytis

1.2.2. Contexte du projet

Le portefeuille bancaire est particulièrement risqué puisque l’enregistrement des prêts

Projet de Fin d’Etudes 19 2014-2015

1.2.3. Objectifs du projet

En réponse à ce besoin, il s’avère nécessaire de concevoir un DataMart Risque de Crédit, qui