Ministère de l’Enseignement Supérieur

Et de la Recherche Scientifique
Université de Tunis
Institut Supérieur de Gestion

RAPPORT DE STAGE DE FIN D’ÉTUDES

Pour l’obtention du diplôme de

La Licence Appliquée en Informatique Décisionnelle

ELABORATION D’UNE SOLUTION DECISIONNELLE

POUR L’ATB

Entreprise d’accueil :
Arab Tunisian Bank (ATB)

Elaboré par
Kdous Mohamed Amine & Sammouda Chirine

Encadrant pédagogique Encadrant professionnel

Mme. Rejeb Lilia Mr. Sahraoui Aymen

Année universitaire
2017 – 2018
 Remerciements
Dans un premier temps, nous tenons à remercier Dieu le tout puissant, qui nous a donné la
force et la patience d’accomplir ce modeste travail.

C’est avec une grande gratitude et respect que nous tenons à exprimer nos sincères
remerciements à notre encadrante académique Madame Lilia REJEB pour ses précieux
conseils, sa qualité d’encadrement ainsi que le savoir qu’elle nous a transmis.

Nous adressons, par la même occasion nos vifs remerciements et nos profondes
reconnaissances à l’égard de Monsieur Aymen SAHRAOUI, notre encadrant professionnel
pour nous avoir encadré et orienté durant notre projet de fin d'études ainsi que pour ses
remarques judicieuses, sa sympathie et son amitié.

Nos remerciements s’étendent également à tout le personnel de l’ATB pour leur chaleureux
accueil.

Nous ne manquerons pas l’occasion de remercier tous nos enseignants à l’institut supérieur
de Gestion pour le temps qu’ils nous ont consacré afin d’assurer une formation de qualité
durant ces années d’étude, ainsi que les membres du jury présents pour avoir accepté de
juger ce modeste travail.
 Dédicace
Je dédie ce modeste travail

À mon père Imed et ma mère Fadoua

Aucune dédicace ne saurait exprimer ma considération pour les sacrifices que vous avez
consenti pour mon instruction et mon bien être. Que cet humble travail puisse vous rendre
fiers de moi.

À mon frère Khalil et ma sœur Maissa.

Je vous remercie pour tout le soutien et l’amour que vous me portez depuis mon enfance et
j’espère que votre bénédiction m’accompagne toujours.

À mes grands-parents.
Je vous remercie pour tout le soutien et l’amour que vous me portez depuis mon enfance et
j’espère que votre bénédiction m’accompagne toujours.

À toute ma famille, et mes amis,

Qui m’ont toujours aidé et encouragé, qui étaient toujours à mes côtés, et qui m’ont
accompagné durant mon chemin d’études supérieures.

À mon cher binôme Chirine,

Chez qui j’ai trouvé le soutien et l’entente dont j’avais besoin. Merci pour les moments de
réussite et de joie partagés durant ces trois années d’amitié sincère et qui témoigne de ma
plus profonde reconnaissance.

Kdous Mohamed Amine

 Dédicace

À ma très chère mère Dorra

Aimable, affable et honorable : Tu es la source de tendresse, le symbole de la bonté et

l’exemple du dévouement qui n’a jamais cessé de m’encourager et de prier pour moi.

À mon très cher père Taoufik

Rien au monde ne vaut les efforts fournis jour et nuit pour mon éducation et mon bien être. Je
te dédie ce travail en témoignage de mon profond amour. Puisse Dieu, le tout puissant, te
préserver et t’accorder santé, longue vie et bonheur.

Je vous dois ce que je suis aujourd’hui et ce que je serai demain et je ferai toujours de mon

mieux pour rester votre fierté et ne jamais vous décevoir.

À ma très chère sœur Chayma

Les mots ne suffisent guère pour exprimer l’attachement, l’amour et l’affection que je porte

pour toi. Je te souhaite un avenir plein de joie, de bonheur, de réussite et de sérénité.

À tous les membres de ma famille, petits et grands

Veuillez trouver dans ce modeste travail l’expression de mon affection.

À mon très cher binôme Amine

Sans Ton soutien moral, ta gentillesse sans égal et tes encouragements ce travail n'aurait vu

le jour. Que ce travail soit témoignage de ma reconnaissance et de mon amitié sincère et

fidèle.

À tous mes chers amis

En témoignage de l’amitié et les souvenirs qui nous unissent.

Sammouda Chirine
 Table des matières

Chapitre I : Contexte général..................................................................................................... 1

1. Introduction ......................................................................................................................... 1

2. Cadre du projet .................................................................................................................... 1

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

3.1 Historique .................................................................................................................... 1

3.2 Fiche d’identité de l’ATB ............................................................................................ 2

3.3 Organigramme du siège ............................................................................................... 3

3.4 Présentation de la DCSI ............................................................................................... 4

3.5 Présentation de la direction des études et des projets .................................................. 4

4. Analyse de l’existant ........................................................................................................... 5

4.1 Etude de l’existant ....................................................................................................... 5

4.2 Critique de l’existant ................................................................................................... 6

4.3 Description de la solution ............................................................................................ 7

5. Conclusion .......................................................................................................................... 8

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

1. Introduction ....................................................................................................................... 10

2. Méthodes de conception ................................................................................................... 10

2.1 Etude des méthodes prédictives classiques ............................................................... 10

2.2 Méthodes AGILES .................................................................................................... 11

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

2.4 Méthode adoptée........................................................................................................ 12

2.4.1 Présentation de la méthode SCRUM .................................................................. 13

2.4.2 Les intervenants dans Scrum .............................................................................. 13

 2.4.3 Les artéfacts du Scrum [11]................................................................................ 14

2.4.4 L’approche SCRUM appliqué à un projet BI..................................................... 15

3. Modèle conceptuel ............................................................................................................ 16

4. Approches pour la création du Datawarehouse (ROLAP, MOLAP, HOLAP) ................ 17

5. Comparaison des outils décisionnels ................................................................................ 17

5.1 Outils pour la création de DataWarehouse ................................................................ 17

5.2 Outils pour Extract Transform Load (ETL) .............................................................. 19

5.3 Outils de Reporting .................................................................................................... 21

6. Environnement de développement retenu ......................................................................... 23

6.1 Outils de conception .............................................................................................. 23

6.2 Outils de développement ........................................................................................ 23

7. Conclusion ........................................................................................................................ 24

Chapitre III : Phase de préparation ......................................................................................... 25

1. Introduction ....................................................................................................................... 25

2. Analyse des besoins .......................................................................................................... 25

2.1 Identification des acteurs du système ........................................................................ 25

2.2 Spécification des besoins fonctionnels ...................................................................... 26

2.3 Spécification des besoins non fonctionnels ............................................................... 26

3. Backlog produit ................................................................................................................. 27

4. Planification du projet ....................................................................................................... 28

4.1 Pilotage du projet avec la méthodologie SCRUM..................................................... 28

4.2 Découpage de la solution en Sprints.......................................................................... 29

4.3 Diagramme de Gantt .................................................................................................. 30

5. Etude des données sources ................................................................................................ 30

6. Conception de la base de données .................................................................................... 31

7. Alimentation de la base de données .................................................................................. 32

8. Conclusion ........................................................................................................................ 34
Chapitre IV :............................................................................................................................. 35

Sprint 1 : Mise en place d’un Data Warehouse des Suivis ...................................................... 35

1. Introduction ....................................................................................................................... 35

2. Sprint Backlog .................................................................................................................. 35

3. Conception du DataWarehouse ......................................................................................... 36

3.1 Choix des mesures ..................................................................................................... 36

3.2 Choix des dimensions ................................................................................................ 37

3.3 Table de faits ............................................................................................................. 37

4. Modélisation du DataWarehouse ...................................................................................... 38

5. Intégration des données du DataWarehouse « Suivi » (ETL) ........................................... 39

5.1 Extraction des données ................................................................................................... 40

5.2 Transformation des données ........................................................................................... 42

5.3 Chargement des données ................................................................................................ 47

6. La restitution des données ................................................................................................. 49

7. Conclusion ........................................................................................................................ 59

Chapitre V : .............................................................................................................................. 60

Sprint 2 : Suivi et évaluation de la classification des actifs et des risques clients. .................. 60

1. Introduction ....................................................................................................................... 60

2. Sprint Backlog .................................................................................................................. 60

3. La classification des Actifs ............................................................................................... 61

3.1 Actifs courants (Classe 0) .......................................................................................... 61

3.2 Actifs nécessitant un suivi particulier (Classe 1) ....................................................... 61

3.3 Actifs incertains (Classe 2) ........................................................................................ 62

3.4 Actifs préoccupants (Classe 3) .................................................................................. 62

3.5 Actifs compromis (Classe 4) ..................................................................................... 62

4. Formules pour le calcul des risques .................................................................................. 63

4.1 Formule de calcul du « STRATE » ........................................................................... 63

 4.2 Formule de calcul de la Variation des engagements ................................................. 64

4.3 Formule de calcul de la Garantie plafonnée à l’engagement ..................................... 64

5. Conception du Datamart « Risque » ................................................................................. 64

5.1 Choix des mesures ..................................................................................................... 64

5.2 Choix des dimensions ................................................................................................ 65

5.3 Modélisation du Datamart ......................................................................................... 65

6. Intégration des données du Datamart « RISQUE » (ETL) ............................................... 66

6.1 Extraction des données .............................................................................................. 66

6.2 Transformation des données ...................................................................................... 67

6.3 Chargement des données ........................................................................................... 70

7. La restitution des données ................................................................................................. 70

8. Conclusion ........................................................................................................................ 71

Chapitre VI :............................................................................................................................. 72

Sprint 3 : Gestion des Rapports et des Tableaux de bord ........................................................ 72

1. Introduction ....................................................................................................................... 72

2. Sprint Backlog .................................................................................................................. 72

3. Conception ........................................................................................................................ 73

3.1 Diagramme de cas d’utilisation ................................................................................. 74

3.2 Diagramme de séquence de l’authentification du décideur ....................................... 75

3.3 Diagramme de séquence de la consultation d’un Rapport......................................... 76

3.4 Diagramme de séquence de la consultation d’un Tableau de bord ........................... 77

3.5 Diagramme de séquence de la mise à jour des Garanties .......................................... 78

3.6 Diagramme de navigation web .................................................................................. 79

4. Environnement de travail .................................................................................................. 80

4.1 Architecture physique ................................................................................................ 80

4.2 Environnement de Développement ........................................................................... 81

4.3 Technologies .............................................................................................................. 81

 4.4 Réalisation ................................................................................................................. 82

5. Conclusion ........................................................................................................................ 84

Conclusion Générale ................................................................................................................ 85

Annexe A : Le Projet Décisionnel ............................................................................................ 87

Annexe B : Dictionnaire des données sources ......................................................................... 92

Webographie et Bibliographie ................................................................................................. 97

 Table des figures

Figure 1. Organigramme du siège [3] ........................................................................................ 3

Figure 2. Démarche cycle en V [5] .......................................................................................... 11
Figure 3. Déroulement d'un projet Scrum [12] ........................................................................ 15
Figure 4. Equipe Scrum ........................................................................................................... 29
Figure 5. Répartition des Sprints .............................................................................................. 29
Figure 6. Modélisation de la base de données .......................................................................... 32
Figure 7. Les Packages de chargement de la base de données ................................................. 33
Figure 8. Chargement de la table Produit ................................................................................. 33
Figure 9. Conversion des données de la table Produit ............................................................. 34
Figure 10. Modèle en étoile du DataWarehouse « Suivi »....................................................... 38
Figure 11. Création d'un nouveau projet SSIS ......................................................................... 39
Figure 12. Composition d'un Package SSIS simple [32] ......................................................... 40
Figure 13. Package pour l'extraction des données à partir de la base « ATBTEST_DB » ...... 41
Figure 14. Tâche d'exécution de la requête SQL « Delete » .................................................... 41
Figure 15. Transformation appliquée à la Dimension Activité ................................................ 42
Figure 16. Transformation appliquée à la dimension Agence.................................................. 43
Figure 17. Tri des données à charger dans la table de faits ...................................................... 44
Figure 18. Transformations aboutissant à la table de faits ....................................................... 45
Figure 19. Tâche de transformation "Colonne dérivée" appliquée à la table de faits .............. 46
Figure 20. Choix de Destination de Chargement de données .................................................. 47
Figure 21. Chargement des Dimensions .................................................................................. 48
Figure 22. Chargement de la table de faits ............................................................................... 48
Figure 23. Interface de SQL Server Reporting Services .......................................................... 49
Figure 24.Configuration de l'URL du service web .................................................................. 50
Figure 25. Configuration de l'URL du portail web .................................................................. 50
Figure 26. Configuration de la base de données ...................................................................... 51
Figure 27. Création d'une nouvelle Source de données ........................................................... 51
Figure 28. Chaîne de connexion avec le DataWarehouse « ATBTEST_DW » ....................... 52
Figure 29. Chaîne de connexion avec la base de données « ATBTEST_DB » ....................... 52
Figure 30. Création d'un nouveau Jeu de données ................................................................... 53
Figure 31. Choix de source de données dans Report Builder .................................................. 53
Figure 32. Jeu de données dans le Report Builder (requête 1) ................................................. 54
Figure 33. Jeu de données dans le Report Builder (requête 2) ................................................. 55
Figure 34. Création d'un nouveau Rapport mobile .................................................................. 55
Figure 35. Choix d'une grille de données pour le Rapport ....................................................... 56
Figure 36. Ajout des données du DataSet ................................................................................ 56
Figure 37. Paramétrage du Rapport.......................................................................................... 57
Figure 38. Exemple du Rapport généré .................................................................................... 57
Figure 39. Choix du type de graphique à produire ................................................................... 58
Figure 40. Dashboard « Engagement » .................................................................................... 58
Figure 41. Modèle en étoile du Datamart « Risque »............................................................... 65
Figure 42. Exécution de Package d'extraction ......................................................................... 66
Figure 43. Le tri des données avec Sort Transformation Editor .............................................. 67
Figure 44. Transformations aboutissant à la table de faits « Fact_Risque » ............................ 67
Figure 45. Paramétrage des Transformations de la table de faits « Fact_Risque » et des Inputs
et Outputs ................................................................................................................................. 68
Figure 46. Bouton aboutissant à la modification du Script C sharp ......................................... 69
Figure 47. Script du code C sharp de la formule « STRATE »................................................ 69
Figure 48. Chargement du Datamart Risque ............................................................................ 70
Figure 49. Diagramme de cas d'utilisation global .................................................................... 74
Figure 50. Diagramme de séquence de l’authentification du décideur .................................... 75
Figure 51. Diagramme de séquence de la consultation d’un Rapport ...................................... 76
Figure 52. Diagramme de séquence de la consultation d’un Tableau de bord ......................... 77
Figure 53. Diagramme de séquence de la mise à jour des Garanties ....................................... 78
Figure 54. Diagramme de navigation web ............................................................................... 79
Figure 55. Architecture 3-tiers ................................................................................................. 80
Figure 56. Page d’accueil ......................................................................................................... 82
Figure 57. Interface d’authentification ..................................................................................... 83
Figure 58. Aperçu du Rapport de suivi des Engagements ....................................................... 83
Figure 59. Aperçu de Tableau de bord Engagement ................................................................ 84
 Liste des tableaux

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

Table 2. Méthodes AGILES Vs méthodes classiques .............................................................. 12
Table 3. Comparaison entre les outils de créations du DataWarehouse. ................................. 19
Table 4. Comparaison des Outils ETL ..................................................................................... 21
Table 5. Comparaison entre les outils de Reporting. [30] ........................................................ 22
Table 6. Backlog Produit .......................................................................................................... 28
Table 7. Diagramme de Gantt .................................................................................................. 30
Table 8. Backlog Produit 1 ....................................................................................................... 36
Table 9. Mesures de la table de faits ........................................................................................ 36
Table 10. Les dimensions du DataWarehouse « Suivi » .......................................................... 37
Table 11. Table de faits « fact_suivi » ..................................................................................... 38
Table 12. Sprint Backlog 2 ....................................................................................................... 61
Table 13. Choix des mesures de la table de faits « Fact_Risque » .......................................... 64
Table 14. Choix des dimensions du Datamart .......................................................................... 65
Table 15. Sprint Backlog 3 ....................................................................................................... 73
 Introduction générale

Lucides que l'une des plus grandes richesses d'une entreprise est son information, mais noyé
sous un volume pesant de données dispersées, non structurées, éparses et hétérogènes, les
dirigeants se trouvent confrontés à une problématique de taille : Comment étudier toutes ces
informations si précieuses mais volumineuses, dans un temps quasiment acceptable ? Ces
décideurs requièrent qu'on leur expose les faits importants, appuis de leurs décisions.

Pour répondre à une telle sollicitation, c’est l’informatique décisionnelle, nommée également
BI pour Business Intelligence qui, depuis son apparition, est entrain de submerger les systèmes
d’information (SI) en constante croissance. Il s’agit d’une sélection des informations
opérationnelles et pertinentes qui seront par la suite normalisées pour l’entreposage, puis
l’analyse et finalement la diffusion. De ce concept, est née alors la notion de modélisation
multidimensionnelle, essentielle pour répondre aux exigences d’analyse. En outre,
l’informatique décisionnelle permet de produire des indicateurs et des rapports à l'attention des
analystes en proposant des outils de visualisation, de navigation et d'interrogation de l'entrepôt.

C’est dans cette perspective que s’insère notre projet intitulé « Elaboration d’une solution
décisionnelle pour l’ATB » qui consiste à mettre en place une application intégrée d’aide à la
décision pour la banque ATB permettant de suivre les Engagements, les Produits, les Garanties,
La Classification des Actifs ainsi que les Risques clients.

Ce rapport exhibe les différentes étapes suivies pour la mise en œuvre de notre solution selon
la méthode SCRUM. Il est réparti en six chapitres :

• Le premier chapitre qui s’intitule « Contexte général » est dédié à la présentation de

l’organisme d’accueil de l’ATB ainsi que la présentation du projet.

• Le deuxième chapitre qui s’intitule « Méthodes de conception et outils décisionnels »

récapitule l’étude comparative que nous avons mené en vue de choisir la méthode de conception
la plus adaptée à notre projet, ainsi que l’ensemble des outils BI utilisé.

• Le troisième chapitre qui s’intitule « Phase de préparation » présentera l’analyse des

besoins fonctionnels et non fonctionnels, le Backlog produit, la planification du projet ainsi que
la conception et l’implémentation de la Base de données. Ces parties sont fondamentales pour
assurer un bon démarrage de notre projet

• Le quatrième chapitre qui s’intitule « Mise en place d’un Data Warehouse des Suivis »
traite le premier Sprint qui vise à construire l’entrepôt de données. Il comporte le Backlog
produit, la conception globale de l’entrepôt, le processus décisionnel et finalement, la phase de
restitution des données.

• Le cinquième chapitre qui s’intitule « Suivi et évaluation de la classification des actifs

et des risques clients » traite le deuxième Sprint qui vise à construire le Datamart. Il comporte
le Backlog produit, la définition des différentes classes des actifs, la conception globale du
magasin de données et le processus décisionnel aboutissant à la phase de restitution.

• Le sixième chapitre qui s’intitule « Gestion des Rapports et des Tableaux de bord » traite
notre troisième et dernier Sprint qui assurera la création d’un site web dédié aux décideurs de
l’ATB pour visualiser les rapports générés et les tableaux de bord créés.

En guise de conclusion, nous allons présenter le fruit de notre travail ainsi que nos perspectives
 Chapitre I : Contexte général

1. Introduction

Dans ce chapitre, nous allons évoquer brièvement l’historique de l’organisme d’accueil, ses
missions et son organisation. Par la suite, nous allons introduire le contexte du projet et faire
une étude de l’existant. Enfin, nous allons nous intéresser à la présentation de la solution
proposé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 fonder
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.

1
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 L’Arab Tunisian Bank

Date de création 30 juin 1982
Fondateur Hatem Kchouk
Siège social 9 Rue Hedi Nouira, 1001 Tunis
Forme juridique Société anonyme
Activité Banque
Direction Mohamed Ferid Ben Tanfous
Nombre d’agences 131
Nombre d’employées 1300
Nombre de filiales 9
Capitalisation 100 millions TND en 2015
Bilan comptable 2 696 000 USD en 2014
Téléphone 71351155
E-mail Atbbank@atb.com.tn
Site web http://www.atb.tn/

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

2
 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 Dircetion Adjoint au Direction des Direction central

centrale de
centrale de l'inspection et de directeur affaires du département
financement l'audit général juridiques comptable

Direction des Direction des Direction de

Direction systèmes
moyens de ressources
d'organisation d'infomation
paiement humaines

Division
Division de
administration
coordination
des systèmes

Division études
Division de et
production développement

Service Service
maintenance maintenance
hard application soft

Service
Service maintenance
exploitation application hard
centrale

help desk

Figure 1. Organigramme du siège [3]

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
 3.4 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 est 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 électroniques
 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.5 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.

4
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. Analyse de l’existant

4.1 Etude de l’existant

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 :

5
  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é.

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
format 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.2 Critique de l’existant

La solution utilisée traite chaque module à part. En effet, 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 relatifs aux suivis des
engagements clients. 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 de :

 Un mauvais partage de l’information.

 Un manque de souplesse.

6
  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 qui 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 de données à cause d’un 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.3 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 sources de données hétérogènes.

 Suivre les engagements clients.
 Suivre les produits de la banque tels que les intérêts et les commissions.
 Suivre les garanties et les mettre à jour.
 Suivre la classification des clients
 Calculer les risques d’insolvabilité.
 Analyser les données et générer des rapports et des Tableaux de Bord.
 Diffuser les rapports et les Tableaux de Bord générés dans une interface
utilisateur.

7
  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 des bases décisionnelles. Cette solution permet de 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 aux risques calculés, 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 des décideurs de la banque. Quant au
chapitre qui suit, nous allons énumérer les différentes méthodes de conception et les outils de
l’informatique décisionnelle pour justifier nos choix.

8
 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. Nous allons également faire le choix des outils informatiques que nous
allons utiliser ainsi que 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éthodes de conception

Le projet décisionnel est un projet de type particulier. Il est non seulement complexe, mais 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 la
Business Intelligence. D’ailleurs, toute décision est obligatoirement une prise de risque,
d’autant plus critique à calculer dans un environnement incertain. Par conséquent, il faut choisir
une bonne méthode de gestion adaptée à ce type de projet.

2.1 Etude des méthodes prédictives classiques

Les méthodes classiques de gestion de projet telles que le cycle en V et le modèle en cascade
sont caractérisées par leurs aspects prédictifs, comme son nom l’indique, il faut que tout soit
planifié et défini dès le début. Le principe de la méthode prédictive consiste à collecter dans un
premier temps, les besoins puis déterminer le produit. En d’autres termes, la particularité de
cette méthode consiste à prévoir toutes les étapes de manière séquentielle et de valider l’étape
en amont pour pouvoir passer à l’étape qui suit. De ce fait, le chef de projet s’engage sur un
planning de réalisation du projet bien précis mais il lui est impossible d’anticiper les problèmes
que l’équipe peut rencontrer, dans un environnement où les nouvelles technologies font leurs
apparitions constamment. Prenons l’exemple du cycle en cascade, les risques ne sont détectés
qu’à la phase de test après avoir achevé la phase de développement. En avançant dans la
réalisation du projet, l’impact de ces risques augmente. Néanmoins, parmi les méthodes
classiques, la démarche cycle en V est la plus utilisée lorsqu’il s’agit d’un projet décisionnel.
La figure 2 récapitule les différentes phases de la démarche cycle en V. [4]

10
 Figure 2. Démarche cycle en V [5]

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. » [6]

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

les projets informatiques. La particularité de la méthode agile réside dans le fait qu’elle applique
un principe de développement itératif. Ce principe consiste à découper le projet en « itérations ».
Ces itérations présentent des mini-projets définis au préalable avec le client en déterminant les
différentes fonctionnalités à développer ainsi que leurs priorités. Cette méthode permet d’éviter
les imprévus rencontrés en cours du travail grâce à sa flexibilité aux changements et son
adaptabilité aux modifications. Dans le cadre d’un projet décisionnel, la méthode agile peut être
appliquée. Elle permettra d’avoir un circuit de communication efficace et une possibilité de
modification et de correction par rapport aux exigences du client. Parmi les méthodes agiles les
plus utilisées, nous citons Adaptive Software Development, Scrum et Crystal.

11
 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 Adaptive
Cycle de vie Itératif et incrémental
Documentation Très réduite au strict nécessaire au
profit des fonctionnalités
opérationnelles afin de recevoir les
feedbacks des clients.
Equipe Une équipe soutenue par un chef
de projet où la communication et
l’initiative sont les piliers du
travail.
Livraison de la Généralement rapide et
solution incrémentale.
Intervention du client Très fréquente lors de la mise en
œuvre de la solution avec
proposition de changement si
souhaité.
Mesure de succès Respect des engagements initiaux
en termes de délais, budgets, coûts
et qualité.
Prédictive
En cascade ou en V
Livrée en quantité
importante sous forme d’un
Support de communication
et de validation.
Une équipe composée de
ressources spécialisées
dirigée par un chef de projet.
Généralement tardive.
Pratiquement inexistante, le
client évalue le produit vers
la fin du projet.
Satisfaction du client

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

2.4 Méthode 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 Ralph Kimball, qui se résume en trois points
[8] :

12
  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 le client et d’assurer la valeur métier pour l’organisation.
Après avoir fixée 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.4.1 Présentation de la méthode SCRUM

La méthode 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éthodes incrémentales et itératives.

Cette méthode 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 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.4.2 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.

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

 Le Product 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 à délivrer les éléments de chaque sprint
selon leurs ordres de priorités. Le groupe est constitué d’architectes, de développeurs et
d’administrateurs de base de données.

2.4.3 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 Product 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.

14
  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é.

La figure 3 présente un récapitulatif du processus du projet SCRUM.

Figure 3. Déroulement d'un projet Scrum [12]

2.4.4 L’approche SCRUM appliqué à un projet BI

Lors de l’élaboration d’un projet BI, la solution SCRUM est appelée. Chaque sprint représente
le cycle de vie entier du projet décisionnel qui inclut la phase d’analyse des besoins, la phase
de conception, la phase de réalisation et finalement la phase de test. Cette solution assure
l’adaptabilité du projet à l’égard de l’évolution des besoins de l’utilisateur.

15
En outre, nous nous intéressons dans notre cas, à la mise en place d’un entrepôt de données qui
est au cœur de la technologie BI. De ce fait, nous mentionnons deux écoles de pensées relatives
à la modélisation des données [13] :

 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 du chargement des dimensions, ainsi que
lors de la création 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. [14]

3. Modèle conceptuel

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 qui 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 un 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’il peut 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.

16
 4. 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]

5. 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.

5.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.
Réputé pour sa puissance et sa robustesse, il possède diverses fonctionnalités riches et avancées
permettant de manipuler une grande masse de données et supporter une douzaine de langages

17
de programmation, dont Python, Java, C, C++ ainsi que son propre langage PL/pgSQL qui est
similaire à PL/ SQL d’Oracle. [18]

 SQL Server

SQL Server est un outil de gestion de base de données (SGBD) développé par Microsoft, il
permet à l’utilisateur de manipuler, contrôler, trier, mettre à jour et plusieurs autres
fonctionnalités en utilisant le langage SQL (Structured Query Language). [19]

Le table 3 illustre une Comparaison des propriétés de PostgreSQL et Microsoft SQL Server.
[20]

Critère de comparaison SQL Server PostgreSQL

Licence Commercial Open Source

Classement selon DB- # 3 #4
Engines Ranking en février Score : 1095.51 Score :395.47
2018. [21]
Langage d’implémentation C++ C
Langages de C #, C ++, Delphi, Aller, .Net, C, C ++, Delphi,
programmations supportées Java, JavaScript (Node.js), Java Perl PHP Python
PHP, Python, R, Ruby, Visual
Basic
API et autres méthodes Flux de données API de streaming
d’accès tabulaires OLE DB (TDS) de bibliothèque C
ADO.NET native pour les objets
JDBC volumineux
ODBC ADO.NET

Système d’exploitation Windows, Linux, Mac Os et Windows, Linux, Mac Os

Unix et Unix

Temps d’exécution d’une 581 5095

requête simple en ms Une étude a démontré que SQL Server est quatre fois plus
rapide que PostgreSQL dans la manipulation des données
spatiales.

18
 Sécurité Gestion des environnements Mécanisme de réplication
critiques avancés, disponible que dans la
Mécanisme de réplication version commerciale.
Gestion des Indexes

Table 3. Comparaison entre les outils de créations du DataWarehouse.

5.2 Outils pour Extract Transform Load (ETL)

Nous présenterons dans ce qui suit, quelques outils assurant l’ETL.

 Talend Open Studio

Talend Open Studio est un ETL (Extract Transform Load) développé par la société Talend en
2005. Cet outil Open Source, est doté de capacités avancées d’intégration de données tout en
assurant une exécution optimale. Sur Talend, les « Jobs », appelés aussi tâches permettent de
réaliser des transformations et se font sur une interface nommée « Job Designer ». Pour chaque
job, Talend génère un code Perl ou Java selon la préférence de l’utilisateur permettant
l’exécution des transformations. Talend est capable de gérer des métadonnées grâce à un
référentiel complet de la formation XML et de modéliser également des architectures des
solutions décisionnelles via un Business Modeler. [22]

 Pentaho Data Integration

Pentaho Data Integration (PDI) est un outil ETL (Extract Transform Load) open Source
développé par PENTAHO CORPORATION. Son principal objectif est de permettre aux
utilisateurs la conception, la manipulation et la transformation des données après leur
récupération à partir des sources hétérogènes et sous différents formats. Il est basé sur une
architecture normalisée et est compatible à plusieurs environnements ou solution de Business
Intelligence. [23]

19
  SQL Server Integration Services (SSIS)

SQL Server Integration Services (SSIS) est un outil de gestion de flux de données appartenant
à la famille des ETL. Proposé aux possesseurs d’une licence SQL Server Standard ou
Entreprise, SSIS connu aussi sous le nom de Data Transformation Services dans les versions
antérieures, permet le développement simplifié de scripts d’import et export, en mettant à la
disposition de son utilisateur un large éventail de fonctionnalités via une interface d’édition
graphique. Dans le cadre de gestion des flux de données ETL, SSIS propose principalement
trois types d’éléments [24] :

 Les connecteurs : assurant l’import/export des données

 Les transformateurs assurant la manipulation des données telle que les conversions, les
concaténations, les filtres, les agrégations…
 Les Mappages assurant le « Mapping » qui consiste à mettre en correspondance les
connecteurs et les transformateurs afin de les lier.

La table 4 illustre une comparaison des propriétés de Talend Open Studio, Pentaho Data
Integration et SQL server Integration services. [25]

Critère de
Pentaho Data Integration SSIS
comparaison Talend Open Studio

Open Source
(fonctionnalités limitées)
Licence Open Source Commercial
Commercial (plus de
fonctionnalités)

Classement sur
58 outil
d’intégration
7ème 3ème 2ème
des données

Mise à disposition de Un large appui de point Permet de résoudre

plus de 600 d'émission de données et des problèmes
Performance
composants d’où sa une architecture complexes et
puissance et sa variété extensible. possibilité de

20
 et un référentiel de travailler avec de
stockage avec nombreux
possibilité de partage. connecteurs (oracle,
Teradata, SAP...)

Résultat graphique
basé sur Eclipse RCP
Interface graphique basé
avec une bonne
sur SWT (Standard
Environnement visibilité de Jobs d’où Un outil très visuel
d’exécution Widget Toolkit) simple et
une compréhension
facile à utiliser.
plus rapide de
l’architecture.

Table 4. Comparaison des Outils ETL

5.3 Outils de Reporting

 IBM Cognos

« IBM Cognos Analytics intègre des fonctions de génération de rapports, de modélisation et

d'analyse, des tableaux de bord, des histoires, des indicateurs et la gestion des événements pour
permettre aux décideurs la compréhension des données de leurs organisation et la prise de
décision professionnelle avisée. » [26]

 SQL Server Reporting Services (SSRS)

SQL Server Reporting Services est une solution dédiée à la création, la génération et la
publication des rapports que les clients peuvent déployer dans leurs propres locaux, puis les
distribuer ; soit par visualisation dans un navigateur Web, sur un appareil mobile ou par email.
[27]

 Business Intelligence Reporting Tools (BIRT)

Le projet BIRT est un logiciel développé et diffusé sous une licence libre et fait partie de la
famille des logiciels décisionnels. Il a été initié par l’entreprise Actuate en 2004 en vue de

21
concevoir des rapports, des tableaux et des graphiques basés sur un environnement Eclipse,
ainsi qu’un moteur d’exécution lié avec un serveur de type JEE tel que le serveur JBoss et le
serveur Tomcat. [28]

 QlikView

QlikView est une plate-forme de Business Intelligence et de Data Visualisation développée par
la société américaine Qlik, permettant de transformer les données en connaissances. Elle permet
à son utilisateur d’analyser, chercher, consolider et visualiser les données afin de prendre les
décisions. Les forces de QlikView résident dans sa grande souplesse d’utilisation permettant le
croisement des données entre elles ainsi que sa capacité d’intégrer un nombre important de
sources de données telles que Excel, SQL Server et Oracle. [29]

Le table 5 illustre une Comparaison des propriétés de IBM Cognos, SQL Server Reporting
Services, Business Intelligence Reporting Tools et QlikView.

Critères de
IBM Cognos SSRS BIRT QlikView
comparaisons
Edition
personnelle :
GPL.
Licence Commerciale Commerciale GPL
Edition pour
entreprise :
Commerciale
Via une Via une
Via une Interface Via une Interface
Accessibilité Interface Interface
graphique. graphique
graphique graphique.

Documentation Très bonne Très bonne Bonne Bonne

XML, CSV,
Excel, PDF, CSV
Format de PDF, EXCEL, PDF, CSV et Excel, HTML,
et
rapport généré PowerPoint, HTML Word, PDF
HTML
Word, TIFF file

Table 5. Comparaison entre les outils de Reporting. [30]

22
 6. Environnement de développement retenu

Dans ce volet, nous décrivons les outils de conception et les logiciels de développement utilisés
pour la mise en place de notre solution.

6.1 Outils de conception

 Microsoft Visio 2016

Microsoft Visio est un logiciel de mise en page des diagrammes et des graphiques qui fait partie
de la suite bureautique Microsoft Office. Il permet la modélisation de plusieurs types de
diagrammes UML tels que les diagrammes de cas d’utilisation et les diagrammes de classes. Il
offre également la possibilité de créer des diagrammes de Gantt.

6.2 Outils de développement

 Microsoft Visual Studio 2015

C’est une suite de logiciels conçue par Microsoft dédiée au développement pour Windows et
MacOs. Il constitue un ensemble complet d'outils de développement qui permet de générer
principalement des services web XML, des applications web ASP.NET, des applications mobiles ainsi
que des applications bureautique.

 SQL Server Management Studio 2014

Microsoft SQL Server est un système de gestion de base de données (SGBD) en langage SQL,
développé et commercialisé par Microsoft incorporant entre autres un SGBD relationnel et un
SGBD multidimensionnel, Il peut fonctionner sous les systèmes d’exploitation Windows et
Linux ainsi que sur Mac OS.

 Microsoft SQL Server Data Tools - Business Intelligence pour Visual Studio

SQL Server Data tools, nommé également SSDT est l’utilitaire qui permet la création des lots
SSIS, la conception des cubes SSAS (SQL Server Analyse Services) et la génération des
rapports SSRS (SQL Server Reporting Services). Il est téléchargeable séparément de SQL

23
Server depuis la version de SQL Server 2004 et intégré dans la gamme des outils de
développement de Visual Studio.

 Microsoft SQL Server Reporting Services 2017

SQL Server Reporting Services est une plateforme de Reporting faisant partie de la suite
décisionnelle Microsoft BI. SSRS fournit des fonctionnalités de création de rapports
d'entreprise qui permettent d’extraire et de mettre en forme des données à partir d'une large
gamme de sources de données.

7. Conclusion

A travers ce chapitre, nous avons fait le choix de la méthode de conception de notre projet :
SCRUM ainsi que les outils utilisés, par l’intermédiaire d’une étude comparative détaillée. Dès
lors, nous allons consacrer le chapitre qui suit à la préparation du projet qui inclut la
détermination des besoins.

24
 Chapitre III : Phase de préparation

1. Introduction

La phase de préparation, nommée aussi Sprint 0 selon le Co-créateur de Scrum Ken Schawber,
est consacrée à la description de la partie d’Inception qui précède le lancement de notre projet.
Dans ce chapitre, nous allons donc, étudier les besoins fonctionnels et les besoins non
fonctionnels du système. Par la suite, nous allons produire le Backlog produit et découper la
solution en Sprint. Finalement, nous allons commencer l’étude des données sources.

2. Analyse des besoins

La première étape de cette phase est dédiée à l’analyse des exigences des clients, la définition
des utilisateurs potentiels de notre solution ainsi qu’à la présentation des besoins fonctionnels
et non fonctionnels

2.1 Identification des acteurs du système

Les utilisateurs de notre solution sont subdivisés principalement en deux parties :

 La partie FrontOffice : Ce sont les décideurs et les dirigeants de la banque (utilisateurs

non informaticiens) qui vont pouvoir consulter les rapports et les tableaux de bord via
une interface graphique dans le but d’avoir une vue globale pour des finalités
décisionnelles.
Acteurs : Responsable Crédits et Engagements, Directeur financier, Responsable
affaires juridiques et Recouvrements, Risk Manager et Président Directeur Général que
nous allons nommer Décideur tout au long du projet.

 La partie Back-office (arrière-boutique) : Ce sont les utilisateurs informaticiens, qui,

une fois la solution mise en place, se chargeront de la maintenir.
Acteur : Développeur.

25
 2.2 Spécification des besoins fonctionnels

Le besoin énoncé par notre décideur est le suivant : Développer et concevoir une application

intégrée qui communique avec un entrepôt de données et un Datamart regroupant toutes les

informations relatives aux engagements clients, les garanties, les produits, la classification des

Actifs et les Risques Clients afin de suivre et évaluer la situation de ces derniers en générant

des rapports et des tableaux de bord relatifs à ces sujets d’analyse.

Pour ce faire, nous tacherons à assurer les fonctionnalités suivantes :

- Générer un Rapport qui illustre la répartition des engagements et mettre en place un

Tableau de bord dont le sujet est « Engagement ».
- Générer un Rapport qui illustre la répartition des produits et mettre en place un Tableau
de bord dont le sujet est « Produits ».
- Générer un Rapport qui illustre la répartition des Garanties et mettre en place un Tableau
de bord dont le sujet est « Garanties ».
- Offrir aux décideurs, principalement le responsable des affaires juridiques et
recouvrement, la possibilité de mettre à jour les données relatives aux garanties.
- Générer un Rapport qui illustre la classification des Actifs et mettre en place un Tableau
de bord dont le sujet est « Classification ».
- Générer un Rapport qui illustre les risques des clients et mettre en place un Tableau de
bord dont le sujet est « Risque client ».

Au niveau de l’annexe A, dédié à la description de l’Etat de l’Art d’un projet décisionnel, nous
avons présenté la différence entre un rapport et un tableau de bord.

2.3 Spécification des besoins non fonctionnels

Si les besoins non fonctionnels ne sont pas respectés, notre application risque de rencontrer des
lacunes et des obstacles qui peuvent l’empêcher de fonctionner convenablement. Elle doit alors
répondre aux critères suivants :

26
  La rapidité de traitement : En effet, vu le nombre important des transactions
quotidiennes, il est impérativement nécessaire que la durée d'exécution des traitements
s'approche le plus possible du temps réel.
 La performance : Un logiciel doit être avant tout performant c'est-à-dire à travers ses
fonctionnalités, répond à toutes les exigences des usagers d'une manière optimale.
 La convivialité : Le futur logiciel doit être facile à utiliser. En effet, les interfaces
utilisateurs doivent être conviviales c'est-à-dire simples, ergonomiques et adaptées à
l'utilisateur.
 Fiabilité : l’application doit être fiable et sure à travers ses fonctionnalités qui doivent
répondre aux exigences d’une manière optimale.
 Sécurité : L’application doit être sécurisée et garantit la confidentialité de l’accès.
 Evolutivité : L’application doit avoir la capacité de s’adapter aux changements et aux
futures exigences de la banque

3. Backlog produit

Le Backlog produit présente une liste de fonctionnalités attendues du produit. Cette liste permet
de définir des éléments appelés des histoires « user stories ». Chaque « user story » ajoutée au
Backlog produit doit justifier une valeur ajoutée nommée aussi « business value ».

Notre Backlog produit est défini comme suit :

User story
Thème ID Priorité
En tant que… Je veux… Afin de …
Consulter un rapport
Suivi et
1 dynamique concernant les Avoir une vision globale 1
évaluation Responsable
engagements. de la situation des
des crédits et
Disposer d’un tableau de bord engagements pour des
engagements engagements
2 interactif relatif aux fins décisionnelles. 1
.
engagements.
Consulter un rapport
Avoir une vision globale
Suivi et 3 dynamique concernant les 1
Directeur de la situation des
évaluation produits.
financier produits pour des fins
des produits. Disposer d’un tableau de bord
4 décisionnelles. 1
interactif relatif aux produits.

27
 Consulter un rapport
5 dynamique concernant les 1
Suivi et Responsable Avoir une vision globale
garanties.
évaluation affaires de la situation des
Disposer d’un tableau de bord
des 6 juridiques et garanties pour des fins 1
interactif relatif aux garanties.
garanties. recouvrement décisionnelles.
Mettre à jour les données
7 1
relatives aux garanties.
Consulter un rapport
8 dynamique concernant la 1
classification des Actifs.
Suivi et
Disposer d’un tableau de bord
évaluation
9 interactif relatif à la Avoir une vision globale 1
de la
classification des actifs. de la classification et les
classification Risk Manager
Disposer d’un tableau de bord risques pour des fins
des actifs et
10 interactif relatif aux risques décisionnelles. 1
les risques
clients.
clients.
Consulter un rapport
11 dynamique concernant les 1
risques clients.

Table 6. Backlog Produit

4. Planification du projet

4.1 Pilotage du projet avec la méthodologie SCRUM

L’équipe de notre projet est composée de quatre membres représentés par la figure 4 :

 Le product Master est Mme Lilia Rejeb, chef département informatique à l’ISG.
 Le product Owner est Mr Aymen Sahraoui, membre de l’équipe BI au sein de l’ATB.
 Le team members sont Mohamed Amine Kdous et Chirine Sammouda.

28
 Scrum master Product Owner Equipe de travail

Mme Rejeb Lilia Mr Sahraoui Aymen Mohamed Amine Kdous

Chirine Sammouda

Figure 4. Equipe Scrum

4.2 Découpage de la solution en Sprints

Nous avons choisi de découper notre solution en 3 sprints après avoir étudié les besoins du
décideur comme suit :

Sprint 1 : Générer des rapports dynamiques et des tableaux de bord

interactifs concernant les engagements, les produits et les garanties.

Sprint 2 : Générer des rapports dynamiques et des tableaux de bord

interactifs concernant la Classification des Actifs et le Risque

Sprint 3 : Diffuser et Gérer les rapports et des tableaux de bord relatifs

aux sujets d'analyse traités sur une platforme web dynamique.

Figure 5. Répartition des Sprints

29
 4.3 Diagramme de Gantt

Dans le but de mener à bien notre projet et pour assurer une bonne organisation, nous avons
constitué un chronogramme qui englobe les différentes tâches à réaliser :

 Etape 1 : Familiarisation avec la partie métier

 Etape 2 : Etude de l’existant et Analyse des besoins
 Etape 3 : Comparaison et Analyse des données sources
 Etape 4 : Modélisation et Développement du Sprint 1
 Etape 5 : Modélisation et Développement du Sprint 2
 Etape 6 : Modélisation et Développement du Sprint 3
 Rédaction du Rapport

Février Mars Avril

S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4
Etape 1
Etape 2
Etape 3
Etape 4
Etape 5
Etape 6
Rédaction du rapport

Table 7. Diagramme de Gantt

5. Etude des données sources

Maintenant que les besoins fonctionnels sont identifiés, il faut commencer la collecte des
données.
Cette section est consacrée à l’étude des données sources extraites à partir du système
d’information de la banque avec lesquelles nous allons alimenter notre entrepôt.
Pour des raisons de confidentialités et de sécurité, il n’était pas possible que nous ayons accès
aux serveurs de la banque dans lesquels sont stockés des données personnelles des clients. Les

30
données sources nous ont été livrées sous format Excel. Nous avons alors créé une base de
données relationnelle contenant les tables suivantes :

 Table compte : Cette table contient des informations sur les comptes des clients ATB.
 Table client : Cette table regroupe les informations sociodémographiques de la clientèle
de l’ATB (particuliers et entreprises).
 Table engagements : Cette table contient plusieurs types d’engagement que peut avoir
le client envers la banque.
 Table Activité Cette table comporte le secteur d’activité de chaque client ATB.
 Table garantie : Cette table contient toutes les informations concernant les garanties
détenues sur les clients de la banque.
 Table produits : Cette table regroupe les produits et les revenus de la banque.
 Table agence : Cette table contient les informations relatives aux agences de l’ATB.

 Table groupe Cette table comporte la description des groupes engagés à l’ATB tel que
le groupe délice.

 Table classe : Cette table comporte les différentes classes des actifs de l’ATB.

Le dictionnaire des données complet figure dans l’annexe B.

6. Conception de la base de données

Cette partie est dédiée à la modélisation des données au niveau relationnel (ou logique). Ceci
implique la création des tables dans SQL server et l’établissement des relations. Nous avons
nommé cette base « ATBTEST_DB ». (Voir figure 6)

31
 Figure 6. Modélisation de la base de données

7. Alimentation de la base de données

L’étape qui suit la création de la base au niveau se SQL Server, est l’alimentation de cette base
avec les données sources livrées sous format Excel. Pour ce faire, nous avons eu recours à
Visual Studio Integration Services qui constitue un ensemble de packages assurant le
chargement des données. Pour chaque table, nous avons décidé de créer un Package de
chargement distinct. (Voir figure 7)

32
 Figure 7. Les Packages de chargement de la base de données

Le processus de chargement des tables sera expliqué en détail au niveau du chapitre suivant.
Maintenant, nous allons nous contenter de montrer un exemple de chargement de la table
Produit à partir d’une source Excel, vers une OLE DB Destination. (Voir figure 8)

Figure 8. Chargement de la table Produit

33
Le passage d’une conversion de données est obligatoire à ce stade, elle permet de convertir les
types des données d’une colonnes d’entrées si souhaité.

Figure 9. Conversion des données de la table Produit

8. Conclusion

Dans ce chapitre nous nous sommes intéressés aux acteurs du système, aux besoins fonctionnels
et non fonctionnels, ainsi qu’à l’élaboration du Backlog Produit qui est l’output essentiel de ce
chapitre. Puis nous sommes passés à la planification du projet en découpant la solution en
Sprint. Finalement, nous avons étudié les données sources livrées. Dans le chapitre suivant,
nous allons entamer le premier Sprint.

34
 Chapitre IV :
Sprint 1 : Mise en place d’un Data Warehouse des Suivis

1. Introduction

Ce chapitre sera dédié au traitement du premier Sprint qui évoque tout le processus d’un projet
BI. Cela implique principalement, la mise en place d’un DataWarehouse en passant par l’ETL,
ainsi que la restitution des données. Nous allons alors, détailler toutes ces étapes en partant des
données livrées jusqu’à l’élaboration des Tableaux de bord et la génération des Rapports relatifs
aux Engagements, Produits et Garanties comme expliqué dans le chapitre qui précède au niveau
du Backlog Produit.

2. Sprint Backlog

Le Sprint Backlog fait partie des artéfacts de la méthodologie SCRUM. Il est utilisé dans le but
de faciliter la répartition des tâches et permet de faire la mise au point du travail demandé en
vue d’atteindre les objectifs du sprint concerné. Dans le cas du Sprint 1, l’objectif est de
construire un Datawarehouse dont le sujet est le suivi des Engagements, Produits et Garanties
puis en générer des Rapports et des Tableaux de bord.

Le tableau 8 représente le backlog du premier sprint :

ID User Story ID Tâche

Tâche
Identification des mesures et des dimensions à partir des
En tant que 1.1
données source.
développeur je
Mise en place d’un entrepôt de données tout en précisant
souhaite mettre en 1.2
la conception utilisée.
1 place un Data
Appliquer les transformations nécessaires aux données
Warehouse et créer
sources afin de satisfaire les exigences de notre projet
des rapports et des 1.3
telles que le nettoyage, la filtration et l’élimination des
Tableaux de bord
redondances.

35
 dynamiques et Chargement des données traitées dans l’entrepôt de
1.4
interactifs. données en se référant de la conception choisie.
Génération des rapports dynamiques et un tableau de
1.5
bord interactif relatifs aux engagements.
Génération des rapports dynamiques et un tableau de
1.6
bord interactif relatifs aux produits.
Génération des rapports dynamiques et un tableau de
1.7
bord interactif relatifs aux garanties.
1.8 Préparer une interface de mise à jour des garanties.

Table 8. Backlog Produit 1

3. Conception du DataWarehouse

3.1 Choix des mesures

Pour préparer la table de faits, il faudra bien se servir des éléments recueillis et collectés lors de
la phase de préparation et étude des données sources. Il faudra alors préciser les éléments que
nous souhaitons mesurer.

Dans notre table de faits, nous avons retenu les mesures indiquées dans le tableau 9 :

Mesure Libellé

PORTEFEUILLE_FINAN Portefeuille financier

TOT_IMP Total des impayés
MNTDEC Montant découvert
TOT_ENG_AC Total des engagements accumulés
TOT_PROD Total des produits
TOT_GAR Total des garanties
STRATE Les couches
VAR_ENG Variation des engagements
GAG_PLAFF_A_L_ENG Garantie Plafonnée à l’engagement

Table 9. Mesures de la table de faits

36
 3.2 Choix des dimensions

On entend par dimensions, tous les axes ou thèmes suivant lesquels les données seront
analysées. On attribue une table à chaque dimension ce qui implique qu’il existe autant de tables
de dimension que de dimensions.

Une table de dimension comporte des attributs et une clé primaire indépendante des attributs.
Notre modèle comportera les dimensions suivantes :

Dimension Libellé
Dim_temps Dimension temps

Dim_compte Dimension compte

Dim_agence Dimension agence

Dim_groupe Dimension groupe

Dim_client Dimension client

Dim_activité Dimension activité

Dim_classe Dimension Classe

Table 10. Les dimensions du DataWarehouse « Suivi »

3.3 Table de faits

La table de fait contient les données observables (les faits) que l’on possède sur un sujet et
que l’on veut étudier, selon divers axes d’analyse (les dimensions).

La table de fait dans notre cas se présente dans le tableau 11.

Les clés étrangères NUM_CPT Numéro du compte

ID_TEMPS Identifiant temps
Les mesures PORTEFEUILLE_FINAN Portefeuille financier
TOT_IMP Total des impayés
MNTDEC Montant découvert

37
 TOT_ENG_AC Total des engagements année
courante
TOT_PROD Total des produits
TOT_GAR Total garanties
STARTE Les couches
VAR_ENG Variation des engagements
GAG_PLAFF_A_L_ENG Garantie Plafonnée à
l’engagement

Table 11. Table de faits « fact_suivi »

4. Modélisation du DataWarehouse

Voici finalement notre schéma conceptuel du DataWarehouse.

Figure 10. Modèle en flocon de neige du DataWarehouse « Suivi »

38
 5. Intégration des données du DataWarehouse « Suivi » (ETL)

L’ETL est une phase primordiale dans un projet Décisionnel, elle représente les trois quarts de
la totalité du projet. Elle comporte [31] :

 L’extraction des données d’applications et de bases de données de production (Fichier

plat, Excel, bases de données transactionnelles, etc.).

 La transformation de ces données afin de les rassembler sous un même format

exploitable par les outils d’analyse et de Reporting.

 Le chargement de ces données rafraichies et nettoyées dans des éléments de stockage

permettant une exploitation décisionnelle : entrepôts de données, magasins de données,
etc.

Pour ce faire, nous avons créé un nouveau projet dans l’environnement Visual Studio 2015 et
nous avons choisi « Integration Service » sous la rubrique « Business Intelligence » comme
indiqué dans la figure 11.

Figure 11. Création d'un nouveau projet SSIS

39
Le projet Integration Services est composé de plusieurs Packages, qui à leurs tours sont
composés des Flux de contrôle et des Flux de données : Dans SSIS, l’onglet Flux de contrôle
permet de gérer les tâches nécessaires aux transformations et les éléments de contrôle que le
package va exécuter. Au niveau de l’onglet Flux de données, s’effectue la sélection des données
sources, les transformations qu’elles vont subir, et la précision de leurs destinations. Le schéma
dans la figure 12 clarifie la composition d’un package simple.

Figure 12. Composition d'un Package SSIS simple [32]

5.1 Extraction des données

Nous nous sommes basés sur les tables sources définies dans notre base de données afin
d’extraire les mesures et les dimensions dans l’entrepôt de données en tenant compte des
relations et des contraintes établies. Les tables utilisées pour l’extraction des données sont les
suivantes :

 T_ACTIVITE
 T_AGENCE
 T_CLASSE
 T_CLIENT
 T_COMPTE
 T_ENGAGEMENT
 T_GARANTIE
 T_GROUPE
 T_PRODUIT

40
Nous avons choisi d’extraire les données relatives à ces tables de notre base de données

ATBTEST_DB et les charger dans un entrepôt de données nommé ATBTEST_DW dans

SQL SERVER en utilisant des packages SSIS.

Chaque package comporte une tâche de flux de données qui assure l’extraction des données ;
et chaque tâche de flux de contrôle assure la mise à jour des Tables. Dans notre cas, nous avons
eu recours à une tâche « Execute SQL Task » que nous avons nommé « Delete » qui permet
d’effectuer une requête SQL à chaque exécution du package pour éviter la duplication des
données. [33] (Voir figure 13 et 14)

Figure 13. Package pour l'extraction des données à partir de la base « ATBTEST_DB »

Figure 14. Tâche d'exécution de la requête SQL « Delete »

41
 5.2 Transformation des données

Pour garantir la réussite d’un ETL, il faut accorder une grande importance aux transformations
des données, sujet que nous allons traiter dans cette section.

Pour que les données soient significatives et utilisables plus tard lors de la génération des
rapports et des Tableaux de bord de l’ATB, elles doivent être nettoyées, triées et vérifiées en
vue d’éliminer toutes sortes de valeurs aberrantes et dupliquées. Il faut aussi traiter les données
manquantes ainsi que la standardisation des référentiels tels que les unités, la devise etc.

Nous allons citer dans ce qui suit, les différentes transformations apportées durant le premier
Sprint.

 Dimension Activité
La dimension activité permet d’identifier l’activité des clients. Mais, le problème rencontré
avec les données sources de la table Activité est le suivant : Quelques descriptions de l’activité
des clients sont inexistantes. Nous avons donc, procédé à remplacer les descriptions vides
(NULL) par l’expression « Description indisponible » afin d’éviter les complications dans les
étapes plus avancées.

Figure 15. Transformation appliquée à la Dimension Activité

42
Pour ce faire, nous avons utilisé la tâche « SQL STATEMENT » pour mettre à jour les données
de cette dimension à l’aide d’une requête SQL comme l’indique la figure 15.

 Dimension Agence

Dans la dimension Agence, nous avons transformé le champ COD_AGE, qui représente le code
de l’agence, faute d’inadéquation avec les numéros de compte. En effet, pour distinguer
l’appartenance de chaque client à une agence, il faut que le numéro de compte du client
comporte le code de son agence. La Banque exige que les codes d’agence soient dans un format
prédéfini, c’est-à-dire les codes agence qui débutent par 58 doivent être remplacés par 0 et 59
doivent être remplacés par 1.

Pour ce faire, nous avons utilisé la tâche « SQL STATEMENT » pour transformer le champ
code agence de cette dimension à l’aide d’une requête SQL comme l’indique la figure 16.

Figure 16. Transformation appliquée à la dimension Agence

43
  Table de Faits « Suivi »

Pour traiter le premier sprint qui s’intéresse au suivi des engagements, des produits et des
garanties il faut intégrer les données relatives à ces sujets dans la table de faits que nous
l’appelons « Fact_suivi ».

Les mesures de la table de faits « fact_suivi » sont issues de différentes tables sources telles que
T_engagement, T_produit et T_compte de la base de données initiale. Nous avons commencé
par trier et éliminer les redondances dans chaque table. (Voir figure 17)

Figure 17. Tri des données à charger dans la table de faits

44
Une fois le tri effectué, nous avons utilisé l’élément « Merge Join », permettant de fournir un
output en associant deux ensembles de données triés à l’aide d’une jointure FULL OUTER
JOIN. (Voir figure 18) [34]

Figure 18. Transformations aboutissant à la table de faits

Pour notre solution décisionnelle, il faut combiner plusieurs valeurs et effectuer des sommations
au niveau des mesures de la table de faits. Pour cela, nous avons opté pour l’élément « Derived
column » qui permet de créer de nouvelles valeurs en appliquant des expressions sur les
colonnes d’entrée telles que des fonctions, des opérations mathématiques et des combinaisons
de variables. Le résultat sera ajouté dans une nouvelle colonne ou bien inséré dans une colonne
existante. [35]

Dans notre cas, les transformations nécessaires au niveau de la table de faits sont des
sommations de plusieurs valeurs d’entrée. Nous allons détailler ces transformations dans ce qui
suit.

 Portefeuille = AUTCRDCT+AUTCRDMT+CRDMTRES+CRDLTORD

 Total_imp = IMPRINC+IMPINTER

 Total_gara= [GARETAT]+ [GARBQE]+ [AUTGARRE]+ [GAR_REELLE]

45
  Total_prod= [INTERETS_DEBITEURS]+ [AUTRES_COMMISSIONS]

+[COMM_MONETIQUE]+ [COMM_SUR_VIR_PRELEV]

+[COMM_SUR_CREDIT]+ [COMMISIONS_EXIMBILS]

+[INT_SUR_BONS_DE_CAISSES_AVANCEE]+

[INT_SUR_FINANCEMENTS_DEVISES]+

[COMM_SUR_OPERATION_EFFETS] +[COMM_SUR_OPERATION_CHEQ]+

[AGIOS_DEBITEURS]+ [INT_RETARD_PTF_ESCOMPTE_COMM]

+[INT_PTF_ESCOMPTE_COMMER]+ [PDT_LENDING_H_NET_DESCOMPTE]+

[PDT_LENDING_NET_DESCOMPTE]+

[INT_SUR_CPTES_PERSONNELS_ATB]+ [INT_DE_RETARD_LENDING]+

[INT_DE_RETARD_MANUEL]

 Var_eng=TOT_ENG_AC-TOT_ENG_AP

Comme la figure 19 le montre, ces transformations sont appliquées dans le « Derived Column
Transformation Editor ».

Figure 19. Tâche de transformation "Colonne dérivée" appliquée à la table de faits

46
5.3 Chargement des données

Une fois les transformations nécessaires effectuées et que les tables obtenues répondent aux
besoins de notre solution, il est temps de les charger dans une structure qui n’est autre que le
Datawarehouse, que nous avons déjà créé dans SQL Server nommé « ATBTEST_DW ».

Puisque les données seront stockées dans SQL server, nous avons choisi comme Destination
« OLE DB » dans SSIS comme indiqué dans la figure 20.

Figure 20. Choix de Destination de Chargement de données

Nous avons commencé par charger les dimensions à partir des données sources en assurant à
chaque fois le tri. Pour la dimension temps, son alimentation se fait à partir de la table des
engagements qui comporte les champs Mois et Année. En effet, ces champs figurent dans 3
tables sources : Table engagement, Table Produit et Table Garantie. Nous tenons à préciser que
le choix est aléatoire vu que ces informations sont identiques dans toutes les tables citées. (Voir
figure 21)

Par la suite, nous avons clôturé la phase de l’ETL par le chargement de la table de faits
« Fact_suivi » pour enfin, obtenir notre Datawarehouse total stocké au niveau de SQL server.
(Voir figure 22)

47
Figure 21. Chargement des Dimensions et de la Table de faits

Figure 22. Chargement de la table de faits

48
 6. La restitution des données

Les « outils-end-users » sont les outils de restitution des données. Ces outils constituent les
piliers du système décisionnel sur lesquels l’utilisateur s’appuie afin de prendre les décisions.

Comme solution de restitution des données, nous avons choisi les rapports et les Tableaux de
bord. Dans un cadre d’une démarche de progrès, le tableau de bord est assurément l’instrument
de mesure le plus performant, il facilite la conduite proactive d’une ou plusieurs activités. Le
Dashboard contribue à la réduction de l’incertitude et facilite la prise de risque jointe à toutes
sortes de décisions.

Quant au Reporting, il est dédié à élaborer, publier et diffuser les rapports d’activité de
l’entreprise selon un format prédéterminé. Le principe de l’outil de Reporting c’est qu’il assure
une interrogation des bases de données en fonction des requêtes SQL préalablement préparées
au moment de la réalisation du modèle.

Nous avons détaillé la phase de restitution dans l’annexe A.

Dans notre cas, nous avons décidé d’assurer la phase de restitution à l’aide de SQL Server
Reporting Services (SSRS) 2017 comme mentionné dans le deuxième chapitre. [36] (Voir
figure 23)

Figure 23. Interface de SQL Server Reporting Services

49
Pour accéder à l’interface illustré dans la Figure 24, un passage par le Report Server
Configuration Manager s’impose. Il permet de définir et modifier les paramètres du serveur et
du portail Web. Mais, avant de pouvoir utiliser le serveur, il faut configurer l’URL du service
web (figure 24), l’URL du portail web (figure 25) et la base de données (figure 26).

Figure 24.Configuration de l'URL du service web

Figure 25. Configuration de l'URL du portail web

50
 Figure 26. Configuration de la base de données

La première étape consiste à sélectionner les sources de données des rapports à générer et des
tableaux de bord à créer. Pour établir cette tâche, il suffit de choisir « Source de données » dans
la rubrique « Nouveau » comme indiqué dans la figure 27.

Figure 27. Création d'une nouvelle Source de données

Par la suite, il faut établir la connexion avec la base en précisant la chaine de connexion. Dans
ce cas, nous avons choisi notre base multidimensionnelle qui réside dans le serveur local
DESKTOP-U9NCUTE. [37] (Voir figure 28)

51
 Figure 28. Chaîne de connexion avec le DataWarehouse « ATBTEST_DW »

De même pour la connexion avec la base de données relationnelles puisque nous avons opté
pour l’approche HOLAP permettant d’accéder à la fois aux données agrégées à traves MOLAP
et aux données détaillées à travers ROLAP. (Voir figure 29)

Figure 29. Chaîne de connexion avec la base de données « ATBTEST_DB »

52
Une fois les connexions aux bases établies, nous passons à la génération des Rapports et des
Tableaux de bord. Au niveau de ce sprint, nous nous intéressons aux suivis des Engagements,
des Produits et des Garanties. Par conséquent, nous avons décidé de générer un Rapport et
d’élaborer un Tableau de bord pour chaque sujet.

Les étapes à suivre pour générer un rapport et celles pour construire un tableau de bord sont
très similaires. Nous commençons par un exemple de génération d’un rapport. Prenons
l’exemple d’une partie d’un rapport relatif aux Engagements. Nous nous intéressons à
déterminer les 5 groupes dont les engagements sont en évolution et les 5 groupes dont les
engagements sont en recul.

La première étape consiste à déterminer les données à utiliser dans le DataSet ou Jeu de
données, à traves SQL server Report Builder. Nous allons choisir « DW » comme source de
données. (Voir figure 30 et 31)

Figure 30. Création d'un nouveau Jeu de données

Figure 31. Choix de source de données dans Report Builder

53
Une fois la source fixée, nous allons importer les données à visualiser dans le rapport. Dans le
cas du rapport des engagements, nous avons décidé d’afficher les 5 groupes dont les
engagements sont en évolution et les 5 groupes dont les engagements sont en recul comme
mentionnée. Pour ce faire, nous avons exécuté deux requêtes SQL dans le Générateur des
Rapports (Report Builder).

La figure 32 présente la requête SQL 1 permettant d’identifier les 5 groupes dont les
engagements sont en évolution.

Figure 32. Jeu de données dans le Report Builder (requête 1)

La figure 33 présente la requête SQL 2 permettant d’identifier les 5 groupes dont les
engagements sont en recul.

54
 Figure 33. Jeu de données dans le Report Builder (requête 2)

La deuxième étape consiste à créer un nouveau Rapport mobile à l’aide de l’éditeur des
Rapports mobile de SQL Server.

Figure 34. Création d'un nouveau Rapport mobile

55
Dans l’éditeur des Rapports, il suffit de choisir « Grilles des données », puis quoique le type
choisi soit, il faut spécifier les données que nous avons déjà importé dans Report Builder lier à
cet élément. (Voir figues 35 et 36)

Figure 35. Choix d'une grille de données pour le

Rapport

Figure 36. Ajout des données du DataSet

Puis, il ne reste qu’à paramétrer les données en modifiant les noms des champs, le type et en
ajoutant par exemple, une colonne de comparaison si souhaité en indiquant les colonnes à
comparer. (Voir figure 37)

56
 Figure 37. Paramétrage du Rapport

Pour enfin obtenir un rapport qui permet de suivre les clients dont les engagements sont en
évolution et ceux dont les engagements sont en recul comme représenté dans la figure 38.

Figure 38. Exemple du Rapport généré

De même pour la création d’un Tableau de bord, il faut passer par la première étape expliquée
précédemment ainsi que la deuxième. La seule différence c’est le choix d’un des éléments
graphiques proposés par l’éditeur de rapport de SSRS (Graphique en secteur, Graphique en
entonnoir, Histogramme, anneau etc.)

57
 Figure 39. Choix du type de graphique à produire

Prenons l’exemple du Dashboard « Engagements ». En passant par toutes les étapes décrites
précédemment incluant l’identification du sujet d’analyse, la création des jeux de données et
leurs ajours lors de l’élaboration du Tableau de bord, le choix des graphiques et leurs
paramétrages, nous obtenons ce résultat. (Voir figure 40)

Figure 40. Dashboard « Engagement »

58
Vers la fin de ce Sprint et après l’enchainement des étapes décrites, nous avons créé :

 Un Rapport concernant les Engagements.

 Un Tableau de bord concernant les Engagements.
 Un Rapport concernant les Produits.
 Un Tableau de bord concernant les Produits.
 Un Rapport concernant les Garanties.
 Un Tableau de bord concernant les Garanties.

7. Conclusion

L’objectif principal de ce sprint est atteint. En achevant ce chapitre, nous avons pu concevoir
notre DataWarehouse relatif aux suivis des Engagements, des Produits et des Garanties en
présentant toute la démarche aboutissant à ce sprint. Par la suite, nous avons restitué les données
à travers des rapports dynamiques et des tableaux de bord interactifs dédiés aux décideurs.

59
 Chapitre V :

Sprint 2 : Suivi et évaluation de la classification des actifs et

des risques clients.

1. Introduction

Le premier sprint est achevé, nous nous intéressons maintenant au deuxième sprint de notre
projet. Ce sprint traitera la consultation de la classification des actifs financiers ainsi que le
calcul des risques client.

2. Sprint Backlog

Le sprint Backlog est utilisé afin de faciliter la répartition des tâches et permet de faire la mise
au point du travail demandé.

Le tableau 12 résume le backlog du deuxième sprint qui vise le traitement de deux sujets
d’analyse : La Classification des Actifs et Le calcul des Risques.

ID User Story ID Tâche

Tâche
Conception détaillée d’un Datamart traitant
En tant que 1.1
principalement les risques clients.
développeur je
Identification des mesures et des dimensions du Datamart
souhaite mettre en
1.2 à partir de l’entrepôt de données afin de correspondre au
place un Datamart
sujet choisi.
1 « Risque » et créer
Appliquer les transformations nécessaires aux données
des rapports et des
1.3 extraites telles que le tri, l’élimination des redondances et
Tableaux de bord
le calcul des formules de risques.
dynamiques et
Chargement des données traitées dans le Datamart
interactifs. 1.4
« Risque » en se référant de la conception choisie.

60
 Génération des rapports dynamiques et un tableau de
1.5
bord interactif relatifs à la classification des actifs.
Génération des rapports dynamiques et un tableau de
1.6
bord interactif relatifs aux risques clients.

Table 12. Sprint Backlog 2

3. La classification des Actifs

Dans le but d’établir l’analyse des risques clients, il est indispensable d’effecteur une
classification des actifs financiers, celle-ci permettra de mettre en relation la criticité de l’actif
en question avec les vulnérabilités et les menaces qui lui sont associées.

En effet, la classification repose essentiellement sur deux critères ; la liquidité de l’actif et la

relation juridique entre le débiteur et le créancier.

Par conséquent, la classification permettra objectivement d'évaluer les risques d’une part, et
d'établir un plan de traitement face à ceux-ci d’autre part.

Il existe 5 classes des actifs financiers [38] :

3.1 Actifs courants (Classe 0)

Les actifs courants sont les actifs dont le recouvrement entier dans les délais, semble être assuré.
Ces actifs sont détenus couramment par des entreprises dont :

 La situation financière est stable et justifiée par des documents comptables certifiés qui
datent de moins de 18 mois.
 Les perspectives de l’activité et la gestion globale sont satisfaisantes, confirmées grâce
aux rapports de visites.
 Le volume des encours est compatible avec les besoins de son activité et la capacité de
remboursement.

3.2 Actifs nécessitant un suivi particulier (Classe 1)

Les actifs occupant cette classe sont ceux dont le recouvrement entier dans les délais est
encore assuré. Ces actifs sont détenus habituellement par des entreprises dont :

61
  Le secteur d'activité connaît plus ou moins des difficultés ;
 La situation financière est en dégradation.

Les débiteurs de la classe 1 doivent être toujours prêt de faire face au remboursement de leurs
dettes, sans avoir droit à nouveau financement direct ou indirect de la banque.

3.3 Actifs incertains (Classe 2)

Les Actifs incertains sont les actifs dont le recouvrement entier dans les délais est douteux. Ces
actifs sont détenus généralement par des particuliers ou des entreprises qui rencontrent des
difficultés de type financier ou autres, ce qui pourra mettre en cause leurs validités et requiert
la mise en place des mesures de redressement juridiques.

En plus des caractéristiques des actifs de la classe précédente, ces entreprises disposent d’au
moins une de ces caractéristiques :

 Le volume des encours n’est plus compatible avec l’activité principale.

 Une défaillance accentuée de la disponibilité de l’information ou/et de la documentation
nécessaire pour l’évaluation de la situation financière.
 Un retard de paiement des principaux ou des intérêts entre 90 jours et 180 jours.
 Des problèmes de litige entre les associés
 Des problèmes techniques ou commerciaux

3.4 Actifs préoccupants (Classe 3)

Les actifs qui appartiennent à cette classe sont les actifs dont le recouvrement risque d’être
menacé. Ces actifs sont généralement détenus par des entreprises dont la situation globale
suggère une faillite éventuelle ce qui engendre un appel auprès de la banque pour limiter au
maximum les dégâts. Ces entreprises possèdent avec plus de gravité, les mêmes caractéristiques
que celles de la classe 2.

Leurs retards de paiements des principaux ou des intérêts sont entre 180 jours et 360 jours.

3.5 Actifs compromis (Classe 4)

Font partie de la classe 4 :

 Les créances dont les retards de paiements des intérêts ou du principal dépassent 360
jours.

62
  Les actifs qui sont restés en attente/suspens au-delà de 360 jours.
 Les entreprises qui passent par une perte. La banque est tenue néanmoins d’épuiser
toutes les procédures de droit tendant à la réalisation de ces actifs.

4. Formules pour le calcul des risques

Pour le Calcul des Risques, nous avons opté pour 3 formules différentes. Chacune possède un
objectif bien déterminé.

4.1 Formule de calcul du « STRATE »

Le terme Strate est principalement utilisé dans le domaine de biologie et géologie. Il présente
une sorte de couche homogène des roches sédimentaires avec des épaisseurs variantes.

Dans notre cas, Strate représente des sous-ensembles en lesquels nous allons diviser une
population qui n’est autre que les clients en partant de ces conditions :

 STRATE='1- SUP 1MDT'

Where TOT_ENG_AC=1000000

 STRATE='2- SUP 500KDT'

Where TOT_ENG_AC<1000000 and TOT_ENG_AC>=500000

 STRATE='3- SUP 100KDT'

Where TOT_ENG_AC_REV<1000000 and TOT_ENG_AC_REV<500000
and TOT_ENG_AC_REV<100000

 STRATE='4- SUP 50KDT'

Where TOT_ENG_AC_REV<1000000 and TOT_ENG_AC_REV<500000
and TOT_ENG_AC_REV<100000 and TOT_ENG_AC_REV>=50000

 STRATE='5- INF 50KDT'

Where TOT_ENG_AC_REV<100000 and TOT_ENG_AC_REV<50000

63
 4.2 Formule de calcul de la Variation des engagements

La détermination des écarts entre les engagements d’un client pendant l’année courante et ceux
de l’année précédente, permettent de détecter les risques de la perte éventuel de ce client. C’est
pour cette raison, nous avons appliqué la formule suivante :

 VAR_ENG=TOT_ENG_AC-TOT_ENG_AP

4.3 Formule de calcul de la Garantie plafonnée à l’engagement

Le calcul de la garantie plafonnée à l’engagement permet de déterminer le montant au-delà

duquel le client ne peut pas créditer. Pour trouver cette valeur, il suffit d’appliquer la formule
suivante :

 GAG_PLAFF_A_L_ENG= Min(nvl(tot_gar_ac,0), (TOT_PDT))

5. Conception du Datamart « Risque »

Notre Datamart est orienté vers un sujet bien particulier de l’activité de la banque qui est le
calcul de Risque des clients. Nous avons opté pour un modèle en flocon de neige afin de
respecter la conception utilisée dans l’entrepôt de données.

5.1 Choix des mesures

Pour préparer la table de faits de ce Datamart, il faudra bien se servir des éléments recueillis et
collectés dans l’entrepôt de données. Dans notre table de faits « Fact_RISQUE », nous avons
retenus les mesures comme indiqué dans la table 13.

Mesure Libellé

STRATE Les couches

VAR_ENG Variation des engagements
GAG_PLAFF_A_L_ENG Garantie plafonnée à l’engagement

Table 13. Choix des mesures de la table de faits « Fact_Risque »

64
 5.2Choix des dimensions

Les dimensions choisies dans notre Datamart sont représentées dans la table 14.

Dimension Libellé
Dim_temps Dimension temps

Dim_compte Dimension compte

Dim_agence Dimension agence

Dim_client Dimension client

Dim_activité Dimension activité

Tableau 14. Choix des dimensions du Datamart

5.3 Modélisation du Datamart

La figure 41 présente la modélisation du Datamart « Risque » contenant les données que nous
allons manipuler lors de la création du Tableau de bord et du Rapport des Risques.

Figure 41. Modèle en flocon de neige du Datamart « Risque »

65
 6. Intégration des données du Datamart « RISQUE » (ETL)

6.1 Extraction des données

Nous nous sommes basés sur les tables de dimensions et la table de faits définies dans notre
entrepôt de données afin d’extraire les mesures et les dimensions nécessaires pour le Datamart
du risque en tenant compte des relations et des contraintes établies. Les tables utilisées pour
l’extraction des données sont les suivantes :

 FACT_SUIVI
 Dim_Temps
 Dim_Compte
 Dim_Agence
 Dim_Client
 Dim_Activite

Nous avons choisi d’extraire les données relatives à ces tables de notre entrepôt de données
ATBTEST_DW et les charger dans un Datamart nommé RISQUE_DM ayant principalement
le risque des clients comme sujet dans SQL SERVER en utilisant des packages SSIS.
L'extraction des tables relatives est assurée par une tâche de flux de données. Une autre tâche
qui s’intitule « Execute SQL Task » que nous avons nommé « Delete » permet d’exécuter des
requêtes SQL à chaque lancement du package pour éviter la duplication des données.

Figure 42. Exécution de Package d'extraction

66
 6.2 Transformation des données

Avant le chargement des données dans le Datamart, nous les avons triées selon leurs Identifiants
et nous avons éliminé les redondances en cochant « Remove rows with duplicate sort values »
pour assurer une bonne représentation des données dans chaque table de destination.

Par la suite, nous avons calculé le risque en suivant les formules précédemment citées en
utilisant un script en langage c sharp. Nous avons ajouté le résultat de ces calculs dans de
nouvelles colonnes créés à l’aide de l’élément « Script Component ».

Figure 43. Le tri des données avec Sort Transformation Editor

Figure 44. Transformations aboutissant à la table de faits « Fact_Risque »

67
En cliquant sur le Script Component que nous avons nommé Calcul de Risque, le Script
Transformation Editor nous donne la possibilité de préciser les nouvelles colonnes dans
lesquelles seront stockés les résultats du calcul dans la section des Outputs comme le montre la
figure 45.

Figure 45. Paramétrage des Transformations de la table de faits « Fact_Risque » et des Inputs et
Outputs

De cette manière-là, sont créées les nouvelles colonnes que nous allons alimenter avec un Script
C sharp en cliquant sur Edit Script sous la section Script de l’éditeur comme indiqué sur la
figure 46.

68
.

Figure 46. Bouton aboutissant à la modification du Script C sharp

La figue 47 présente le bout de code C sharp utilisé pour appliquer les formules de « STRATE »
et celui des garanties plafonnées à l’engagement.

Figure 47. Script du code C sharp de la formule « STRATE » et des garanties

plafonnées à l’engagement

69
 6.3 Chargement des données

Après l’extraction et les transformations appliquées sur les données, nous les avons chargées
dans chacune des tables correspondantes comme l’indique la figure 48.

 Source : ATBTEST_DW
 Destination : RISQUE_DM

Figure 48. Chargement du Datamart Risque

7. La restitution des données

La dernière étape de ce Sprint dont le sujet est le suivi de la classification des Actifs et le calcul
des Risque est la phase de restitution en suivant les mêmes étapes citées dans le chapitre
précédent, nous avons donc élaboré :

- Un Rapport dynamique concernant la Classification.

- Un Tableau de bord interactif concernant la Classification.
- Un Tableau de bord interactif concernant les Risques.
- Un Rapport dynamique concernant les risques clients.

70
 8. Conclusion

A travers ce sprint, nous avons pu construire notre Datamart relatif aux risques. Puis nous
avons construit un tableau de bord relatif à ce sujet d’analyse, ainsi qu’un tableau de bord et
un rapport pour la classification des Actifs.

71
 Chapitre VI :
Sprint 3 : Gestion des Rapports et des Tableaux de bord

1. Introduction

En achevant le premier et le deuxième Sprint, nous avons préparé pour les décideurs de l’ATB
un ensemble de Rapports dynamiques ainsi que des Tableaux de bord interactifs qui fournissent
une vue globale de l’activité de la banque.
Ce chapitre présente alors le troisième sprint de notre projet dans lequel nous allons mettre à la
disposition des décideurs un site web simple auquel ils peuvent accéder facilement afin de
consulter les rapports générés et les tableaux de bord élaborés.
Dans un premier temps, nous allons aborder le Sprint Backlog du sprint présent. Puis nous
allons décrire le cas d’utilisation globale. Ensuite, nous allons introduire la partie de conception
de notre site en ayant recours à un diagramme de navigation simplifié.

2. Sprint Backlog
Le Sprint Backlog relatif à ce sprint se présente comme suit :

ID User Story ID Tâche

Tâche
En tant que développeur je Conception d’un site web dynamique en tenant compte des
1.1
souhaite mettre en œuvre besoins des décideurs.
une interface Web
Test du site Web
1.2
1 dynamique et diffuser des
rapports dynamiques et Ajout des rapports dynamiques et tableaux de bords
des Tableaux de bord 1.3 interactifs au site Web.
interactifs.
En tant que responsable Consulter un rapport dynamique concernant les
2.1
crédits et engagements je engagements.
2
souhaite suivre et évaluer Disposer d’un tableau de bord interactif relatif aux
2.2
les engagements. engagements.

72
 En tant que Directeur 3.1 Consulter un rapport dynamique concernant les produits.
financier je souhaite
3 Disposer d’un tableau de bord interactif relatif aux
suivre et évaluer les 3.2 produits.
produits.

4.1 Consulter un rapport dynamique concernant les garanties.

En tant que Responsable
affaires juridiques et Mettre à jour les données relatives aux garanties.
4.2
4 recouvrement je souhaite
Disposer d’un tableau de bord interactif relatif aux
suivre, évaluer et mettre à
4.3 garanties.
jour les garanties.

Consulter un rapport dynamique concernant la

classification des actifs.
En tant que Risk Manager 5.1
Disposer d’un tableau de bord interactif relatif à la
je souhaite suivre et
classification des actifs.
5 évaluer la classification
Consulter un rapport dynamique concernant les risques
des actifs et les risques
clients.
clients. 5.2
Disposer d’un tableau de bord interactif relatif aux risques
clients.

Table 15. Sprint Backlog 3

3. Conception

Cette partie sera consacrée à la présentation des diagrammes de séquences de notre système.
Comme nous avons déjà mentionné, nous allons nous contenter d’une authentification simple,
un exemple de consultation d’un rapport, un exemple de consultation de tableau de bord et
finalement une modification des garanties.

73
 3.1 Diagramme de cas d’utilisation

La figure 49 dévoile le diagramme de cas d’utilisation global de ce sprint

Figure 49. Diagramme de cas d'utilisation global

Comme présenté dans le Diagramme, le site web que nous allons créer sera dédié aux
décideurs de l’ATB, qui dans notre cas peut être le Responsable Crédits et engagements, le
Directeur Financier, le Responsable affaires juridiques et recouvrement ou le Risk Manager.
Ces derniers auront des identifiants et des mots de passe gérés par le Développeur. Ils
n’auront pas l’habilité de créer leurs propres comptes.

74
 3.2 Diagramme de séquence de l’authentification du décideur

Ce diagramme présente les étapes par lesquelles le décideur passe pour s’authentifier :

Figure 50. Diagramme de séquence de l’authentification du décideur

75
 3.3 Diagramme de séquence de la consultation d’un Rapport

Le diagramme illustré dans la figure 51 présente l’interaction du décideur avec le système lors
d’une consultation d’un rapport.

Figure 51. Diagramme de séquence de la consultation d’un Rapport

76
 3.4 Diagramme de séquence de la consultation d’un Tableau de bord

Le diagramme illustré dans la figure 52 présente l’interaction du décideur avec le système lors
d’une consultation d’un tableau de bord.

Figure 52. Diagramme de séquence de la consultation d’un Tableau de bord

77
 3.5 Diagramme de séquence de la mise à jour des Garanties
Le diagramme illustré dans la figure 53 présente l’interaction du décideur avec le système
lors d’une mise à jour des garanties.

Figure 53. Diagramme de séquence de la mise à jour des Garanties

78
 3.6 Diagramme de navigation web

Le diagramme de navigation, ou ce que l’on appelle « Site Map diagram » en anglais est utilisé

pour clarifier la navigation d’un site web en montrant sa structure entière. Il peut être également

utilisé comme un schéma directeur du Site pour le concepteur.

Figure 54. Diagramme de navigation web

79
 4. Environnement de travail
Dans cette partie, nous allons présenter l’architecture physique suivie du choix des
technologies.

4.1 Architecture physique

Les fonctionnalités relatives aux besoins spécifiques de notre solution exigent une mise en place
d’une architecture bien étudiée afin d’assurer une meilleure performance.

C’est pour cette raison que dans notre projet, nous avons opté pour une architecture trois tiers
qui sert principalement à concevoir l’application en trois couches logicielles :

 La couche de présentation des données correspond à l’affichage et assure le dialogue

avec l’utilisateur.
 La couche de traitement qui assure à son tour la mise en œuvre des différentes règles
et la gestion de la logique applicative.
 La couche d’accès aux données correspond aux données qui sont destinées à être
conservées.

La figure ci-contre présente un schéma clair de l’architecture 3-tiers [39] :

Figure 55. Architecture 3-tiers

80
 4.2 Environnement de Développement

Pour notre projet, nous avons opté pour l’utilisation de Microsoft Visual Studio 2015 comme
environnement de développement.

 Microsoft Visual Studio 2015

C’est une suite de logiciels conçue par Microsoft dédié au développement pour Windows et
MacOs. Il constitue ensemble complet d'outils de développement qui permet de générer des
services web XML, des applications web ASP.NET, des applications mobiles ainsi que des
applications bureautique.

4.3 Technologies

En ce qui concerne les technologies adoptées, nous avons choisi :

 HTML

L’acronyme de HTML est HyperText Mark-Up Language. Il s’agit d’un langage de

programmation dont le rôle principal est de formaliser l'écriture d'un document avec des balises
de formatage en vue de créer des pages Web ou bien des emails au format HTML.

 CSS

L’acronyme de CSS est Cascading Style Sheets. Il s’agit d’un langage permettant de gérer la
présentation générale d’une page web en insérant des styles sur le code HTML. Ces derniers
permettent de préciser et de définir les comportements des éléments de la page.

 Java Script

JavaScript désigne un langage de script orienté objet. Il est retrouvé principalement dans des
pages web ou HTML permettant d’interagir avec l’utilisateur. Contrairement aux langages
serveurs, JavaScript s’exécute sur la machine de l’internaute grâce au navigateur.

 C#

C# est un langage de programmation inventé par Microsoft, dérivé du langage C et inspiré du

langage C++. Il est utilisé pour réaliser des sites web et connu par sa ressemblance au langage
Java d’où leur concurrence.

81
 4.4 Réalisation

Pour mettre en place notre site, nous avons créé un nouveau « Web Site » en utilisant la
plateforme .NET. Puis nous avons choisi « ASP.NET Empty Web Site »

A ce stade, nous allons illustrer quelques captures d’écran des pages réalisées. Nous allons
commencer par la page d’accueil qui présente les différentes fonctionnalités de notre solution,
puis la page d’authentification. Ensuite, nous allons enchaîner avec un exemple d’interface de
Rapport et un autre de Tableau de bord.

Nous présentons dans la figure 56 la page d’accueil.

Figure 56. Page d’accueil

82
Nous présentons dans la figure 57 l’interface d’authentification.

Figure 57. Interface d’authentification

Nous présentons dans la figure 58 un aperçu du rapport de suivi des Engagements.

Figure 58. Aperçu du Rapport de suivi des Engagements

83
Nous présentons dans la figure 59 un aperçu de Tableau de bord Engagement.

Figure 59. Aperçu de Tableau de bord Engagement

5. Conclusion

A travers ce troisième et dernier Sprint, nous avons pu concevoir notre interface web en
définissant les diagrammes qui lui sont relatives. Puis nous avons précisé l’environnement de
travail au niveau de l’architecture adoptée et les technologies utilisées pour enfin diffuser les
rapports et les Tableaux de Bord générés préalablement dans notre site web.

84
 Conclusion Générale

Nous nous sommes intéressés tout au long de notre stage à la conception et la réalisation d’une
solution décisionnelle qui permet aux décideurs de l’ATB de suivre les engagements, les
produits et les garanties bancaires, ainsi qu’avoir accès au suivi de la classification des clients
tout en se référant au risque calculé pour enfin diffuser les rapports dynamiques et les Tableaux
de Bord interactifs relatifs à chaque module dans une interface web dynamique pour des fins
décisionnelles.

Cette solution ne peut pas être conçue sans le recours à un DataWarehouse et un DataMart qui
englobent les mesures nécessaires et les dimensions adéquates afin d’assurer une meilleure
présentation des rapports et des Tableaux de Bord générés ce qui explique le choix des bases
de données décisionnelles.

Au cours de la réalisation de notre solution, nous avons introduit en premier lieu le contexte
général du projet tout en mettant l’accent sur la direction centrale des systèmes d’information
dans laquelle notre stage s’est déroulé. Puis, nous avons enchaîné avec l’étude de l’existant et
la spécification des besoins qui nous ont permis de proposer une solution qui répond aux
exigences des décideurs.

Par la suite, la comparaison des méthodes de conceptions nous a permis d’adopter la méthode
SCRUM appliquée à l’informatique décisionnelle afin de faciliter la planification de notre
travail et la répartition des tâches.

Le même enchainement a été appliqué aux deux premiers Sprints en identifiant le Sprint
Backlog relatif à chacun, en passant par l’intégration des données après avoir adopté une
conception et une modélisation adéquate du DataWarehouse et du DataMart pour finir avec la
restitution des données qui n’est autre que la génération des rapports dynamiques et des
Tableaux de Bord interactifs.

Quant au dernier Sprint qui est dédié à la diffusion des rapports et des tableaux de bords générés
dans les sprints précédents dans une interface web dynamique. Pour ce faire, nous avons
commencé par la définition du Sprint Backlog. Par la suite, nous avons conçu notre site web
qui répond aux exigences des décideurs définies au préalable. Et clôturant avec l’environnement
du travail en précisant l’architecture adoptée et les technologies utilisées.

85
Néanmoins, il est à signaler que nous avons rencontré quelques imprévus et ce pour plusieurs
raisons. En effet, nous avons pris plus de temps que prévu à comprendre les fondamentaux du
métier de la banque, qui occupe une grande partie de notre projet. En outre, l’accès aux serveurs
de données est malheureusement limité aux personnels de l’ATB. Ce qui a décéléré le rythme
du travail.

Ce stage s’est révélé instructif et enrichissant du point de vue des connaissances acquises. Il
nous a procuré une opportunité pour sculpter nos compétences techniques telle que la maîtrise
des outils décisionnelles qui nous seront utiles dans la vie professionnelle. Par ailleurs, ce stage
a contribué à améliorer notre sens d’organisation et de planification en suivant une
méthodologie bien définie et à assumer nos choix.

Cette opportunité si précieuse a dévoilé notre esprit d’équipe et a démontré nos capacités
relationnelles et communicatives.

Nous ne pouvons pas nier le fait qu’un tel projet possède des perspectives d’évolution et
d’amélioration. A titre d’exemple, nous citons le développement d’une application mobile,
instance du site créé. Une autre perspective possible consiste à préparer aux décideurs, une
fonctionnalité permettant de générer leurs propres rapports personnalisés.

Finalement, nous souhaitons que ce modeste travail apporte la satisfaction aux membres de
jury.

86
 Annexe A : Le Projet Décisionnel

1. Définition de l’informatique décisionnelle

« La Business Intelligence (BI), également "intelligence d'affaires" ou "informatique
décisionnelle", englobe les solutions informatiques apportant une aide à la décision avec, en
bout de chaîne, rapports et tableaux de bord de suivi à la fois analytiques et prospectifs. Le but
est de consolider les informations disponibles au sein des bases de données de l'entreprise. »
[40]

2. Architecture d’un projet décisionnel

Dans cette section, nous allons parcourir les différents éléments fondamentaux pour la mise en
place de n’importe quelle solution d’aide à la décision commençons par l’extraction des
données à partir des données sources jusqu’à leurs restitutions sous forme synthétisée et
normalisée. La figure ci-dessous illustre l’ensemble des composants intervenant dans le
système décisionnel.

3. Le modèle multidimensionnel

Un modèle multidimensionnel est une combinaison parfaite de tables de dimensions et de table

des faits. Le sujet de l’analyse est le fait. Ce dernier est formé de mesures qui sont généralement
numériques et renseignées de manière permanente et continue. Les mesures permettent de faire

87
un résumer d’un nombre important d'enregistrements des données issus des données sources en
quelques-uns. L’objectif du modèle multidimensionnel est d’analyse le fait selon des axes ou
perspectives qu’on nomme dimensions. Chacune de ces dimensions est définit en une structure
hiérarchique bien déterminée. Prenons le cas de la dimension « temps », Nous pouvons la
diviser en année, trimestre, mois, semaine, jours... Dans la hiérarchie, il découle le niveau de
granularité de l'entrepôt, et donc on parle les niveaux d'agrégations.

Exemple de Cube multidimensionnel à 3 perspectives d'analyse [41]

4. Sources de données

L’alimentation de l’entrepôt se fait à partir des données identifiées et extraites depuis leurs
emplacements originales. En effet, les données à collecter sont stockées dans des systèmes de
natures et de formats différents selon la structure. Il s’agit essentiellement des données internes
du système d’information de l’entreprise (base de données, Excel, CRM, ERP, etc.) ou encore
des données externes récupérées à partir de quelques services distants et des web services. Dans
ce cas, on parle des données complexes. Dans notre projet, nous allons extraire des données à
partir d’une base de données Oracle 11g, du système « Equation » et des fichiers plats.

88
 5. Outil d’extraction, transformation et chargement
Plus connus sous le terme anglo-saxon : Extract Transform Load (ETL), cet outil est
fondamental pour la mise en place des entrepôts de données.

 E pour Extraction des données à partir des données sources dans un environnement de
travail.
 T pour Transformation qui englobe le nettoyage, le filtrage et la manipulation des
données pour le chargement de l’entrepôt de données ou le magasin des données.
 L pour Loading et chargement de l’entrepôt et mise à disposition des données.

L’étape de transformation est décisive car elle permet de filtrer et de fédérer les données en vue
de les rendre homogènes, considérons :

 Le filtrage qui sert à identifier les données problématiques ou aberrantes comme les
données manquantes ;
 Le formatage qui est crucial dans le cas de données codifiées (exemple des abréviations
difficilement convertibles), ou dans le cas des dates qui doivent être dégradées en un
ensemble de champs (années, mois, jours, heures, minutes, etc.) ;
 La synchronisation qui garantit la cohérence entre les agrégats de l'entrepôt ;
 L'agrégation qui est une collection d'opérations, généralement mathématiques, possibles
à appliquer sur les données. Les plus utilisées et courantes sont la somme, le minimum,
le maximum, la moyenne, la somme cumulée etc. Ces opérations sont considérées
compte tenu du niveau de granularité de l'entrepôt.

89
 6. Entrepôt de données
L’entrepôt de données ou Data Warehouse est une base de données dédiée au stockage des
données assimilées dans le cadre de l’analyse décisionnelle et la prise de décision. Le Data
Warehouse est exclusivement destiné à cet usage. Il est alimenté à partir des bases de production
grâce aux outils de l’ETL (Extract Transform Load).

Ensuite, les analystes et les décideurs pourront accéder aux données collectées afin d’étudier
des cas précis de réflexion. Ils construisent des modèles d'étude et de prospective pour limiter
la part d'incertitude lors du processus de prise de décision.

7. Caractéristiques du Datawarehouse
Père du concept datawarehousing, Bill Inmon l’a décrit dans son livre Building the Data
Warehouse : « Subject oriented, integrated, nonvolatile, time variant collection of data in
support of management decisions. » [42]

 Orienté sujet : Au cœur de l’entrepôt, les données doivent être organisées par thème.
Les données appartenant à un thème sont rapatriées des différentes bases d’OLTP et
regroupées.
 Intégré : Puisque les données proviennent de différentes sources hétérogènes et utilisant
chacune un certain type de format, elles seront alors intégrées avant d'être proposées à
utilisation.
 Non volatile : Les données ne changent pas et ne disparaissent pas au cours des
traitements et au fil du temps.
 Historisé : Les données doivent être historisées pour qu’on puisse ainsi visualiser et
traquer l'évolution d’une valeur donnée au cours du temps.

8. Restitution des données

Les « outils-end-users » sont les outils de restitution des données. Ces outils constituent les
piliers du système décisionnel sur lesquels l’utilisateur s’appuie afin de prendre les décisions.

Comme solution de restitution des données, nous pouvons mentionner :

90
  Le reporting

Le reporting appartient à la famille des outils de Business Intelligence, dédié à élaborer, publier
et diffuser les rapports d’activité de l’entreprise selon un format prédéterminé. C'est une sorte
de présentation périodique et continue des bilans analytiques et des rapports dont le sujet est les
activités et les résultats de l’organisation, d'une unité de travail ou du responsable d'un
département ou d’une fonction. L’objectif du reporting est en informer les chargés de contrôle
et de supervision en interne comme en externe, ou bien tout simplement ceux qui sont concernés
par ces activités ou ces résultats, on parle alors de dirigeants et décideurs. Le principe de l’outil
de reporting c’est qu’il assure une interrogation des bases de données en fonction des requêtes
SQL préalablement préparées au moment de la réalisation du modèle. Mieux encore, cet outil
propose des fonctions spécifiques telles que des présentations graphiques et des modules de
calculs à l’effet de concevoir des bilans et des comptes rendus pertinents et congrus.

 Le data mining

Le datamining est l’ensemble des outils permettant l’analyse et l’exploration des données d’une
base décisionnelle (Datawarehouse ou Datamart). Ces outils emploient des techniques
sophistiquées en vue de dégager et détecter des tendances et des corrélations des données ce
qui permet d’anticiper des tendances peu apercevables. Ce que l'on peut traduire par la
transformation des données en connaissances.

 Le tableau de bord (Dashboard)

Dans un cadre d’une démarche de progrès, le tableau de bord est assurément l’instrument de
mesure le plus performant, il facilite la conduite proactive d’une ou plusieurs activités. Le
Dashboard contribue à la réduction de l’incertitude et facilite la prise de risque jointe à toutes
sortes de décisions.

 Analyse OLAP

Le Datawarehouse permet de mettre en place des vues multidimensionnelles que l’on représente
sous la forme d’un cube de trois dimensions. Les systèmes OLAP (On-Line Analytical
Processing) disposent des technologies qui assurent le regroupement, la gestion, le traitement et la
présentation des données multidimensionnelles pour des fins analytiques partagées et
décisionnelles.

91
 Annexe B : Dictionnaire des données sources
 Table compte

Champ Description Type

NUM_CPT Numéro du compte (PK) NUMBER
DATE_OUV Date d’ouverture du compte DATE
DATE_CLO Date de clôture du compte DATE
CODGPE Code groupe (FK) NUMBER
COD_AGE Code agence (FK) NUMBER
ID_ENGAGEMENT Identifiant engagement (FK) NUMBER
ID_GARANTIE Identifiant garantie (FK) NUMBER
ID_PRODUIT Identifiant produit (FK) NUMBER

 Table client

Champ Description Type

BASIC Identifiant du client (PK) NUMBER
NOMCLT Nom client VARCHAR2
SEGMENT Le segment (type client) VARCHAR2
ID_ACT Identifiant activité (FK) NUMBER
NUM_CPT Numéro du compte (FK) NUMBER
ID_CLASSE Identifiant classe NUMBER

 Table engagements

Champ Description Type

ID_ENGAGEMENT Identifiant engagement (PK) NUMBER

MNTDEC Montant découvert NUMBER

92
ESCCOM Escompte commercial NUMBER
PREFEXP Préfinancement export NUMBER
MCNUDTU Mobilisation de créances nées NUMBER
sur l’étranger en DTU
MCNEDEV Mobilisation de créances nées NUMBER
sur l’étranger en devises
AUTCRDCT Autre crédit court terme NUMBER
EXPORDTU Export en dinars tunisien NUMBER
AUTCRDMT Autre crédit moyen terme NUMBER
CRDMTRES Crédit moyen terme NUMBER
CRDLTORD Crédit long terme ordinaire NUMBER
ENCCONSP Encours consolidation principale NUMBER
ENGFINEX Engagements financiers NUMBER
extérieurs
OUVCREDO Crédits documentaire NUMBER
AVALBTRE Aval NUMBER
OBLICAUT Obligation cautionnée NUMBER
AUTENGSI Autre engagement NUMBER
CTX Total contentieux NUMBER
IMPPRINC Impayées principales (total) NUMBER
IMPINTER Impayées intérêt NUMBER
TOT_ENG_AC Total engagements année NUMBER
courante
TOT_ENG_AC_Rev Total engagements année NUMBER
courante revenu
TOT_ENG_AP Total engagement année NUMBER
précédente
MOIS Mois DATE
ANNEE Année DATE

 Table Activité

93
 Champ Description Type
ID_ACT Identifiant activité (PK) NUMBER
DESC_SECT_ACT Description secteur activité VARCHAR (50)
 Table garantie

Champ Description Type

ID_GARANTIE Identifiant (PK) NUMBER
GARETAT Garantie état NUMBER
GARBQE Garantie bancaire NUMBER
GARFINAN Garantie financière NUMBER
DEPAFFEC Dépôt affecté NUMBER
HYPUSIN Hypothèque usine NUMBER
HYPTERAI Hypothèque terrain NUMBER
HYPVILLA Hypothèque villa NUMBER
HYPNAVIR Hypothèque navire NUMBER
NANMATR Nantissement matériel NUMBER
NANTFCOM Nantissement fonds de NUMBER
commerce
CAUTSOLI Caution solidaire NUMBER
AUTGARRE Autre garantie réelle NUMBER
GAR_REELLE Garantie réelle NUMBER
DATE_SAISI Date de saisie DATE
DATE_MODIF Date modification DATE
OBSERVATION_GARA Observation garantie VARCHAR2
MOIS Mois DATE
ANNEE Année DATE

 Table produits

Champ Description Type

ID_PRODUIT Identifiant produit (PK) NUMBER
INTERETS_DEBITEURS Intérêts débiteurs NUMBER

94
PDT_LENDING_H_NET Produits lending hors net NUMBER
_DESCOMPTE d’escompte
PDT_LENDING_NET_D Produits lending net NUMBER
ESCOMPTE d’escompte
INT_SUR_CPTES_PERS Intérêts sur comptes personnels NUMBER
ONNELS_ATB ATB
INT_DE_RETARD_LEN Intérêts de retard lending NUMBER
DING
INT_DE_RETARD_MAN Intérêts de retard manuel NUMBER
UEL
INT_PTF_ESCOMPTE_C Intérêts ptf escompte NUMBER
OMMER commercial
INT_RETARD_PTF_ESC Intérêts de retard ptf escompte NUMBER
OMPTE_COMM commercial
AGIOS_DEBITEURS Les agios des débiteurs NUMBER
COMM_SUR_OPERATI Commission sur opération par NUMBER
ON_CHEQ chèque
COMM_SUR_OPERATI Commission sur opération NUMBER
ON_EFFETS effets
INT_SUR_FINANCEME Intérêts sur financements en NUMBER
NTS_DEVISES devises
INT_SUR_BONS_DE_C Intérêts sur bons de caisses NUMBER
AISSES_AVANCEE avancées
COMMISIONS_EXIMBI Commissions eximbils NUMBER
LS
COMM_SUR_CREDIT Commission sur crédit NUMBER
COMM_SUR_VIR_PREL Commission sur NUMBER
EV virement/prélèvement
COMM_MONETIQUE Commission monétique NUMBER
AUTRES_COMMISSION Autres commissions NUMBER
S
MOIS Mois DATE
ANNEE Année DATE

95
  Table agence

Champ Description Type

COD_AGE Code agence (PK) NUMBER
LIB_AGE Libellé agence VARCHAR
ADR_AGE Adresse de l’agence VRACHAR

 Table groupe

Champ Description Type

CODGPE Code groupe (PK) NUMBER
LIB_GRE Libellé groupe VARCHAR

 Table classe

Champ Description Type

ID_CLASSE Code groupe (PK) NUMBER
CLASSE_GEL Classe gèle NUMBER
CLASSE_IMPAYES Classe impayés NUMBER
CLASSE_CONSOLIDATION Classe consolidation NUMBER
CLASSE _CONTENTIEUX Classe contentieux NUMBER
CLASSE_MAX Classe total NUMBER
MOIS Mois DATE
ANNEE Année DATE

96
 Webographie et Bibliographie

[1] Site officiel de l’ATB, http://www.atb.tn/ visité le 01/02/2018.

[2] Site Wikipédia, https://fr.wikipedia.org/wiki/Arab_Tunisian_Bank visité le 01/02/2018

[3] Document de référence « ATB 2017 », page 83, http://www.atb.tn/doc/ATB-Doc-ref-

2017.pdf visité le 01/02/2018.

[4] Veronique Messager Rota, Gestion de projet vers les méthodes agiles, Edition Eyrolles,
2008. Visité le 03/02/2018. Visité le 03/02/2018.

[5] Site kyu.fr, http://www.kyu.fr/publication/services-embarques-a-la-recherche-dun-modele-

de-developpement-performant/ visité lé 03/02/2018.

[6] Veronique Messager Rota, Gestion de projet agile avec Scrum, Lean, eXtreme
Programming..., Edition Eyrolles 2013. Visité le 03/02/2018.

[7] Site access-dev.com, http://www.access-dev.com/access-dev/la-gestion-de-projet-

methodes-classiques-vs-methodes-agiles/. Visité le 03/02/2018.

[8] Ralph Kimball, Concevoir et Déployer un DataWarehouse, Edition Eyrolles, 2000,

https://www.eyrolles.com/Chapitres/9782212116007/chap02.pdf. Visité le 04/02/2018.

[9] Le Guide de Référence de Scrum : Les Règles de Jeu, Ken Schwaber et Jeff Sutherland,
Novembre 2017, https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-
French.pdf. Visité le 03/02/2018.

[10] Site de l’Institut d'électronique et d'informatique Gaspard-Monge (IGM), Les rôles de la

méthodologie SCRUM, http://igm.univ-mlv.fr/~dr/XPOSE2008/SCRUM/roles.php. Visité le
05/02/2018.

[11] Site de l’Institut d'électronique et d'informatique Gaspard-Monge (IGM), Les artéfacts de

la méthodologie SCRUM, http://igm.univ-mlv.fr/~dr/XPOSE2008/SCRUM/artefacts.php.
Visité le 05/02/2018.

[12] Site blog.myagilepartner.fr, SCRUM : Les premiers Pas,

https://blog.myagilepartner.fr/index.php/2017/11/29/le-scrum-les-premiers-pas/. Visité le
05/02/2018

97
[13] Site ComputerWeekly.com, Inmon or Kimball : Which approach is suitable for your data
warehouse ? https://www.computerweekly.com/tip/Inmon-or-Kimball-Which-approach-is-
suitable-for-your-data-warehouse. Visité le 07/02/2018.

[14] Site Data Warehousing Wiki (DWH), http://en.dwhwiki.info/best_practices/bottom_up.

Visité le 07/02/2018.

[15] Site Développez.com Club de développeurs et IT pro, starschema vs snowflake,

https://blog.developpez.com/jmalkovich/p8718/modelisation/modele_en_etoile_ou_en_flocon
s. Visité le 10/02/2018.

[16] Bernard ESPINASSE, Systèmes OLAP : ROLAP, MOLAP et HOLAP, Décembre 2015,
http://www.lsis.org/espinasseb/Supports/DWDM/5-SystemesOLAP-4p.pdf. Visité le
10/02/2018.

[17] Site Expert-only.com, Cubes ROLAP, MOLAP, HOLAP et bases de données

multidimensionnelles, https://expert-only.com/concepts/cubes-rolap-molap-holap-bases-de-
donnees-multidimensionnelles/. Visité le 10/02/2018.

[18] Site officiel de PostgreSQL, https://www.postgresql.org/. Visité le 12/02/2018.

[19] Guide Microsoft Ignite 2017 conference coverage,

https://searchsqlserver.techtarget.com/definition/SQL-Server. Visité le 12/02/2018.

[20] Frédéric Brouard, Comparaison des performances de PostGreSQL vs SQL Server,

https://g-ernaelsten.developpez.com/tutoriels/comparatif-sig-et-performances/. Visité le
12/02/2018.

[21] DB-Engines est une liste de SGBD classés selon leurs popularités mise à jour chaque mois,
elle est maintenue par la société autrichienne de conseil en informatique « solid IT », https://db-
engines.com/en/ranking. Visité le 15/02/2018.

[22] Site officiel de Talend, https://fr.talend.com/. Visité le 18/02/2018.

[23] Site officiel de Pentaho, http://www.pentaho.com/fr. Visité le 18/02/2018.

[24] Site officiel Microsoft, Documentation SQL Server Integration Services,

https://docs.microsoft.com/en-us/sql/integration-services/sql-server-integration-
services?view=sql-server-2017. Visité le 20/02/2018.

98
[25] Site itcentralstation.co, Plateforme communautaire de partage de revues des produits
https://www.itcentralstation.com/products/comparisons/ssis_vs_talend-open-studio. Visité le
22/02/2018.

[26] Site officiel IBM, IBM Cognos Analytics 11.0 documentation,

https://www.ibm.com/support/knowledgecenter/fr/SSEP7J_11.0.0/com.ibm.swg.ba.cognos.wi
g_cr.doc/c_gtstd_ica_overview.html. Visité le 24/02/2018.

[27] Site officiel Microsoft, Documentation SQL Server Reporting Services,

https://docs.microsoft.com/en-us/sql/reporting-services/create-deploy-and-manage-mobile-
and-paginated-reports?view=sql-server-2017. Visité le 24/02/2018.

[28] Site decisionnel-open-source.smile.fr, Les composants décisionnels/BIRT,

http://decisionnel-open-source.smile.fr/Les-composants-decisionnels/Birt. Visité le
25/02/2018.

[29] Help de QlikView, https://help.qlik.com/fr-FR/qlikview/November2017/Content/what-

is.htm Visité le 25/02/2018.

[30] Analyse comparative entre différents outils de BI (Business Intelligence),

https://entrepotdedonnee.files.wordpress.com/2015/03/comparaison-entre-les-trois-meilleurs-
outils-opensource-bi.pdf. Visité le 25/02/2018.

[31] Collecte des données : ETL Extract Transform load, Alain Fernandez
https://www.piloter.org/business-intelligence/ETL.htm. Visité le 14/03/2018.

[32] Site officiel Microsoft, Documentation en ligne de SQL Server 2014, Integration Services
(SSIS) Packages, https://docs.microsoft.com/en-us/sql/integration-services/integration-
services-ssis-packages?view=sql-server-2017. Visité le 17/03/2018.

[33] Site officiel Microsoft, Documentation en ligne de SQL Server 2014, Integration Services,
Execute SQL Task, https://docs.microsoft.com/en-us/sql/integration-services/control-
flow/execute-sql-task?view=sql-server-2017. Visité le 17/03/2018.

[34] Site officiel Microsoft, Documentation en ligne de SQL Server 2014, Integration Services,
Data Flow transformation, Merge Join transformation, https://docs.microsoft.com/en-
us/sql/integration-services/data-flow/transformations/merge-join-transformation?view=sql-
server-2017. Visité le 20/03/2018.

99
[35] Site officiel Microsoft, Documentation en ligne de SQL Server 2014, Integration Services,
Data Flow transformation, transformation de colonnes dérivées https://docs.microsoft.com/en-
us/sql/integration-services/data-flow/transformations/derived-column
transformation?view=sql-server-2017. Visité le 22/03/2018.

[36] Site officiel Microsoft, Documentation What is SSRS ?, https://docs.microsoft.com/en-

us/sql/reporting-services/create-deploy-and-manage-mobile-and-paginated-reports?view=sql-
server-2017. Visité le 25/03/2018.

[37] Site officiel Microsoft, Report Data (SSRS), https://docs.microsoft.com/en-

us/sql/reporting-services/report-data/report-data-ssrs?view=sql-server-2017. Visité le
27/03/2018.

[38] Jean-Claude Juhel, Gestion optimale de la trésorerie des entreprises, 2010,

https://tel.archives-ouvertes.fr/tel-00477041/document. Visité le 02/04/2018.

[39] Site Dilem.com, http://deplim.com/architecture-3-tiers.html. Visité le 15/04/2018.

[40] Site journaldunet.com https://www.journaldunet.com/solutions/intranet-

extranet/business-intelligence/ Visité le 02/02/2018.

[41] business-intelligence.developpez.com Visité le 02/02/2018.

[42] https://www.piloter.org/business-intelligence/datawarehouse.htm Visité le 02/02/2018.

10
0