Elaboration d’une Solution Décisionnelle pour l’ATB

ses missions et son organisation. Par la suite, nous allons introduire le contexte du projet et faire

une étude de l’existant. Enfin, nous nous intéressons à la présentation de la solution proposée

et la justification du choix de la méthodologie adoptée.

2. Cadre du projet

Ce projet s’inscrit dans le cadre de la préparation d’un projet de fin d’études afin d’obtenir le

Diplôme de Licence Appliquée en Informatique Décisionnelle à l’Institut Supérieur de Gestion

(ISG). Ce projet dont la durée est de trois mois, est réalisé au sein de l’ATB (Arab Tunisian

Bank).

Son objectif principal est le développement d’une application intégrée dédiée à l’aide à la

décision.

3. Présentation de l’organisme d’accueil

3.1 Historique

En 1930, l’Arab Bank a été fondée dans le but de construire une institution au service du monde

arabe. Elle a démarré avec sept actionnaires et un capital qui ne dépassait pas les 15 000 livres

palestiniennes. 52 ans plus tard, Arab Bank a décidé d’intégrer l’agence de Tunisie et fondre

une banque commerciale tunisienne l’ATB.

L’ATB s’est donnée pour mission d’offrir des services diversifiés et de qualité aux particuliers

ainsi qu’aux professionnels et de contribuer au développement économique et financier du pays.

Elle est classée parmi les meilleures banques en termes de résultats, importance des fonds

propres et de ses actifs.

L'ATB dispose aujourd'hui d'un réseau de 131 agences et emploie plus de 1300 personnes. Cette

banque s’est investie dans le développement d’une stratégie de filialisation. On parle

aujourd’hui d’une création des sociétés spécialisées. En vue de consolider sa position sur le

marché Tunisien et d’accroître ses champs d’action, l’ATB s’intéresse particulièrement aux

axes suivants [1] :

• Une orientation plus soutenue vers le marché des particuliers sans toutefois

négliger sa cible privilégiée constituée des petites et moyennes entreprises, et les

grandes entreprises.

• Une synergie entre la banque et ses filiales.

3.2 Fiche d’identité de l’ATB

Comme tout établissement, l’ATB possède une fiche signalétique qui est décrite par la table 1

[2] :

Dénomination

Date de création

Fondateur

Siège social

Forme juridique

Activité

Direction

Nombre d’agences

Nombre d’employées

Nombre de filiales

Capitalisation

Bilan comptable

Téléphone

E-mail

Site web

L’Arab Tunisian Bank

30 juin 1982

Hatem Kchouk

9 Rue Hedi Nouira, 1001 Tunis

Société anonyme

Banque

Mohamed Ferid Ben Tanfous

131

1300

9

100 millions TND en 2015

2 696 000 USD en 2014

71351155

[email protected]

http://www.atb.tn/

Table 1. Fiche d'identité de l'ATB

3.3 Organigramme du siège

L’organisation de l’ATB est modélisée par l’organigramme présenté dans la figure 1 :

Directeur général

Direction centrale de financement

Dircetion centrale de l'inspection et de l'audit

Adjoint au directeur général

Direction des affaires juridiques

Direction central du département comptable

Direction des moyens de paiement

Direction des ressources humaines

Direction d'organisation

Direction de systèmes d'infomation

Division administration des systèmes

Division de coordination

Division de production

Division études et développement

Service maintenance hard

Service exploitation

Service maintenance application soft

Service maintenance application hard centrale

help desk

Figure 1. Organigramme du siège [3]

3.4 Direction du Stage

Notre stage d’étude se déroulera au sein de la direction des systèmes d’information, plus

précisément dans la division administration des systèmes en collaboration avec la direction des

Etudes et des projets. Nous allons expliquer dans ce qui suit, les activités de chacune de ces

directions.

3.4.1

Présentation de la DCSI

La direction centrale des systèmes d’information de l’ATB (DCSI) est composée

principalement de trois départements :

✓ Le département infrastructure et systèmes qui est subdivisé en :

• Unité réseau de communication

• Cellule d’administration systèmes et base de données

• Unité de gestion de matériel informatique

✓ Le département exploitation et maintenance constitué de :

• La division assistance utilisateur

• La cellule de sauvegarde et restauration

• La division exploitation

✓ Le département application et maintenance qui est composé de :

• La cellule core system

• L’unité des canaux de distribution électronique

• La division développement et maintenance système

•

Nous nous intéressons, non seulement à la cellule d’administration systèmes et base de données

qui fait partie du département infrastructure et systèmes, mais aussi à la direction des études et

des projets qui pilote tous les projets de la banque.

3.4.2 Présentation de la direction des études et des projets

La Direction des études et des projets a pour mission la planification stratégique et

opérationnelle des actions de développement de la banque.

A ce titre, elle est chargée notamment :

• De réaliser des études nécessaires à l’atteinte des objectifs de la banque.

• D’assurer le pilotage de plusieurs projets en termes de coût, délai, qualité et risque.

• D’assurer le suivi et l’évaluation de la performance des projets.

• De coordonner l’élaboration des plans et des stratégies

• De produire les rapports d’activité

4. Présentation du projet

4.1 Contexte du projet

Ce projet consiste à élaborer une solution décisionnelle pour l’analyse des engagements, des

produits et des garanties de la banque tout en se référant de la classification et le calcul de risque

des clients afin de faciliter la prise de décision.

La banque dispose des sources de données regroupant des informations sur les clients créanciers

telles que :

Les engagements : Le client peut être lié à différents types d’engagements envers

la banque. Principalement, on peut citer :

• Les crédits à moyen terme

• Les crédits à long terme

• Les engagements par signature

• L’aval

Les produits : Le client s’engage à fournir les produits bancaires tels que les

différents types de commissions, d’intérêt et les agios…

Les garanties : La banque exige une garantie bancaire qui permet d’assurer un

remboursement dans le cas où le client n'arriverait pas à honorer le contrat.

Les classes : La classification des clients peut être considérée comme une étape

essentielle à la prise de décision et se fait selon :

- Le gel des comptes bancaires

- La consolidation des crédits

- La classification des impayés

Chaque classe peut avoir une valeur entre 0 et 5. Plus la note est proche de 5 plus le client est

mal classé.

4.2 Analyse de l’existant

Les données de l’ATB sont généralement sauvegardées dans un système Oracle, mais il existe

aussi une grande partie qui a été migrée vers un nouveau système intitulé « Equation »

spécifique à l’Arabe banque. La migration totale des données est encore inachevée donc une

partie des données concernant les engagements clients réside toujours dans l’ancien système.

Pour suivre les engagements, les produits et les garanties, la solution utilisée actuellement est

une application .NET classique qui permet la consultation et l’exportation des données sous

forme Excel et peut être considérée comme étant basique et traditionnelle. Elle est définie sur

une base de données Oracle 11g en utilisant des liens de bases de données DBLINK permettant

l’accès à distance (oracle 11g, AS 400).

4.3 Critique de l’existant

La solution utilisée traite chaque module à part. D’ailleurs les informations concernant les

engagements, les clients, les produits et les garanties se trouvent dans différentes bases de

données.

Cette solution était adéquate et répondait aux besoins des décideurs pour le suivi des

engagements clients, la consultation et le calcul. Cependant, depuis quelques années, la banque

a noté une augmentation considérable du nombre de clientèle, d’où une élévation du volume

des données à traiter et l’enrichissement du système d’information de la banque. Ceci a mené

alors, à l’inefficacité de cette solution face à ces changements, on parle d’ :

- un mauvais partage de l’information

- un manque de souplesse

- un temps de traitement très lent qui peut durer jusqu’à 4 jours en considérant le volume

important des données à analyser.

Les bases de données relationnelles utilisées dans cette solution sont définies comme étant un

répertoire d'éléments de données dotés d'une relation prédéfinie entre eux. Ce répertoire peut

contenir des informations erronées et manquantes, et ne répondent pas aux attentes des

décideurs qui ont besoin d’informations pertinentes et fiables sur lesquelles ils peuvent

s’appuyer pour une prise de décision avisée. Il est indispensable alors d’opter pour une structure

de données mieux adaptée afin de faciliter l’analyse des données pour des fins décisionnelles.

Les décideurs sont confrontés à des problèmes qui résident dans :

- La complexité de la structure de la base à cause de nombre assez important des tables

et des jointures mises en œuvre.

- La difficulté d’accès à distance aux informations.

- La difficulté de la représentation des données historiques

- La gêne de l’exploitation optimale des données et la classification selon un thème

bien déterminé.

4.4 Description de la solution

Après avoir étudié le processus de la prise de décision de l’ATB, il s’est avéré qu’il est

nécessaire de mettre en place un système décisionnel qui va permettre de :

- Homogénéiser les ressources de données hétérogènes.

- Suivre les engagements clients via une interface utilisateur en visualisant

principalement les impayés et les crédits.

- Consulter les produits de la banque (les intérêts et les commissions).

- Consulter les garanties.

- Classifier les clients et calculer les risques d’insolvabilité (classification des actifs,

les agios, les provisions).

- Analyser les données et générer des rapports selon le besoin du décideur.

- Diffuser les informations nécessaires à tous les acteurs décisionnels.

- Faciliter l’analyse et la prise de décision au niveau des hauts et moyens secteurs de

la banque.

C’est pour cette raison que nous avons opté pour une solution décisionnelle ayant pour but de

collecter et récupérer les données de différentes sources disponibles, les traiter et les charger

dans un entrepôt de données puis fournir une interface web dynamique qui permettra aux

décideurs de suivre les engagements, les produits et les garanties bancaires, de consulter la

classification des clients tout en se référant du risque calculé, et enfin avoir l’accès aux

différents tableaux de bord et des rapports interactifs pour des fins décisionnelles.

5. Conclusion

A travers ce chapitre, nous avons pu acquérir une connaissance assez importante concernant

l’activité de l’ATB, en faisant l’étude de l’existant et en soulignant ses limites. Ensuite, nous

avons proposé une solution qui répond aux besoins de la banque. Quant au chapitre qui suit,

nous allons énumérer les différentes méthodes de conception qui existent pour enfin, adopter

une et Idem pour les outils informatiques décisionnels.

Chapitre II : Méthodes de conception et outils décisionnels

1. Introduction

Afin d’assurer une bonne gestion du projet, une étude comparative des méthodes de conception

s’impose à ce stade. De même pour le choix des outils informatiques que nous allons utiliser et

les approches que nous allons adopter. Ce chapitre sera alors, dédié à la justification de nos

choix en faisant recours à une comparaison bien détaillée.

2. Méthode de conception

2.1 Etudes des méthodes prédictives classiques

Les méthodes de développement utilisés jusqu’à 1990 comme « Cycle en V », « Cleanroom »,

« Waterfall » et « la Spiral de Boehm » n’assuraient plus la bonne maîtrise et la gestion des

coûts, budgets, et des délais d’un projet dont le périmètre fonctionnel est assez développé.

Les études du Standish Group ont démontré à travers le « Chaos Report » [4] que le taux de

réussite des projets élaborés avec Waterfall, par exemple, n’a pas dépassé 32% en 2009, et

beaucoup moins en 2012 avec un taux de 14%. Alors qu’on considère qu’un projet réussi, s’il

arrive à respecter le périmètre fonctionnel, le budget et les délais prévus préalablement. C’est

pourquoi les recherches se sont orientées vers l’exploration de nouvelles approches à adopter

notamment les méthodes agiles.

Successful

Challenged

Failed

Figure 2. « The Chaos Manifesto »

2.2 Méthodes AGILES

« Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit

collaboratif avec juste ce qu’il faut de formalisme. Elle génère un produit de haute qualité tout

en prenant en compte l’évolution des besoins des clients. » [5]

Cette approche forme un ensemble de méthodes permettant en effet de gérer essentiellement

les projets informatiques.

Elles se basent sur des cycles de développement adaptifs en fonction des besoins fonctionnels

du projet. En outre, l’implication des collaborateurs dans le développement du projet est

assurée.

Ces méthodes répondent aux attentes du client en un temps réduit et impliquent les

collaborateurs en compétences.

Les méthodes de développement Agile peuvent être énumérées comme suit :

• Scrum

• Adaptive Software Development (ASD)

• Extreme Programming

• Dynamic System Development Method (DSDM)

• XP

• Kanban

Etc...

La figure 3 illustre la répartition de différentes méthodologies Agiles adoptées en 2016 [6].

Scrum occupe la plus grande partie. D’ailleurs il est généralement adopté pour son paradigme

innovateur de conduite de projet ainsi que ses pratiques d’ingénierie logicielle.

Figure 3. Répartition des Méthodologies agiles adoptées en 2016

2.3 Méthodes AGILES Vs Méthodes prédictives classiques

Après avoir étudié chaque méthode, nous proposons ce tableau comparatif qui récapitule les

principales différences entre les deux méthodes. [7]

Axe de comparaison Méthodes AGILES

Méthodes classiques

Planification

Cycle de vie

Adaptive

Prédictive

Itératif et incrémental

En cascade ou en V

Documentation

Très réduite au strict nécessaire au

Livrée en quantité

profit des fonctionnalités

importante sous forme d’un

opérationnelles afin de recevoir les

Support de communication

feedbacks des clients.

et de validation.

Equipe

Une équipe soutenue par un chef

Une équipe composée de

de projet où la communication et

ressources spécialisées

l’initiative sont les piliers du

dirigée par un chef de projet.

travail.

Livraison de la

Généralement rapide et

Généralement tardive.

solution

incrémentale.

Intervention du client Très fréquente lors de la mise en

Pratiquement inexistante, le

œuvre de la solution avec

client évalue le produit vers

proposition de changement si

la fin du projet.

souhaité.

Mesure de succès

Respect des engagements initiaux

Satisfaction du client

en termes de délais, budgets, coûts

et qualité.

Table 2. Méthodes AGILES Vs méthodes classiques

2.4 Méthodologie adoptée

Après cette étude comparative, nous avons décidé d’adopter la méthode Agile pour réaliser

notre projet. Cette méthode est parfaitement cohérente avec les concepts de base du cycle de

vie d’un Datawarehouse, un concept publié par le Ralph Kimball, qui se résume en trois points

[8] :

• Ajouter une valeur métier à l’entreprise.

• Stocker les données dans des dimensions.

• Concevoir une solution d’aspect itérative.

Les méthodes agiles sont de nature itérative et participative, on commence par développer des

petits morceaux d’application qui apportent de la valeur ajoutée, qu’on valide par le client puis

on passe aux suivants. C’est le client qui pilote au fur et à mesure le développement de la

solution à travers le choix des fonctionnalités qu’il souhaite voir développer.

La nature de ce processus est la clé de notre décision. Appliquer l’agilité sur un projet

décisionnel permettra d’impliquer d’avantage l’utilisateur et d’assurer la valeur métier pour

l’organisation.

Après avoir fixé une méthode à suivre pour la réalisation du projet, il est temps de choisir une

des méthodes de développement Agile parmi celles citées précédemment.

2.5 Présentation de la méthodologie SCRUM

La méthodologie SCRUM est inspirée des valeurs et de l’esprit du jeu Rugby. Cette approche

est issue des travaux des signataires du Manifeste Agile : Sutherland et Schwaben, et fait partie

de la famille des méthodologies incrémentales et itératives.

Cette méthodologie est définie dans un milieu de travail assurant la réalisation des projets

considérés complexes. Cette méthode est apte principalement pour la mise à exécution des

projets software néanmoins, elle peut être également appliquée à tout autre type de projet, du

plus simple au plus innovant.

En utilisant les méthodologies classiques et unifiées, le client ne pouvait ni suivre l’évolution

du travail ni être impliqué dans l’exécution de son projet

En effet, en Scrum, le client est plus impliqué dans le suivi de l’avancement du projet et

l’approbation de plusieurs livrables. Il peut donc suivre régulièrement l’évolution des travaux

dans le cas d’une demande de modification d’un élément ou d’insatisfaction ça sera plus facile

de le modifier pour satisfaire ses besoins.

La méthodologie SCRUM assure l’optimisation de la prévisibilité d’un projet et le contrôle des

risques. [9]

2.6 Les intervenants dans Scrum

En comparant un projet séquentiel avec un projet agile, on note une différence aux niveaux des

missions et des responsabilités des intervenants car une importance particulière est accordée

sur l’appropriation de tous les éléments sprint du projet par les membres de l’équipe.

La méthodologie Scrum définit trois rôles [10] :

• Le Porduct Owner (PO)

C’est le porte-parole des clients chargé de définir soigneusement le backlog qui permet de

recueillir les besoins du client, les spécifications du produit ainsi que toutes les fonctionnalités

du projet à réaliser. Le propriétaire du produit est également responsable de classer les éléments

du backlog par priorité et indiquer l’ordre de leur réalisation.

• Le Scrum Master

C’est la personne qui joue le rôle d’un animateur de l’équipe. Il n’est pas considéré comme un

chef de projet ou un donneur d’ordres mais plutôt comme un coordinateur facilitateur qui assure

le bon déroulement du projet et veille à résoudre les problèmes et les obstacles qui empêchent

l’avancement du travail de son équipe.

• Le Scrum Team

C’est l’équipe de développement qui est responsable de délivrer les éléments de chaque sprint

selon leurs ordres de priorités. Le groupe est constitué d’architectes, développeurs

administrateur base de données etc.

2.7 Les artéfacts du Scrum [11]

• Product Backlog :

Le carnet des produits est défini comme étant une liste ordonnée contenant les exigences et les

besoins du client et toutes les spécifications relatives au produit. Le Porduct Owner est chargé

du Product Backlog en termes de contenu, disponibilité et ordonnancement.

• Sprint Backlog :

Le sprint Backlog est un élément indispensable pour la compréhension de la progression du

travail de l’équipe de développement. Chaque sprint doit répondre aux attentes du Product

Owner et assure l’atteinte des objectifs préalablement définis au début du Sprint. Il s’agit d’un

plan bien détaillé de taches effectuées

• Sprint Burn-Down Chart :

Le graphique d'avancement est une représentation qui donne une vue globale sur l'évolution de

quantité de travail restante par rapport au travail engagé. Sur l’axe vertical se situe le travail

restant. L’axe horizontal présente le temps. Ce type de graphique permet de prévoir l’état

d’avancement du travail pendant un laps de temps afin de suivre le déroulement de l’activité.

Figure 4. Vue globale du Scrum [12]

2.8 L’approche SCRUM appliqué à un projet BI

Le projet décisionnel est un projet de type particulier. Il est non seulement complexe, mais aussi

il doit aussi répondre parfaitement aux besoins évolutifs des utilisateurs engagés de prendre des

décisions cruciales dans un univers instable et changeant. Cela n’est autre que la finalité de

Business Intelligence. D’ailleurs, toute décision est obligatoirement une prise de risque,

d’autant plus critique à calculer dans un environnement incertain. De ce fait, il est indispensable

d’intégrer et inclure au plus les utilisateurs lors de développement de la solution. Pour cette

raison, la solution SCRUM agile est appelée lors de l’élaboration d’un projet BI. Elle propose

en effet, plusieurs approches à appliquer sur ce type de projet [13], Nous citons : [14]

• L’approche de Kimball « Bottom-Up »

Dans cette approche, Le Data Warehouse est considéré comme étant l’union des datamarts

cohérents entre eux. Le Datawarehouse physique n’existe pas.

• L’approche d’Inmon « Top-Down »

Dans cette approche, le Data Warehouse est un référentiel centralisé stockant les données

relatives à l’entreprise au niveau le plus détaillé. Par la suite, des Datamarts sont modélisés et crées à partir de ce Data Warehouse.

Quant à notre solution, nous avons adopté l’approche de conception « top-down » permettant

de mettre en place un référentiel centralisé, le DW, puis charger de manière cohérente les

datamarts. Cette approche est simple et résistante lors de chargements des dimensions, ainsi

que lors de créations des magasins de données. En outre, elle est insensible et flexible aux

besoins des clients qui évoluent au cours des phases de mise en œuvre.

3. Approche de conception de l’entrepôt de données

3.1 Modèles conceptuels

Dans cette section, nous allons choisir un schéma de modélisation de notre Datawarehouse.

Commençons tout d’abord par définir les deux modèles qu’ils existent [15] :

• Un schéma en étoile (Star Schema) est une structure dimensionnelle qui représente, au

centre, une seule table de faits dont les colonnes sont les mesures. La table de faits est

entourée par cercle de dimensions présentant les axes d’analyse. Toute dimension à

niveaux multiples est aplatie en une seule dimension. Le schéma en étoile est conçu

pour répondre à des requêtes inhérentes à la structure dimension-fait.

• Le principe du schéma en flocon de neige est qu’ils peuvent exister des hiérarchies de

dimensions, contrairement au schéma en étoile.

Pour notre solution, nous avons opté pour le modèle en flocon de neige qui permet de formaliser

une hiérarchie de dimensions, ce qui facilite l’analyse et réduit le volume des données.

3.2 Approches pour la création du Datawarehouse (ROLAP, MOLAP,

HOLAP)

Il existe 3 possibilités pour créer un DW [16] :

• Relationnel OLAP (ROLAP) : Les données sont stockées dans un SGBD relationnel et

un moteur OLAP permet de stimuler le comportement du SGBD.

• Multidimensionnel OLAP (MOLAP) : Les données sont stockées dans un Cube qui

n’est autre qu’une base de données multidimensionnelle qui permet la restitution des

données de façon instantanée.

• Hybride OLAP (HOLAP) : L’HOLAP est un mélange du ROLAP et du MOLAP, les

cubes HOLAP sont donc Hybrides.

Pour notre solution, nous avons opté pour HOLAP. L’idée consiste à avoir la possibilité

d’accéder aux données agrégées à travers MOLAP, ou accéder aux détails si souhaités à travers

ROLAP. Cela pourra nous aider lors de la phase de restitution. Nous pourrons avoir un rapport

dont les données sont issues d’une base multidimensionnelle, ainsi qu’un autre beaucoup plus

détaillé dont les données sont issues, cette fois-ci, d’une table relationnelle. [17]

4. Comparaison des outils décisionnels

Nous allons présenter dans ce qui suit, une étude comparative des différents outils BI les plus

utilisés. Nous avons divisé ces outils en 3 catégories :

• Les outils pour la création du DataWarehouse.

• Les outils pour assurer l’ETL.

• Les outils de Reporting.

4.1 Outils pour la création de DataWarehouse

✓ PostgreSQL

PostgreSQL est un SGBDR (système de gestion de base de données relationnelle) Open Source.

Il est issu des recherches du professeur Stonebraker de l’université de Californie qui remontent

à 1986. Réputé pour sa puissance et sa robustesse, il possède des diverses fonctionnalités riches

et avancées permettant de manipuler une grande masse de données et supporter une douzaine

de langages de programmation, dont Python, Java, C, C++ ainsi que son