Ministère de l’Enseignement Supérieur Et de la

Recherche Scientifique

Rapport de Projet de fin d’études

Filière : Génie Informatique

Réalisé par :
Sehli Semia
Encadré par :
Encadrant académique : Mr Imed Ben Boukhatem
Encadrant professionnel : Mr Yassine Flija

Sujet : Développement d’une solution décisionnelle de

suivi de l’activité clientèle de la Société Tunisienne de
Banque.

Année Universitaire : 2023/2024

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 diri-
geants se trouvent confrontés à une problématique de taille : Comment étudier toutes ces infor-
mations 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.

Afin de 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 finale-
ment la restitution. 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.

L’alliance entre la Business Intelligence et le développement logiciel crée un environ-

nement propice à l’innovation et à la transformation numérique. Grâce à cette convergence,
les entreprises peuvent concevoir des systèmes d’information intégrés qui utilisent de manière
efficace les données afin de produire des informations utiles.

C’est dans ce contexte que s’insère notre projet intitulé ≪ Développement d’une solution
décisionnelle de suivi de l’activité clientèle dans la STB ≫ qui a comme objectif de mettre en
place une solution décisionnelle automatisée pour la STB ainsi que la génération d’un modèle
de prédiction et le développement d’une plateforme Web pour la restitution de l’ensemble des
tableaux de bord.

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, du cadre du projet, la problématique, la solution envisagée et nous
finirons par la description de la méthodologie adoptée.

• Le deuxième chapitre intitulé ≪ Concepts fondamentaux et outils décisionnels ≫ présente

les concepts fondamentaux de la BI et du machine learning, ainsi qu’une étude compa-
rative des approches de conception du Data Warehouse. Puis, nous nous intéressons aux
outils et logiciels que nous avons utilisé après une étude comparative détaillée de plusieurs
exemples.

• Le troisième chapitre intitulé ≪ Phase de préparation ≫ présentera l’analyse des be-

soins fonctionnels et non fonctionnels, la planification du projet ainsi que la conception et

1
 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 ≪SPRINT 1 : Intégration des données et développement

ETL ≫ vise à la conception de l’entrepôt de données et le développement du processus ETL.

• Le cinquième chapitre qui s’intitule ≪ Sprint 2 : Restitution de données et prédiction≫ qui

assurera l’élaboration des tableaux de bord et la génération du modèle de prédiction.

• Le sixième chapitre qui s’intitule ≪ Sprint 3 : Développement de la plateforme web≫ qui

présentera l’architecture logicielle de la solution et sa réalisation.

En guise de conclusion, nous allons présenter le fruit de notre travail ainsi que nos perspectives.

2
Chapitre 1 :

Contexte général

1.1 Introduction :
Dans ce chapitre nous allons présenter brièvement le cadre du projet, l’historique de l’orga-
nisme d’accueil et son organisation. Nous poursuivrons par la suite avec une étude de l’exis-
tant en présentant une analyse critique suivie d’une solution pour prévenir ces problèmes
la problématique avec une étude de l’existant. À la fin de ce chapitre, nous aborderons la
méthodologie choisie ainsi que la planification prévisionnelle du projet.

1.2 Cadre du projet :

Ce travail s’inscrit dans le cadre de la préparation d’un projet de fin d’études afin d’obtenir
le Diplôme National d’ingénieur en Informatique. Ce projet dont la durée est de quatre mois,
est réalisé au sein de la Société Tunisienne des Banques. Il vise à y mettre en place une solution
décisionnelle pour la direction du service commercial en fournissant des tableaux de bord pour
suivre l’activité liée aux indicateurs d’activité des deux produits : Comptes et Crédits, qui
seront par la suite implémentés dans une application Web.

1.3 Présentation de l’organisme d’accueil :

1.3.1 Présentation générale :
La Société Tunisienne de Banque (STB), fondée le 26 mars 1958, est le premier établissement
bancaire tunisien créé après l’indépendance pour soutenir le développement économique et social
du pays. Avec une participation majoritaire de l’État, la STB a constamment évolué, augmen-
tant son capital à plusieurs reprises et jouant un rôle clé dans divers secteurs économiques. Elle
a développé une stratégie commerciale innovante, introduisant des technologies modernes et
diversifiant ses services pour répondre aux besoins de sa clientèle. La STB a également établi
des relations internationales solides, soutenant des projets à l’échelle globale.

Figure 1.1 – Logo de la STB

3
1.3.2 Historique :
La Société Tunisienne des banques est une banque tunisienne fondée le 18 Janvier 1957,
entrée en activité le 26 Mars 1958. Il s’agit d’une société anonyme relative aux établissements
de crédits et dont le capital s’élève à 776.875 millions de dinars tunisien dont l’Etat tunisien
détient 81.83% d’une façon directe ou indirecte. La STB a pour mission essentielle de contribuer
au développement économique social du pays et de promouvoir les entreprises dans les diverses
activités économiques.
Cette dernière dispose un réseau assez dense en Tunisie avec un nombre important d’agences
égal à 149 agences réparties sur tout le pays.
En outre elle dispose d’environ 300 filiales et participations dont une cinquantaine d’importance.
Parmi celles-ci, la Tunisian Foreign Bank à Paris et Marseille, et la Banque franco-tunisienne
a fait l’objet d’un appel d’offres en vue de sa cession.
La STB détient par ailleurs 25% de la Société nigérienne de banque, implantée au Niger et au
Bénin.
En 2019 elle était désigné comme la meilleure banque digitale en Afrique du Nord et en décembre
de la meme année elle devient la première banque Swift GPI (Global Payment Innovation) en
Afrique du Nord

1.3.3 Fiche d’identité de la STB :

Comme tout établissement, la STB possède une fiche signalétique, décrite par cette table :

Raison social Société Tunisienne de Banque

Date de constitution 18 janvier 1957
Fondateur Abdelaziz Mathari
Forme juridique Société anonyme
Direction Znati Jouini Lassaad
Capital 776.875.000 millions de dinars tunisiens
Nombre d’agences 149
Nombre de filiales 300
Siège social Rue Hédi Nouira - 1001 Tunis - Tunisie
Téléphone 216 70 140 000
Site web [Link]
Matricule fiscale 001237/A/P/M/000

Table 1.1 – Fiche d’identité de la STB

1.3.4 Mission de la STB :

La mission de la Société Tunisienne de Banque (STB) est de contribuer activement au
développement économique et social de la Tunisie en offrant des services bancaires innovants
et adaptés aux besoins de sa clientèle. En tant que pionnière dans le secteur bancaire tunisien,
la STB s’engage à soutenir les projets d’investissement, à promouvoir l’épargne nationale, et à
faciliter l’accès au crédit pour divers secteurs économiques, incluant l’industrie, le tourisme, et
l’agriculture. Parallèlement, la STB vise à renforcer ses relations internationales et à intégrer

4
les technologies modernes pour améliorer la qualité de ses prestations, tout en favorisant la
formation et le développement professionnel de son personnel pour maintenir un service de
haute qualité.

1.3.5 Organigramme :
Nous modélisons l’organisation de la banque par l’organigramme ci-dessous :

Figure 1.2 – Organigramme de la STB

1.4 Analyse de l’existant :

1.4.1 Étude de l’existant :
Avant d’entamer tout projet, il est primordial de commencer par étudier de manière ap-
profondie l’état actuel du système existant. Grâce à cette analyse, il est possible de saisir le
cadre de fonctionnement et les processus métier en jeu, ce qui constitue la première étape de
l’analyse d’un projet. La définition des objectifs du projet, la compréhension des besoins des

5
parties prenantes et la rédaction d’une brève description du projet sont essentiels.
L’activité clientèle de la STB est diversifiée, couvrant une large gamme de services financiers
pour particuliers, professionnels, et entreprises. Dans cette étude, nous nous concentrerons
spécifiquement sur l’analyse des segments de clientèle et des crédits octroyés.

1.4.2 Critique de l’existant :

La banque dispose d’une base de données centrale mais l’organisation et la structuration
efficace des informations sont difficiles en raison de la diversité des sources de données. L’analyse
des étapes de collecte et du traitement des données relatives à l’activité des comptes et des
crédits dans la STB révèle des lacunes majeures qui restreignent considérablement la tâche
d’analyse et de suivi pour les dirigeants de la banque.

1.4.3 Problématique :
La solution employée aborde chaque module individuellement. Effectivement, les données
relatives aux clients et aux crédits sont enregistrées dans diverses bases de données. Après avoir
mené une analyse détaillée, on constate que cette solution était appropriée et répondait aux
exigences des responsables concernant le suivi des engagements des clients. Toutefois, au cours
des dernières années, la banque a constaté une croissance significative du nombre de clientèle,
ce qui a entraı̂né une augmentation du volume des données à traiter et l’enrichissement du
système d’information de la banque. Cela a entraı̂né l’inefficacité de cette solution face à ces
modifications. nous parlons alors de :
• Un mauvais partage de l’information
• Un manque de flexibilité
• Un temps de traitement très lent

Dans cette solution, les bases de données relationnelles sont définies comme un ensemble
d’éléments de données qui ont une relation préétablie entre eux. Les informations erronées
et manquantes dans ce répertoire peuvent ne pas répondre aux attentes des décideurs, qui ont
besoin d’informations pertinentes et fiables pour prendre des décisions éclairées. Il est donc es-
sentiel de choisir une structure de données plus appropriée pour faciliter l’analyse des données
à des fins de prise de décision. Les décideurs font face à des difficultés liées à :
• L’impossibilité d’accéder aux informations à distance et de la représentation des données
historiques.
• La difficulté à prendre des décisions éclairées à cause de l’utilisation des données qui ne
sont pas préparées.
• La nécessité des Tableaux de bord plus dynamique, riche et entièrement personnalisés.

1.4.4 Solution envisagée :

Après avoir étudié le processus de la prise de décision de la STB, il s’est avéré qu’il est
nécessaire de mettre en place une solution décisionnelle qui offre aux décideurs de la banque, à
travers des tableaux de bord, une visibilité globale sur l’activité clientèle.
Nous allons découper notre projet en deux grandes parties :
• L’intégration, l’analyse des données et la prévision : Cette procédure implique de collecter
et de traiter les données pour les regrouper dans notre entrepôt de données. Par la suite,
nous créons des tableaux de bord semi-temps réel en exploitant ces données centralisées
afin de déterminer les indicateurs de performance associés à l’activité clientèle de la banque
.Ensuite, ces informations sont utilisées pour analyser et prédire les données à venir.
• Le développement d’une plateforme web sécurisée pour restituer l’ensemble des tableaux
de bord, permettre une visualisation efficace, et faciliter l’accès à l’information tout en
offrant une expérience utilisateur conviviale et intuitive.

6
1.5 Méthode de gestion de projet :
L’objectif de la gestion de projet est de garantir la coordination entre les différents acteurs
et les tâches. Avant de débuter la mise en œuvre de notre projet, nous allons d’abord examiner
et évaluer la méthode de gestion de projet à adopter. Afin de mener à bien un projet décisionnel
dans les délais impartis en répondant précisément aux exigences du client, il est essentiel de
choisir la méthode la plus appropriée pour notre projet. Différentes approches de gestion de
projet sont couramment utilisées aujourd’hui, c’est pourquoi nous allons effectuer une étude qui
a pour but le dégagement d’une fiche comparative afin de choisir la méthode la plus appropriée
pour notre projet.

1.5.1 Étude des approches prédictives classiques :

Depuis des décades, la gestion des projets a souvent suivi une approche traditionnelle, le
plus fréquemment ”en cascade” ou son adaptation ”en V”.
Cette approche repose sur l’exécution séquentielle des activités : d’abord la collecte des besoins,
puis la définition du produit, son développement, les tests et enfin la livraison au client. Ces
méthodologies se distinguent par leur insistance à planifier minutieusement chaque aspect du
projet dès son commencement, avec pour objectif que tout soit anticipé. C’est pourquoi elles
sont souvent désignées comme des approches ”prédictives”.
Les limites de la méthode en cascade :
- La rigidité : à cause de sa structure linéaire (le retour en arrière perturbe l’ensemble de
projet).
- Les risques ne sont détectés qu’à la phase de test après avoir compléter la phase de
développement.
- L’effet Tunnel : Sur de gros projets, cette approche peut entraı̂ner d’importants retards
avant de pouvoir présenter quelques choses aux utilisateurs.

Cependant, parmi les approches classiques, l’approche Cycle en V est la plus utilisée lorsqu’il
s’agit d’un projet décisionnel.
D’où la figure ci-dessous présente les différentes phases de l’approche de cycle en V :

Figure 1.3 – Cycle en V

Finalement on peut conclure que : le modèle en V partage des similitudes avec la méthode en
cascade, mais il présente néanmoins des distinctions importantes. Contrairement à la méthode
en cascade, le modèle en V autorise la rétroaction vers les étapes précédentes. Même après
validation d’une étape, il est possible de revenir en arrière dans le cycle en V.

7
1.5.2 Approches AGILES :
”Une approche 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.”
Cette approche consiste en un ensemble de techniques conçues spécifiquement pour la gestion
efficace des projets informatiques. Ce qui distingue la méthode agile, c’est son utilisation d’un
processus de développement itératif.
L’objectif lors de l’application de cette approche est d’injecter de la flexibilité et d’optimiser les
performances dans la gestion de projet. Centrée sur l’humain et la communication, l’implication
du client dans la réalisation du début à la fin du projet permet à l’équipe d’obtenir un feedback
régulier afin d’appliquer directement les changements nécessaires.

Après avoir étudié chaque approche, nous dévoilons les principales différences entre les ap-
proches classiques et les approches AGILE dans le tableau comparatif proposé ci-dessous :

Approche AGILE Classique

Planification Adaptative Prédictive
Cycle de vie Itératif et incrémental Séquentiel
Objectif Satisfaction du client Respect des engagements et
des besoins initiaux
Documentation Résumée au strict Importante, exhaustive et
nécessaire au profit des détaillée présentée sous
fonctionnalités forme d’un support de
opérationnelles afin de communication et de
recevoir les retours des validation
clients
Équipe Travail en synergie d’où Une équipe composée de
l’équipe est soutenue par un ressources spécialisées
chef de projet où la dirigée par un chef de
communication et projet, donc chacun à sa
l’initiative sont les piliers tache
du travail
Livraison de la Fractionnée et incrémentale Tardive
solution
Intervention du Communication permanente Presque inexistante, peu
client lors de la réalisation de la d’interaction, le client
solution avec proposition de attend la livraison finale du
changements si souhaité produit pour le tester
Table 1.2: Tableau comparatif AGILE VS Classiques

Suite à cette étude comparative, nous avons décidé d’adopter l’approche AGILE.
Les techniques AGILES sont basées sur l’itération et la participation. La clé de notre décision
réside dans la nature de ce processus. L’utilisation de l’agilité dans un projet de prise de
décision favorisera une implication accrue du client et garantira la valeur professionnelle pour
l’entreprise.

8
1.5.3 Méthode SCRUM vs Méthode GIMSI :
Après avoir adopter l’approche AGILE, il nous reste encore à choisir la méthode de gestion
la plus adaptée à notre projet. Cependant nous allons faire un comparatif entre SCRUM qui est
considérée comme la méthode la plus utilisée, et GIMSI une méthode qui combine les principes
de la gestion de projet traditionnelle avec les méthodes agiles.

Méthode SCRUM GIMSI

Planification Au début de chaque sprint Flux continu

Estimation Au début de chaque sprint Optionnel, prédictibilité

d’effort
Changement de Doit atteindre le sprint Selon le besoin
périmètre suivant

Rôles Scrum Master Chef de projet

principaux Product Owner Équipe projet
équipe de développement Parties prenantes
Livraison de la Fractionnée et incrémentale Tardive
solution
Top 3 bénéfices Productivité Combinaison des meilleures
Scalabilité pratiques
Meilleure collaboration et Pilotage visuel
communication Mise en place rapide
Table 1.3: Tableau comparatif entre SCRUM et GIMSI

Généralement, même si les deux méthodes sont différentes, elles ne s’opposent pas réellement.
Suite à cette étude comparative, nous avons choisi de suivre la méthode SCRUM.

1.5.4 Choix de la méthode SCRUM :

La méthode SCRUM est basée sur les recherches menées par Sutherland et Schwaber, et
appartient à la famille des méthodes incrémentales et itératives.
Cette méthode est utilisée pour développer, livrer et maintenir des produits complexes. Elle est
apte principalement pour la mise à exécution des projets software. Cependant, elle peut aussi
être utilisée pour tout autre type de projet, du plus basique au plus innovant. En effet, dans
la méthode Scrum, le client joue un rôle plus actif dans le suivi de l’avancement du projet et
l’approbation de divers livrables. Il peut donc surveiller régulièrement l’avancement des travaux,
ce qui facilitera la modification d’un élément ou l’insatisfaction pour répondre à ses besoins.
Scrum adopte une méthode itérative et incrémentale afin d’améliorer la prédictibilité et la
gestion des risques. Elle repose sur trois piliers :
• Transparence : Nous savons tous ce qui ce passe.
• Adaptation : Nous sommes tous d’accord de changer de direction tactique.
• Inspection : Nous vérifions le travail tout en le faisant.
Cette dernière est fondée ainsi sur cinq valeurs principales qui se résument en un seul mot
FORCE : F : Focus O : Ouverture R : Respect C : Courage E : Engagement

9
[Link] Les intervenants dans SCRUM :
Une équipe SCRUM (Scrum Team) comprend un Product Owner (PO), une équipe de
développement (Development Team) et un Scrum Master (SM). Ces équipes sont auto-organisées
et choisissent la meilleur manière de réaliser leur travail plutôt que d’être dirigées par des indi-
vidus externes à l’équipe.
Nous présentons les valeurs principales d’une équipe Scrum :
- Pas de hiérarchie
- Pluridisciplinaire
- Une seule unité
- Même objectif
Nous avons mentionné au début de ce paragraphe les 3 principaux rôles clés différent proposés
par la méthode SCRUM :
• Le Product Owner : Représente à la fois les clients et les utilisateurs. C’est le porte-
parole des clients chargé de gérer efficacement le Backlog produit qui permet de collecter
les besoins du client, les spécifications du produit ainsi que toutes les fonctionnalités du
projet à accomplir. Il incombe également au propriétaire du produit de classer les éléments
du Backlog en fonction de leur priorité et d’indiquer l’ordre de leur réalisation.

• Le Scrum Master : Joue le rôle d’un animateur de l’équipe et représente le manage-

ment du projet. Il n’est pas considéré comme un chef mais plutôt comme un coordinateur
facilitateur qui assure le bon déroulement du projet. Il est responsable de la mise en place
de Scrum et de l’efficacité de la Scrum Team.

• Le Scrum Team : C’est une équipe de développement pluridisciplinaire composée de

5 à 10 individus responsable de fournir les éléments de chaque sprint en fonction de leurs
ordres de priorité. L’importance de l’échange est essentielle lors de l’utilisation de SCRUM
puisque le groupe est constitué d’architectes, de développeurs et d’administrateurs de base
de données, ce dernier est bien organisé et reste inchangé tout le long d’un sprint.

[Link] Les artefacts de SCRUM :

Les artefacts Scrum sont élaborés afin d’optimiser la clarté des informations essentielles pour
que chacun puisse les comprendre de manière équitable. Les artefacts Scrum sont :

• Backlog Produit :
Au commencement du développement d’un produit agile, il sera nécessaire de diviser le
produit minimum viable en petites fonctionnalités ou tâches à effectuer afin de faciliter sa
création. Grâce à cette planification, l’équipe pourra avoir une vision claire du produit et
de son but. On organisera ces tâches prédécoupées dans ce qu’on nomme le backlog pro-
duit. Il s’agit d’une sorte de réservoir qui regroupe toutes les caractéristiques du produit.
Il est essentiel d’organiser les tâches de manière rationnelle en fonction de la priorité dans
laquelle elles doivent être effectuées.

• Backlog de Sprint :
Comme mentionné ci-dessus, le cadre méthodologique Scrum subdivise le planning d’une
équipe en cycles fréquents. Il existe plusieurs tâches prédécoupées qui sont incluses dans
ces divers cycles. À la fin de chaque cycle, il est essentiel que le travail réalisé génère de
la valeur pour le produit en cours de développement. On désigne ces cycles comme des

10
 ”sprints”, la date de début et la date de fin sont fixées. La durée d’un sprint reste in-
changée. Selon le guide Scrum, il est recommandé de l’étendre à 2 ou 3 semaines.

• Sprint Burn-Down Chart :

Le graphique de progression offre une vision d’ensemble de l’évolution de la quantité de
travail restante par rapport au travail effectué. Le travail restant se trouve sur l’axe vertical,
le temps est illustré par l’axe horizontal. Ce genre de graphique offre la possibilité de
prévoir l’avancement du travail pendant une période donnée pour suivre le déroulement
de l’activité. montrons ci-dessous une figure récapitulative :

Figure 1.4 – Sprint Burndown chart

La figure ci-dessous représente un récapitulatif du processus SCRUM :

Figure 1.5 – Le processus de déroulement d’un projet SCRUM

11
1.5.5 L’approche SCRUM appliqué à un projet BI :
Lors de l’élaboration d’un projet BI, la solution SCRUM est appelée. Chaque sprint corres-
pond au cycle de vie complet du projet décisionnel, comprenant la phase d’analyse des besoins,
la phase de conception, la phase de réalisation et enfin la phase de test. Cette solution garantit
l’adaptation du projet à l’évolution des besoins de l’utilisateur de manière flexible.
De plus, dans notre situation, nous nous concentrons sur la création d’un entrepôt de données
qui constitue le cœur de la technologie BI. Ainsi, nous évoquons deux écoles de pensée concer-
nant la modélisation des données :
✓ L’approche TOP DOWN
✓ L’pproche BOTTOM UP.

[Link] L’approche d’Inmon ”Top Down” :

Selon Bill Inmon, un entrepôt de données est considéré comme un référentiel centralisé.
Les sociétés conservent les données au niveau le plus approfondi. La création d’un entrepôt de
données revêt une importance capitale dans un projet de prise de décision. La réalisation de ce
projet se déroule en plusieurs étapes. À partir du premier sprint, nous collectons les informa-
tions nécessaires pour concevoir l’entrepôt de données. D’après cette approche, il est possible
de déterminer le domaine sur lequel nous pouvons développer le datamart à des fins d’analyse
et de rapport dans les prochains sprints. Tout au long du processus de mise en œuvre comme
le montre la figure ci-dessous, l’équipe présente un exemple de travail en utilisant des données
réelles au Product Owner.

Figure 1.6 – Principe de L’approche TOP DOWN

[Link] L’approche de Kimball ”Bottom-Up” :

L’informaticien Ralph Kimball déclare dans son approche ”qu’il est possible de voir l’entrepôt
de données en tant qu’union de magasins de données, cohérents les uns avec les autres en
raison de dimensions conformes ”. Supposons que cette méthode s’applique à l’approche Scrum,
où nous nous concentrerons sur un processus commercial par sprint. Nous nous occupons de
toutes les étapes d’un projet de prise de décision (depuis le début de l’ETL jusqu’à la création
du rapport). Cette approche garantit des Sprints successifs. Il s’agit du même processus. La
complexité varie entièrement en fonction du sujet abordé, ce qui garantit aux utilisateurs des
résultats finaux satisfaisants. On peut observer ces étapes dans la figure ci-dessous.

12
 Figure 1.7 – Principe de L’approche BOTTOM UP

[Link] Choix de l’approche adaptée avec SCRUM :

En ce qui concerne notre solution, nous avons opté pour une approche de conception ≪ top-
down ≫ qui consiste à créer un référentiel centralisé, le DW, puis à charger les datamarts de
manière cohérente. Cette méthode est facile et solide lorsqu’il s’agit de charger les dimensions,
ainsi que lors de la mise en place des bases de données. De plus, elle est insensible et adaptable
aux exigences des clients qui changent pendant les étapes de mise en place.

1.6 Conclusion :
En lisant ce chapitre, nous avons pu acquérir une connaissance assez approfondie de l’ac-
tivité de la STB, en examinant l’état actuel des choses et en mettant en évidence ses limites.
Ensuite, nous avons proposé une solution qui répond aux besoins des décideurs de la banque.
En dernier lieu nous avons fait le choix de la méthodologies de travail de notre projet : SCRUM
par l’intermédiaire d’une étude comparative détaillée.
Dans le chapitre suivant, nous allons définir les concepts fondamentaux, ainsi que nous compa-
rerons les outils décisionnels afin de justifier nos choix.

13
Chapitre 2 :

Concepts fondamentaux
& Outils décisionnels

2.1 Introduction :
Après avoir exposer le contexte général de notre projet et choisir la méthode adoptée, dans
ce chapitre nous allons parler des concepts fondamentaux de la Business Intelligence et du
machine learning. Puis nous allons également faire le choix des outils informatiques que nous
allons utiliser. Ce chapitre sera alors consacré à la justification de nos choix en faisant recours
à une comparaison bien détaillée.

2.2 Concepts généraux de la BI :

2.2.1 Historique de l’informatique décisionnelle :
Depuis ses débuts dans les années 1960, la Business Intelligence (BI) a connu une évolution
majeure. Des systèmes de reporting simples et des systèmes de support à la décision ont été
mis au point à cette époque pour aider les gestionnaires à prendre des décisions basées sur les
données.
Dans les années 80, les bases de données relationnelles et les outils de requêtes ont été introduits
pour répondre aux besoins des utilisateurs de faire des analyses multidimensionnelles.
Les entrepôts de données, systèmes OLAP et les outils de reporting plus avancés ont été apparus
les années 90 ce qui a favorisé une meilleure utilisation des données de l’entreprise.
Les besoins d’analyse ne cessent d’évoluer et les technologies continuent à se progresser, ce qui
exige la naissance de la Business Intelligence en 1989 par l’informaticien Howard Dresner.

Figure 2.1 – Historique de l’information décisionnelle

14
2.2.2 Définition de l’informatique décisionnelle :
Un système d’information décisionnel est défini comme un regroupement de données orientées
vers des sujets spécifiques, intégrées, dépendantes du temps et non volatiles, dans le but d’aider
les gestionnaires dans leurs prises de décision.
En effet, les SIDs ont pour mission de soutenir la prise de décision et de fournir une vue
d’ensemble de l’activité d’une entreprise grâce aux tableaux de bord et aux outils de pilotage
qu’ils produisent.

2.2.3 Principes de l’informatique décisionnelle :

Les solutions de la Business Intelligence se basent sur plusieurs principes. Voici quelques-uns
des principes les plus importants :
- Les systèmes transactionnels ne sont pas adaptés.
- Comprendre et analyser les données stockées.
- Centraliser et normaliser les données.
- Prendre des décisions éclairées et plus informées.
- Aider les entreprises à identifier les incohérences et le gaspillage dans leurs processus, ce
qui peut entraı̂ner une diminution des coûts.
- Mesurer le résultat d’une prise de décision.
- Source unique d’information pour les décideurs
- Mettre à disposition des utilisateurs finaux des données facilement exploitables.

2.2.4 Objectifs de l’informatique décisionnelle :

La plupart des entreprises possèdent d’énormes quantités de données réparties dans des
bases de données et des systèmes transactionnels distribués. Ces bases de données et systèmes
sont généralement conçus pour des opérations spécifiques ou pour le traitement de données.
Cependant, ils ne sont pas conçus pour communiquer entre eux ou permettre aux utilisateurs
de consulter les données de manière non conventionnelle ou de réaliser des analyses de données
avancées à des moments précis. Les principaux objectifs de l’informatique décisionnelle sont
donc de combler cette lacune et de fournir de telles capacités :
- La possibilité de consulter en une seule vue des données provenant de diverses sources.
- Facilité d’obtention rapide d’analyses de données provenant de différents systèmes.
- Facilité d’examen des données réparties dans le temps.
- Facilité de génération de scénarios de simulation et d’obtention de réponses basées sur des
données historiques.
Une conception soigneusement étudiée et une mise en œuvre réussie d’une solution d’informa-
tique décisionnelle peuvent rapidement générer un retour sur investissement très intéressant.
C’est un facteur apprécié par les dirigeants d’entreprise, sans aucun doute.

2.2.5 L’architecture d’un système d’information décisionnel :

Tout système décisionnel est architecturé globalement de la même façon.

L’architecture est présentée par la chaı̂ne décisionnelle qui englobe toutes les étapes de
collecte et de transformation des données. Ce processus peut être divisé en plusieurs étapes :
• Phase d’alimentation : nommée également la phase de collecte concerne l’extraction,
la transformation et le chargement des données brutes issues de différentes source de sto-
ckage de l’information dans un entrepôt de données. Ils s’agit du processus ETL (Extract,
Transform, Load).

15
 Figure 2.2 – Architecture d’un système d’information décisionnel

• Phase de modélisation : ou la phase de stockage, consiste à centraliser les données

dans un DWH pour qu’elles soient disponibles pour une utilisation décisionnelle.
• Phase de restitution : Elle consiste à mettre les données à disposition à travers des
outils de reporting, des tableaux de bord, des outils de statistiques, etc., pour faciliter
l’analyse et la prise de décision.
• Phase d’analyse : Cette dernière étape a comme objectif d’assister au mieux l’utilisateur
afin qu’il puisse analyser les informations qui lui sont fournies et prendre des décisions.
Cela comprend le contrôle d’accès aux rapports, le soutient des requêtes et la visualisation
des résultats.

2.3 Théories d’entrepôt de données :

L’entrepôt de données est le lieu où les données sont stockées et centralisées grâce au pro-
cessus ETL. Il est organisé de manière à contenir une volumétrie importante de données qui
peuvent être analysées pour prendre des décisions plus informées.
Généralement, les informations stockées dans un DWH proviennent de systèmes transaction-
nels, de bases de données relationnelles et d’autres sources, et elles arrivent régulièrement.

2.3.1 Objectif d’un entrepôt de données :

Les entrepôts de données ont pour principale fonction de faciliter la prise de décision en
facilitant l’exploitation des informations provenant des systèmes opérationnels des entreprises.
- L’entrepôt de données doit faciliter l’accès aux données de l’organisation : le contenu
de l’entrepôt de données doit être compréhensible pour les utilisateurs ordinaires et non
seulement pour les développeurs.
- Il est essentiel que l’entrepôt de données présente de manière cohérente les informations de
l’organisation : les données de l’entrepôt doivent être regroupées à partir de diverses sources
de l’organisation, être nettoyées et vérifiées pour leur qualité. La cohérence nécessite une
qualité élevée, elle nécessite également que toutes les données soient complètes.
- L’entrepôt de données doit être adaptable et résistant aux changements : les modifica-
tions de l’entrepôt de données ne doivent pas compromettre les données existantes ou les
applications.
- L’entrepôt de données doit préserver notre trésor d’information : il est essentiel qu’il assure
un contrôle efficace de l’accès aux informations confidentielles de l’organisation.
- L’entrepôt de données doit être le socle sur lequel repose l’amélioration des prises de
décision : Il doit inclure les informations nécessaires pour soutenir les choix. En réalité,
elles constituent la plus grande valeur de l’entrepôt de données.

16
 - La réussite de l’entrepôt de données dépend de l’acceptation de la communauté des utili-
sateurs : l’acceptation des utilisateurs à l’entrepôt de données est principalement liée à sa
facilité d’utilisation.

2.3.2 Modélisation d’un entrepôt de données :

* Les composants d’un schéma décisionnel :
Les entrepôts de données ont pour objectif de mettre en œuvre des systèmes de prise de
décision. Les différents objectifs des systèmes transactionnels doivent être remplis par ces
systèmes, ce qui souligne l’importance de se tourner vers un modèle de données simplifié et
compréhensible : c’est la modélisation dimensionnelle.
Dans la modélisation dimensionnelle, chaque modèle est constitué d’une grande table centrale
et d’un ensemble de petites tables auxiliaires disposées autour de la table centrale.
Celle-ci est appelée table de faits et les autres tables sont les tables de dimensions.
- Table de faits : est la table centrale du modèle dimensionnel. Elle renferme les données
visibles (les mesures) concernant ce que nous souhaitons étudier. Chaque ligne de la table
correspond à une mesure. En général, ces mesures sont des valeurs numériques et additives.
Une table de faits garantit les liens plusieurs à plusieurs entre les dimensions. Les clés
étrangères qu’elles contiennent ne sont autres que les clés primaires des tables de dimension.
- Tables de dimensions : sont les tables qui raccompagnent une table de faits, elles
renferment les descriptions textuelles de l’activité. Chaque tables de dimension représente
un axe d’analyse.

* Modélisation logique des données :

Les tables de faits et les dimensions sont structurées en fonction d’un modèle de données
précis qui répond aux exigences de la modélisation dimensionnelle. Trois principaux modèles
de schémas sont utilisés, Chaque modèle possède ses propres particularités et bénéfices :
- Le modèle en étoile : Il s’agit d’une étoile dont le centre est la table des faits et les
branches sont les tables de dimension. La particularité de ce genre de modélisation réside
dans sa clarté et sa performance, mais elle pose des problèmes tels que la redondance et
l’intégrité des données.

Figure 2.3 – Schéma en étoile

- Le modèle en flocon de neige : Le modèle en flocon de neige est le même que le

modèle en étoile, à l’exception de la division de ses branches en hiérarchies. Ce modèle
simplifie la classification des tables de dimensions en plusieurs tables liées, ce qui diminue

17
 la répétition des données et prévient les pertes de mémoire. Cependant, il est plus lent lors
de l’interrogation en raison de l’augmentation du nombre de jointures.

Figure 2.4 – Schéma en flocon de neige

- Le modèle en constellation : Le modèle en constellation ou schéma galaxie est une

combinaison de plusieurs modèles en étoile. Il est composé de plusieurs tables de faits qui
partagent des dimensions similaires.

Figure 2.5 – Schéma en constellation

2.4 Concepts du Machine Learning :

2.4.1 Définition :
Le Machine Learning (ML), appelé également apprentissage automatique, est une sous-
discipline de l’intelligence artificielle (IA), permet aux systèmes de se perfectionner et d’acquérir
des compétences de manière autonome à partir de l’expérience, sans nécessiter une program-
mation explicite. Grâce à des algorithmes sophistiqués, ces systèmes identifient des motifs dans
les données, apprennent de ces motifs, et utilisent ces connaissances pour faire des prévisions
ou prendre des décisions éclairées.

18
2.4.2 Historique :
Le concept de Machine Learning trouve ses racines dans les années 1950 avec l’invention du
perceptron, une forme primitive de réseau de neurones. Au cours des décennies suivantes, le
domaine a progressé grâce à l’augmentation de la puissance de calcul et à l’accès à d’importantes
quantités de données, conduisant à des avancées telles que les réseaux de neurones profonds et
les systèmes d’apprentissage par renforcement.

2.4.3 Types de Machine Learning :

[Link] Apprentissage Supervisé :

L’apprentissage supervisé s’appuie sur un ensemble de données étiquetées pour former un

modèle. Par exemple, pour estimer le prix des maisons, un modèle peut être entraı̂né à partir
de données historiques où chaque maison est associée à un prix spécifique (étiquette). Parmi les
algorithmes couramment utilisés, on trouve la régression linéaire pour la prédiction de valeurs
continues et les forêts aléatoires pour la classification.

[Link] Apprentissage Non supervisé :

À la différence de l’apprentissage supervisé, l’apprentissage non supervisé ne requiert pas

d’étiquetage des données. Il vise à repérer des structures dissimulées dans les données. Par
exemple, l’utilisation du clustering permet de regrouper des clients similaires sans avoir conscience
préalable de ces groupes. Les algorithmes courants incluent le K-means et l’analyse en compo-
santes principales (PCA).

[Link] Apprentissage semi-supervisé et par renforcement :

L’apprentissage semi-supervisé combine des données étiquetées et non étiquetées pour ac-
croı̂tre la précision des modèles. En revanche, l’apprentissage par renforcement consiste en un
agent qui apprend à prendre des décisions en interagissant avec son environnement, recevant
des récompenses ou des punitions selon ses actions.

2.4.4 Concepts et Terminologie Clés :

[Link] Caractéristiques et Étiquettes :

Les caractéristiques, ou features, sont les variables d’entrée utilisées pour effectuer des
prédictions.
Les étiquettes, ou labels, sont les valeurs de sortie que le modèle doit prédire.

[Link] Modèles et Algorithmes :

Un modèle de Machine Learning est une représentation mathématique des données, construite
à l’aide d’un algorithme.
Parmi les algorithmes courants, on trouve la régression linéaire pour des relations linéaires,
les arbres de décision pour des relations non linéaires, et les réseaux de neurones pour
des données complexes et non structurées.

[Link] Entraı̂nement et évaluation :

L’entraı̂nement d’un modèle implique de le former à partir de données d’entraı̂nement, tandis

que l’évaluation consiste à tester le modèle sur un ensemble de données distinct afin de mesurer
sa performance et sa capacité à généraliser à de nouvelles données.

19
2.4.5 Métriques de performances :
[Link] Précision, Rappel, F1-score :

Ces métriques sont souvent utilisées pour évaluer les performances des modèles de classifi-
cation.
*Précision : indique le pourcentage de prédictions correctes.
*Rappel : évalue la capacité du modèle à détecter toutes les instances positives.
*F1-score : est la moyenne harmonique de la précision et du rappel, offre un équilibre entre les
deux.

2.5 Vue d’ensemble des outils et technologies utilisés :

Afin de mener à bien un projet de décision, il est crucial de sélectionner les outils décisionnels
appropriés pour le mettre en place. Aujourd’hui, on peut trouver sur le marché des solutions
BI propriétaires et open source, ainsi que des outils spécialisés pour des tâches particulières du
processus de prise de décision. Nous étudions quelques-uns de ces outils afin de trouver les plus
adaptés à notre projet.

2.5.1 Étude comparative des outils pour la création de DWH :

* PostgreSQL :
PostgreSQL est un puissant SGDBR (Système de gestion de base de données relationnelles )
Open Source. Réputé pour sa puissance et sa solidité, il offre de nombreuses fonctionnalités
riches et avancées pour gérer une grande quantité de données et peut être utilisé dans une
douzaine de langages de programmation, dont Python, Java, C, C++ et son propre langage
PL/pgSQL qui ressemble à PL/ SQL d’Oracle.

* SQL Server :
Microsoft SQL Server est un SGDBR développé par Microsoft, qui propose une variété de fonc-
tionnalités pour la gestion, le stockage et l’analyse des données. En outre il offre à l’utilisateur
la possibilité de manipuler, contrôler, trier, mettre à jour et d’autres fonctionnalités en utilisant
le langage SQL.
Comparons les propriétés de PostgreSQL et SQL Server dans le tableau ci-dessous :

Critère de PostgreSQL SQL Server

comparaison
Origine Open Source, Communauté Propriétaire, Microsoft
Licence PostgreSQL Licence (OS) Commerciale

Système d’exploitation Multiplateformes Principalement Windows,

(Windows, Linux, MacOS) aussi Linux
Langage C C++
d’implémentation
Langage de requête SQL standard avec T-SQL (Transact-SQL)
extension
Langages de .Net, C, C++, Python, C++, C#, JavaScript,
programmation Java, PHP Java, PHP, Python, R,
supportés Ruby

20
 Business Intelligence Extension tierce nécessaire Intégration native avec
SSIS, SSRS, SSAS
API et autres API de streaming de Flux de données tabulaires
méthodes d’accès bibliothèque C native pour (TDS), [Link], JDBC,
les objets volumineux, ODBC
[Link]
Sécurité Mécanisme de réplication Gestion des environnements
disponible que dans la critiques avancés.
version commerciale. Mécanisme de réplication
Gestion des Indexes
Table 2.1: Étude comparative entre les bases de données

2.5.2 Choix de base de données :

Nous avons choisi PostgreSQL en tant que base de données dans notre projet. Cette décision
revêt une grande importance, car PostgreSQL propose une solidité, une flexibilité et une com-
patibilité SQL complète, assurant ainsi la sécurité et l’intégrité de nos données.

2.5.3 Étude comparative des outils ETL :

* Talend Open Studio :
Talend Open Studio est un logiciel de traitement de données ETL (Extract Transform Load)
créé par Talend en 2005. Ce logiciel Open Source possède des fonctionnalités avancées pour
l’intégration de données tout en garantissant une performance optimale.
Selon la préférence de l’utilisateur, Talend crée un code Perl ou Java pour chaque job, permet-
tant ainsi l’exécution des transformations.
Grâce à un référentiel complet de formation XML, Talend peut gérer des métadonnées et
élaborer des architectures de solutions décisionnelles via un Business Modeler.

Figure 2.6 – Logo de Talend

* SQL Server Integration Services (SSIS) :

SQL Server Integration Services (SSIS) est un outil de gestion de flux de données qui fait partie
de la famille des ETL.
SSIS, également appelé Data Transformation Services dans les versions précédentes, est of-
fert aux utilisateurs disposant d’une licence SQL Server Standard ou Entreprise. Il facilite le
développement de scripts d’import et d’export en offrant une large gamme de fonctionnalités
grâce à une interface d’édition graphique.

21
 Figure 2.7 – Logo de SSIS

* Python :
Le langage informatique Python est l’un des plus couramment employés dans le domaine de la
Data Science et de l’analyse de données. Il s’avère extrêmement utile pour accomplir des tâches
complexes telles que la transformation de données, la visualisation, l’apprentissage automatique
ou l’IA.

Figure 2.8 – Logo de Python

Nous proposons alors une comparaison détaillée des propriétés, dans le tableau ci-dessous,
entre ces outils ETL :

Propriété Talend Open SSIS Python

Studio (Jupyter
Notebooks)
Licence Gratuite, OS Commerciale Open source
Performances Robuste avec Optimisée pour les Robustes avec
possibilité environnements bibliothèques
d’optimisation Windows et SQL adaptées (Pandas,
avec Java Server Dask)
Fonctionnalités ETL avec des ETL avec des Vaste bibliothèque
d’ETL composants workflows d’outils et de
réutilisables et automatisés packages pour
personnalisables l’ETL
Transformation Large éventail de Via Data Flow Utilisation de
des données composants pour Tasks et Pandas, NumPy,
transformation de transformations et autres
données complexes intégrées bibliothèques

22
 Sécurité Basée sur la Intégration avec la Basée sur la
configuration sécurité SQL configuration et
système et l’accès Server et Active les bibliothèques
au serveur Talend Directory utilisées
Table 2.2: Étude comparative entre les Outils de ETL

2.5.4 Choix d’outils ETL :

Talend a été sélectionné comme outil principal pour notre projet ETL. Sa variété de connec-
teurs qui facilitent l’intégration avec différentes sources de données, sa facilité de développement
rapide des flux de données, sa diminution des dépenses tout en profitant d’une communauté
active pour le support en font un choix idéal. Avec Talend nous bénéficions des fonctionnalités
robustes en matière de transformation et de nettoyage des données.

2.5.5 Les outils de visualisation :

* QlikView :
La société américaine Qlik a créé QlikView, une plateforme de Business Intelligence et de Vi-
sualisation de données, qui permet de convertir les données en connaissances.
Son utilisateur a la possibilité d’analyser, rechercher, rassembler et visualiser les données pour
prendre des décisions. Grâce à sa grande flexibilité d’utilisation, QlikView peut croiser les
données entre elles et intégrer un grand nombre de sources de données telles que Excel, SQL
Server et Oracle.

Figure 2.9 – Logo QlikView

* Tableau :
Tableau est un puissant et intuitif outil de visualisation de données créé par Tableau Software.
Ces fonctionnalités offrent aux utilisateurs la possibilité de convertir des données brutes en gra-
phiques interactifs, tableaux de bord et rapports visuels. Il simplifie l’exploration et l’analyse
des données grâce à son interface conviviale de glisser-déposer, sans avoir besoin de compétences
en programmation avancées.
Tableau est couramment employé dans les domaines des analyses et de la prise de décision
basée sur les données.

Figure 2.10 – Logo Tableau

* Power BI :
Power BI crée par Microsoft est un outil de visualisation de données et de business intelligence.

23
Grâce à des tableaux de bord interactifs, des rapports détaillés et des visualisations dynamiques,
il offre aux utilisateurs la possibilité de connecter, modifier et visualiser des données provenant
de différentes sources. Pour les tâches ETL il utilise Power Query et pour les calculs analytiques,
il utilise DAX (Expressions de Analyse de Données).
Power BI est disponible en versions locale, cloud et mobile, afin de satisfaire les exigences des
entreprises en matière de reporting et d’analyse en temps réel, tout en étant facile à utiliser
pour tous les utilisateurs.

Figure 2.11 – Logo de Talend

tableau ci-dessous illustre une comparaison des propriétés de ces outils :

Outils Avantages Inconvénients

QlikView - Flexibilité pour créer des - Les fonctionnalités
visualisations personnalisées intéressantes de ne sont pas
et complexes adéquates pour répondre
- Permet aux utilisateurs de aux attentes des
découvrir des relations entre utilisateurs.
les données de manière - Coût élevé, surtout pour
dynamique les petites et moyennes
entreprises.
Tableau - Excellente capacité de - Aucune possibilité de
visualisation avec des planifier et de mettre à jour
graphiques interactifs et automatiquement les
personnalisables. rapports et/ou les tableaux
- Rapports et tableaux de de bord.
bord très interactifs et - Coût plus élevé, avec des
attractifs. licences nécessitant des frais
récurrents.
Power BI -Une grande variété - Performance peut être
d’options graphiques pour a affectée par de très grands
visualisation. ensembles de données.
- Interface utilisateur - Fonctionnalités avancées
intuitive et facile à utiliser. nécessitent des licences
Power BI Pro ou Premium.
Table 2.3: Étude comparative entre les Outils de visua-
lisation

2.5.6 Choix d’outils de visualisation :

Après cette analyse comparative, Power BI apparaı̂t comme le choix optimal pour plusieurs
facteurs clés, en raison de son excellente intégration avec l’écosystème Microsoft qui offre une

24
expérience utilisateur fluide. En outre, son interface utilisateur intuitive facilite la prise en main
et la création rapide de rapports interactifs et percutants. Finalement, Power BI présente une
excellente prestation qualité-prix, avec une version gratuite et des licences à prix abordable, ce
qui est bénéfique pour notre budget.

2.6 Conclusion :
A travers ce chapitre, nous avons bien défini la notion et les concepts fondamentaux de
l’informatique décisionnelle et du machine learning, en outre nous avons effectué une étude
comparative détaillée afin de justifier nos choix des outils décisionnels utilisés.
Dès lors, nous allons consacrer le chapitre qui suit à la préparation du projet qui inclut la
détermination des besoins.

25
Chapitre 3 :

Phase de préaparation

3.1 Introduction :
La phase de préparation, également connue sous le nom de Sprint 0 selon le Co-créateur de
Scrum Ken Schawber , se concentre sur la description de la partie d’Inception qui précède le
début de notre projet.
Dans ce chapitre, notre objectif est d’examiner les exigences fonctionnelles et non fonctionnelles
du système. Ensuite, nous allons générer le Backlog des produits et diviser la solution en Sprints.
Enfin, nous allons entamer l’analyse des données provenant des sources.

3.2 Analyse des besoins :

L’analyse des besoins des clients, la définition des utilisateurs potentiels de notre solution et
la présentation des besoins fonctionnels et non fonctionnels sont les trois premières étapes de
cette phase.

3.2.1 Identification des acteurs :

Un acteur est une entité extérieure qui interagit avec le système afin de réaliser des tâches
spécifiques ou d’obtenir des informations fournies par une interface d’accès.
Au sein de notre système, on retrouve trois acteurs :
• Développeur BI : Ses principales responsabilités consistent à gérer les données et l’ETL
pour intégrer des données dans un Datawarehouse, créer des tableaux de bord et générer
un modèle de prédiction.
• Administrateur : Il a pour mission de superviser la plateforme, il a pour responsabilité de
gérer les utilisateurs, de gérer leurs fonctions et de consulter les tableaux de bord.
• Utilisateur : C’est le décideur qui est responsable de la consultation des tableaux de bord.

3.2.2 Spécification des besoins fonctionnels :

Les besoins fonctionnels répondent au point précis du cahier de charge et sont donc requis
par le client, qui est le décideur dans notre cas. Ils constituent le besoin primaire du client et
définissent l’opérationnalité du système une fois résolu.
D’où nous avons présenté les exigences fonctionnels proposés par notre système se résument
comme le suit :

- Intégration des données : Création de notre modèle multidimensionnel, grâce aux

sources de données fournit par la STB.
- Analyse des données : Préparer l’analyse multidimensionnelle basée sur les données
fournies dans la phase d’intégration.

26
 - Gestion de la partie ETL : Extraction, transformation et chargement des données pour
assurer leur qualité et leur disponibilité dans le modèle multidimensionnel.
- Création des tableaux de bord : Créer des tableaux de bord qui devront satisfaire à
divers objectifs en fonction des diverses mesures de performance.
- Génération d’un modèle de prédiction : implémenter un modèle de prédiction à
l’aide des techniques de machine learning et des modèles statistiques.
- Authentification : L’application permet aux utilisateurs de s’authentifier afin de profiter
de certaines fonctionnalités de l’application.
- Gestion des utilisateurs : Le système permet à l’administrateur de gérer ses utilisateurs
avec les fonctionnalités d’ajout, suppression et modification.
- Consultation des tableaux de bord : Permet aux décideurs de consulter les tableaux
de bord afin de leur faciliter la prise de décision.

3.2.3 Spécification des besoins non fonctionnels :

Les besoins non fonctionnels se réfèrent aux aspects visibles par les utilisateurs et ils ca-
ractérisent le système. Ce sont des exigences qui concernent les performances, l’intégralité, la
conformité aux normes, la cohérence et ne concernent pas les fonctionnalités du système.
Notre application doit alors répondre aux critères suivants :
• La rapidité de traitement : La durée d’exécution du traitement doit être le plus proche
possible du temps réel.
• La performance : Il est primordial que le logiciel soit avant tout performant, c’est-à-dire
qu’il réponde de manière optimale à toutes les exigences des utilisateurs.
• La convivialité : Le logiciel à venir doit être convivial. Effectivement, il est essentiel que
les interfaces utilisateurs soient conviviales, c’est-à-dire simples, ergonomiques et adaptées
à l’utilisateur.
• La fiabilité : Il est essentiel que l’application soit fiable et sécurisée grâce à ses fonction-
nalités qui doivent répondre de manière optimale aux exigences.
• La sécurité : L’application doit être sécurisée et assure la confidentialité de l’accès.
• L’évolutivité : L’application doit avoir la capacité de s’ajuster aux évolutions et aux futures
exigences de la banque.

27
3.3 Planification du projet :
3.3.1 Diagramme de cas d’utilisation général :
Ce schéma de cas d’utilisation global met en évidence les diverses fonctionnalités proposées
par notre projet dans son ensemble. Autrement dit, cela nous donne la possibilité de voir les
diverses actions que les utilisateurs peuvent accomplir avec notre produit. Cela nous donne une
meilleure compréhension des besoins des utilisateurs et nous permet de créer des fonctionnalités
qui répondent à leurs besoins spécifiques.

Figure 3.1 – Diagramme de cas d’utilisation global

3.3.2 Backlog produit :

Les fonctionnalités du backlog jouent un rôle essentiel dans la méthodologie SCRUM. Les
éléments de travail identifiés et ajoutés à la liste prioritaire des fonctionnalités à développer,
appelée backlog du produit, sont représentés. Chaque caractéristique du backlog se présente
sous la forme d’une ”user story” (histoire utilisateur) qui relate un besoin particulier d’un uti-
lisateur ou d’un acteur du système. Lorsque chaque itération est planifiée, l’équipe SCRUM
choisit les fonctionnalités du backlog afin de créer le backlog de l’itération.
Le choix est réalisé en prenant en considération les priorités, la capacité de l’équipe et les ob-
jectifs de l’itération.

28
 Notre Backlog produit est défini comme suit :

Thème ID User story Priorité

Intégration des
En tant que développeur BI, l’acteur a besoin de
données et
1 1.1 comprendre les données pour comprendre 1
Développement
l’activité du projet.
ETL
En tant que développeur BI, l’acteur peut faire la
1.2 conception de l’entrepôt de données ainsi que les 1
datamarts.
En tant que développeur BI, l’acteur peut gérer
1.3 1
l’ETL et le rendre planifié.
En tant que développeur BI, l’acteur peut créer
Restitution et des tableaux de bord relatifs à l’activité clientèle,
2 2.1 1
Prédiction planifier leur actualisation et les rendre plus
simples pour les utilisateurs
En tant que développeur BI, l’acteur peut
2.2 1
implémenter un modèle de prédiction
Authentification
En tant qu’administrateur, l’acteur doit
et Gestion des 3 3.1 1
s’authentifier pour accéder à l’application.
utilisateurs
En tant que utilisateur, l’acteur doit
3.2 1
s’authentifier pour accéder à l’application.
En tant qu’administrateur, l’acteur peut ajouter,
3.3 1
modifier ou supprimer un utilisateur.
En tant qu’administrateur, l’acteur peut créer et
3.4 1
révoquer des rôles aux utilisateurs.
Intégration des En tant qu’administrateur, l’acteur peut
tableaux de 4 4.1 consulter les détails des tableaux de bord ainsi 1
bord que les indicateurs clés de performance.
En tant que décideur, l’acteur peut consulter les
4.2 tableaux de bord ainsi que les indicateurs clés de 1
performance.
Table 3.1: Backlog produit

3.3.3 Pilotage du projet avec SCRUM :

Nous présentons l’équipe du projet avec laquelle nous avons travaillé, qui se base sur trois
acteurs principaux :

29
 Product Owner Scrum master Development Team
La STB Mr. Imed Semia Sehli
(Mr Yassine Flija ) Ben Boukhatem Mr. Imed

3.3.4 Découpage en Sprints :

Il est essentiel de planifier les sprints dans la méthodologie SCRUM. Cela implique d’iden-
tifier les fonctionnalités du backlog qui seront intégrées à chaque sprint.

Sprint 1 :Intégration des données, analyse

des données, et le développement ETL.

Sprint 2 : Restitution des données, et

implémentation d’un modèle de prédiction.

Authentification , Gestion des utili-

Sprint 3 :
sateurs et Intégration des tableaux de bord.

Figure 3.2 – Répartition des Sprints

3.3.5 Diagramme de GANTT :

Afin de concrétiser notre projet et de garantir une organisation efficace, nous avons élaboré
un chronogramme qui englobe les diverses tâches à effectuer :
✓ Étape 1 : Familiarisation avec la partie métier et définition des besoins.
✓ Étape 2 : Formation/Installation des outils nécessaires.
✓ Étape 3 : Comparaison et analyse des données sources.
✓ Étape 4 : Modélisation et Développement du Sprint 1.
✓ Étape 5 : Modélisation et Développement du Sprint 2.
✓ Étape 5 : Modélisation et Développement du Sprint 3.
✓ Rédaction du rapport.

30
 Mars Avril Mai Juin
S1 S2 S3 S4 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 3.2 – Diagramme de Gantt

3.4 Étude des données sources :

Après avoir identifié les besoins fonctionnels, il est nécessaire de débuter la collecte des
données. Dans cette partie, nous allons examiner les informations provenant du système d’in-
formation de la banque, qui seront utilisées pour alimenter notre entrepôt. Pour des motifs
de confidentialité et de sécurité, nous n’avions pas la possibilité d’accéder aux serveurs de la
banque où sont stockées les informations personnelles des clients. Nous avons reçu les données
sources sous forme des fichiers CSV. Nous avons alors créé une base de données relationnelle
contenant les tables suivantes :

• Table compte : Cette table renferme des renseignements concernant les comptes des clients
de la STB.
• Table client : Cette table rassemble les données sociodémographiques concernant les clients
de la STB.
• Table agence : Cette table contient les informations relatives aux agences de la STB.
• Table crédits : Cette table comporte les informations relatives aux crédits de la STB.

3.4.1 Conception de la base de données :

La modélisation des données au niveau relationnel (ou logique) est abordée dans cette section.
Cela nécessite la mise en place des tables dans la base Postgresql et la mise en place des relations.
Cette base a été baptisée ≪ STBTestDB ≫.
Montrons cette modélisation dzans la figure ci-dessous :

31
 Figure 3.3 – Modélisation de la base de données

3.4.2 Alimentation de la base de données :

La prochaine étape après avoir créé la base de données PostgreSQL consiste à alimenter
cette base avec les données sources livrées sous format CSV en présentant les étapes dans les
figures ci-dessous :

Figure 3.4 – L’importation du fichier ”Table Client”

32
Figure 3.5 – L’importation du fichier ”Table Comptes”

Figure 3.6 – L’importation du fichier ”Table Adresse”

Figure 3.7 – L’importation du fichier ”Table Agence”

Figure 3.8 – L’importation du fichier ”Table Crédits”

33
 Finalement les tables de notre base de données, au niveau de laquelle nous stockons les
fichiers sources, sont prêtes :

Figure 3.9 – L’importation du fichier ”Table Adresse”

3.5 Conclusion :
Au cours de ce chapitre, nous avons examiné les différents acteurs du système, les be-
soins fonctionnels et non fonctionnels, ainsi que la création du Backlog Produit, qui constitue
l’élément principal de ce volet. Ensuite, nous avons commencé à planifier le projet en divisant
la solution en sprints. Enfin, nous avons examiné les données provenant des sources fournies.
Dans le prochain chapitre, nous allons commencer le premier Sprint.

34
Chapitre 4 :

Sprint 1 : Intégration des données et

développement ETL

4.1 Introduction :
Dans ce chapitre, nous aborderons la gestion du premier sprint de notre projet. Dans un
premier temps, nous allons établir le backlog du sprint avant de passer à la mise en œuvre de
notre solution. Au début de notre premier sprint, nous entamerons la conception et ensuite le
développement de l’ETL afin de mettre en œuvre l’entrepôt de donnée.

4.2 Environnement logiciel et technologies utilisées :

Dans cette section, nous allons présenter tous les outils de développement et de réalisation
ainsi que les technologies utilisées pour le développement du premier sprint :

Logo Nom Description

C’est un outil open-source de gestion de données pour
l’intégration, la transformation, et le chargement (ETL) des
Talend
données. Il fournit une interface graphique pour simplifier la
création de workflows ETL.

C’est un SGBDR open-source, réputé pour sa robustesse et sa

conformité aux normes SQL. Il offre des fonctionnalités avancées
PostgeSQL
telles que les transactions complexes, l’extensibilité et le support
des types de données personnalisés.

C’est un outil open source dédié à la modélisation UML, est convi-

Star UML vial, économe de ressources et constitue une excellente option pour
se familiariser avec la modélisation.

Table 4.1 – Environnement logiciel et technologies utilisées

35
4.3 Backlog du Sprint 1 :
Notre Backlog produit est défini comme suit :

Sprint ID User story Tâche Priorité

En tant que - La collecte des données à
développeur, partir des fichiers
l’acteur a besoin sources,sous format csv, de
de comprendre les la société
SPRINT 1 : Intégration des données et Développement

1 1.1 1
données pour - Analyse des données afin
comprendre de comprendre leur nature,
l’activité du leur qualité et leur
projet. structure
En tant que
- La détermination des
développeur,
dimensions et des faits
l’acteur doit faire
1.2 - La conception de DWH 1
la conception du
- La conception des
ETL

DWH ainsi que

datamarts
les datamarts
- Établir une connexion
avec l’entrepôt de données.
- Nettoyer et transformer
En tant que
les données afin de les
développeur BI,
rendre cohérentes et
1.3 l’acteur peut 1
décisionnelles.
gérer l’ETL et le
- Créer et charger les tables
rendre planifié.
de dimensions et les faits.
- Automatiser la
planification de l’ETL.
Table 4.2: Backlog Sprint 1

4.4 Architecture de notre solution BI :

Le projet est organisé en trois grandes parties, chacune jouant un rôle crucial dans le pro-
cessus global :
✥ Il est essentiel de repérer les divers éléments sources requis avant la phase de conception.
✥ La méthode ETL qui implique diverses opérations d’organisation afin de charger les données
dans l’entrepôt de données. La collecte, la transformation et le chargement des données
sont inclus dans cette étape afin de les utiliser ultérieurement.
✥ Le processus de reporting et de visualisation des métriques clés définies est également
inclus. Ces résultats permettent donc aux décideurs de prendre des décisions éclairées.
La figure ci-dessous présente l’organisation globale de notre projet. Chaque section joue un
rôle essentiel dans le processus global et oriente notre travail lors des prochaines étapes.

36
 Figure 4.1 – Architecture de notre solution BI

4.5 Schéma conceptuel des données :

Dans cette section, nous exposerons de manière approfondie notre modèle d’entrepôt de
données en expliquant les diverses tables de dimensions et de faits, et en conclusion, nous
détaillons la modélisation dans son ensemble.

4.5.1 Identification des tables de dimensions :

Une dimension est une table qui contient les axes d’analyse selon lesquels on veut étudier
des données observables.
L’ensemble de notre projet comprend différentes dimensions, chacune représentant un axe d’ana-
lyse qui possède sa propre clé, et qui, une fois combinées avec les mesures adéquates, fournissent
aux décideurs les informations indispensables pour prendre des décisions informées.

Les dimensions de notre modèle de données ainsi que leurs descriptions sont présentées dans
le tableau descriptif ci-dessous :

Dimension Attributs Description de la

dimension
Dim client id client Cette dimension correspond
Nom client aux informations
Sexe personnelles des clients
date naissance
num tel
Email
statut client

37
 Dim compte num cpte Cette dimension présente
type cpte les comptes ouverts dans la
date ouv cpte STB
Dim adresse id adresse Cette dimension correspond
pays aux adresses des clients
gouvernorat
ville
adresse
Dim Credit id credit Cette dimension correspond
Montant cr aux informations relatives
Taux interet aux crédits
Duree cr
Type cr
Dim date id annee Cette dimension correspond
Date octroi à l’axe temporel.
Table 4.3: Description des dimensions

4.5.2 Identification des tables de faits :

Dans notre projet, nous avons créé deux tables (Fact CL) et (Fact CR) qui renferment des
mesures correspondant aux informations du domaine de l’activité clientèle de la STB, en ce qui
concerne les clients et les crédits, que nous souhaitons analyser selon plusieurs axes (dimen-
sions). Les clés primaires de ces deux tables sont la combinaison des clés primaires de toutes
les tables de dimensions correspondantes.

Le tableau ci-dessous présente les éléments de nos tables réalisées :

Fait Champs Description

Fact CL FK id client - Clé étrangère de la dimension client.
FK num compte - Clé étrangère de la dimension compte.
FK id solde - Clé étrangère de la dimension solde.
FK id adresse - Clé étrangère de la dimension adresse.

NbretotCptes - Mesure qui calcule le nombre total des

comptes
Solde total - Mesure qui calcule le solde de tous les
comptes
Nbre Mand - Mesure qui calcule le nombre des
mandataires
Nbre tit - Mesure qui calcule le nombre des
titulaires
Max solde - Mesure qui montre le solde maximum
d’un compte
Min solde - Mesure qui montre le solde minimum
d’un compte

38
 Fact CR FK id client - Clé étrangère de la dimension client.
FK id annee - Clé étrangère de la dimension date.
FK id credit - Clé étrangère de la dimension crédit.

Nbre cr - Mesure qui calcule le nombre total des

Crédits
Nb tot cr - Mesure qui calcule le nombre des crédits
remboursés
Mont tot cr - Mesure qui calcule la somme de
montants des crédits
Mont Cr Risque - Mesure qui calcule la somme de
montants des crédits à risque
Taux defaut global - Mesure qui calcule le taux de défaut
global
Nbre Cr remb - Mesure qui calcule le nombre de crédits
remboursés
Taux rembours - Mesure qui calcule le taux de
remboursement
Taux Interet Moyen - Mesure qui calcule le taux d’intérêt
moyen
Table 4.4: Description des faits

4.5.3 Conception physique du modèle :

[Link] Le modèle de l’entrepôt de données :

Le modèle en constellation a été choisi car il offre la possibilité de structurer et d’organiser

les données de manière hiérarchique. Ce modèle s’avère très pratique pour l’analyse de données
complexes ayant plusieurs dimensions. Effectivement, les faits présents dans ce modèle sont liés
à différentes dimensions, ce qui facilite et détaille leur analyse.

Dans le modèle en constellation, la hiérarchisation des dimensions permet d’observer faci-

lement les liens entre les différentes dimensions et les faits qui leur sont associés et de mieux
comprendre les données que nous analysons.

Le modèle complet de notre entrepôt de données est un modèle en constellation illustré dans
la figure ci-dessous :

39
 Figure 4.2 – Le modèle de l’entrepôt de données

[Link] Le modèle des datamarts :

Une fois que nous avons terminé la création de notre entrepôt de données, nous nous at-
taquons à la cconception des datamarts, qui sont des sous-ensembles spécifiques et dérivés de
notre datawarehouse global. Chaque datamart a été élaboré afin de satisfaire aux exigences
analytiques spécifiques d’un domaine ou d’un sujet particulier de notre entreprise. Dans notre
situation, nous avons repéré deux datamarts : le datamart ”Clients” et le datamart ”Crédits”.
✥ Datamart des Clients :

Le datamart ”Clients” est spécifiquement conçu pour stocker, organiser et analyser les
données liées aux clients.

Figure 4.3 – Le modèle du datamart Clients

40
 ✥ Datamart des Crédits :
Ce datamart est dédié à la gestion des données relatives aux crédits de la STB.

Figure 4.4 – Le modèle du datamart Crédits

4.6 Développement du système ETL :

4.6.1 Préparation de l’Environnement Technique :
Pour notre projet, nous avons créé un environnement technique robuste afin de mettre en
œuvre notre solution BI. Un aspect essentiel de cette préparation a consisté à installer Talend
Open Studio et le SGDBR PostgreSQL. Grâce à cette méthode, nous avons pu profiter de
multiples avantages en ce qui concerne la simplicité de déploiement et de gestion de notre ETL.
✥ L’installation de Talend Open Studio :

Figure 4.5 – Installation de Talend Open Studio

41
✥ La création d’un projet TALEND :
La création du projet se fait avant l’ouverture de l’interface du logiciel. (Voir figure 4.6)

Figure 4.6 – Création d’un projet Talend

✥ La création du JOB :

La création du JOB sur Talend Open Studio est cruciale car elle garantit une intégration
fluide et automatisée des données provenant des fichiers sources vers notre DWH, améliorant
ainsi l’efficacité et la fiabilité de notre solution BI. (Voir figure 4.7)

Figure 4.7 – Création d’un JOB

42
✥ Installation de PostgreSQL : L’installation de PostgreSQL pour la partie ETL est
essentielle car elle offre une plateforme robuste et fiable pour le stockage et la gestion
des données transformées. Son utilisation assure une performance optimale et une sécurité
renforcée pour nos opérations de traitement de données. (Voir figure 4.8)

Figure 4.8 – Installation de PostgreSQL

✥ Création de la base de données pour le data warehouse :

La création de la base de données pour le data warehouse est une étape fondamentale qui
permet de centraliser, structurer et gérer efficacement l’ensemble des données nécessaires
pour nos analyses décisionnelles. (Voir figure 4.9)

Figure 4.9 – Création de la base de données

43
4.6.2 Implémentation ETL :
Une fois la préparation de l’environnement de développement terminée, nous procédons à
la mise en place de notre module BI. Passant par la préparation des données sources et en
finissant par les charger dans notre entrepôt de données.

44
Chapitre 5 :

Sprint 2 : Restitution des données et

prédictions

5.1 Introduction :
Nous examinerons dans ce chapitre la gestion du deuxième sprint de notre projet. Dans
un premier temps, nous préparerons le backlog du sprint et nous nous concentrerons sur la
conception des tableaux de bord, puis nous procéderons à la mise en œuvre du modèle de
prédiction.

5.2 Environnement logiciel et technologies utilisées :

Dans cette partie, nous allons présenter l’ensemble des outils et des technologies utilisés pour
la création du deuxième sprint.

Logo Nom Description

Power BI offre aux entreprises la possibilité d’analyser leurs
données de manière plus efficace grâce à des visualisations inter-
Power BI
actives, des tableaux de bord dynamiques et des rapports person-
nalisables.
Anaconda est une distribution de Python et R pour le traite-
ment des données et l’apprentissage automatique, comprenant de
Anaconda nombreux packages et outils open source. Il simplifie la gestion
des environnements et des dépendances pour les projets de data
science.

Jupyter Notebook est une plateforme Web permettant de conce-

Jupyter Notebook voir et de partager des documents informatiques interactifs, in-
cluant du code, des visualisations et des explications.

Table 5.1 – Environnement logiciel et technologies utilisées

45
5.3 Backlog du Sprint 2 :

Sprint ID User story Tâche Priorité

En tant que
développeur BI,
- Faire une connexion avec
l’acteur peut créer
l’entrepôt de données.
des tableaux de
- Créer des tableaux de
bord relatifs à
bord dynamiques, simples
des données et prédictions

2 2.1 l’activité clientèle, 1

SPRINT 2 : Restitution

et intuitifs
planifier leur
- Planifier et automatiser
actualisation et
l’actualisation des tableaux
les rendre plus
de bord.
simples pour les
utilisateurs
En tant que
- Choisir l’algorithme
développeur BI,
d’apprentissage approprié
l’acteur peut
2.2 - Implémenter l’algorithme 1
implémenter un
choisi.
modèle de
- Visualiser les données.
prédiction
Table 5.2: Backlog Sprint 2

5.4 Restitution des données :

Il est essentiel que les décideurs de chaque entreprise prennent en compte la phase de resti-
tution de données, car les rapports produits fournissent des indicateurs pertinents, des analyses
détaillées et des visualisations graphiques qui facilitent la prise de décision.

5.4.1 Connexion directe à l’entrepôt de données :

Figure 5.1 – Connexion de Power BI avec la base de données PostgreSQL

46
 Nous avons opté pour la base de données PostgreSQL lors de cette étape et nous nous
sommes connectés à notre localhost en utilisant l’option ≪ Direct Query ≫. Cette option permet
de récupérer les données directement depuis la source lors de la requête.

Figure 5.2 – Connexion directe à l’entrepôt de données avec l’option ”Direct Query”

5.4.2 Élaboration des tableaux de bord :

Pour notre projet, il est essentiel de pouvoir naviguer entre les tableaux de bord. Donc nous
avons développé une page d’accueil qui présente le logo de la société ainsi qu’un titre et deux
boutons pour faciliter la navigation aux décideurs, voir figure 5.4

Figure 5.3 – Les boutons de navigation

✥ Tableau de bord ”Page d’accueil” :

Figure 5.4 – Tableau de bord ”Page d’accueil”

47
[Link] Tableaux de bord relatifs aux clients :

Ces tableaux de bord permettront de fournir des insights détaillés sur les comportements,
les tendances et les segments de la clientèle, facilitant ainsi une meilleure prise de décision pour
la gestion des relations clients.

✥ Tableau de bord ”VUE GÉNÉRALE” :

Figure 5.5 – Tableau de bord ”VUE GÉNÉRALE”

• Les cartes sont l’un des outils de visualisation les plus captivants offerts par Power BI.
Elles permettent d’afficher des données quantitatives, précises et bien déterminées tels
que : le nombre total des comptes, le solde total, le nombre de titulaires et le nombre de
mandataires comme montre la figure 5.2 :

Figure 5.6 – Cartes

48
• TOP 5 agence en nombre de comptes : Ce KPI permet d’identifier les 5 agences du réseau
de la banque avec le nombre de comptes le plus élevé. Cela permet aux décideurs d’analyser
les facteurs de succès de ces agences, et de reproduire ces pratiques dans d’autres agences
pour améliorer la performance globale du réseau.
Dans notre cas, nous avons utilisé ce graphique pour visualiser les 5 agences en fonction
du nombre de comptes comme montre la figure 5.7

Figure 5.7 – histogramme groupé

• TOP 5 agences par solde : Ce KPI permet d’identifier les 5 agences du réseau de la banque
avec les soldes les plus élevés. Cela permet aux décideurs de cibler les agences qui gèrent
les portefeuilles les plus importants.
Nous avons utilisé ce graphique à barres empilés pour visualiser les top 5 agences en
fonction du solde des comptes comme montre la figure 5.8

Figure 5.8 – Graphique à barres empilés

• Nombre de comptes par nature de compte : Ce KPI permet de répartir et d’analyser le

nombre de comptes en fonction de leur nature. Cela permet aux décideurs d’ajuster les
offres de produits afin de satisfaire les besoins et les attentes des clients.
Dans ce cas, nous avons utilisé le graphique circulaire afin de montrer la répartition des
comptes en fonction de leurs natures comme montre la figure 5.9

Figure 5.9 – Graphique circulaire

49
• Nombre de comptes durant les 5 dernières années : Ce KPI permet de suivre l’évolution
du nombre de comptes ouverts chaque année au cours des cinq dernières années. Cela aide
les décideurs à identifier les tendances de croissance ou de déclin.
L’utilisation d’un tableau récapitulatif pour étudier ce KPI est le meilleur choix pour bien
visualiser l’évolution du nombre de comptes sur les cinq dernières années comme montre
la figure 5.10

Figure 5.10 – Tableau récapitulatif

✥ Tableau de bord ”NOMBRE DE COMPTES” :

Figure 5.11 – Tableau de bord ”NOMBRE DE COMPTES”

• Le facteur temps est primordial dans n’importe quel indicateur à visualiser . nous avons
choisi de donner l’opportunité à l’utilisateur pour choisir la date souhaitée à partir d’un
segment comme montre la figure 5.12 :

Figure 5.12 – Segment date

50
• Nombre de comptes par trimestre : Ce KPI permet de suivre et d’analyser l’évolution
du nombre de comptes ouverts sur une base trimestrielle. Il permet aux décideurs de
comprendre les variations saisonnières et l’impact des initiatives commerciales.
Présentant ce KPI à l’aide d’un histogramme d’où chaque colonne présente un trimestre
et son nombre de comptes comme montre la figure 5.13

Figure 5.13 – Histogramme

• Nombre de comptes par type de compte : Ce KPI permet de segmenter et d’analyser le

nombre de comptes en fonction du type de client. Cela aide les décideurs à comprendre la
répartition des comptes entre entreprises et particuliers, à ajuster les stratégies de service
clientèle en fonction des besoins spécifiques de chaque segment.
Nous avons utilisé un graphique en entonnoir qui représente ce KPI comme montre la
figure 5.14

Figure 5.14 – Graphique en entonnoir

51
• Nombre de comptes par état de compte : Ce KPI permet de catégoriser et d’analyser les
comptes en fonction de leur état actuel. Cela aide les décideurs à identifier les comptes
nécessitant une attention particulière (comme ceux en contentieux) et à prendre des me-
sures pro-actives pour réduire les risques et optimiser la satisfaction et la fidélité des clients.
Dans notre cas, nous avons introduit un graphique en beignet qui montre la répartition
des comptes par leurs états comme montre la figure 5.15

Figure 5.15 – Graphique en beignet

• Nombre de comptes par nature de compte : Ce KPI permet de catégoriser et d’analyser

le nombre de comptes en fonction de leurs natures. Cette répartition aide les décideurs
à comprendre les catégories de comptes les plus appréciées et de repérer les segments de
marché les plus rentables.
Un graphique en aire précise bien les variations du nombre de comptes en fonction de leurs
natures comme montre la figure 5.16

Figure 5.16 – Graphique en aire

52
• Nombre de comptes par gouvernorat : Ce KPI permet de répartir et d’analyser le nombre
de comptes en fonction des différentes régions géographiques. Cela aide les décideurs à
comprendre la distribution géographique de la clientèle et à identifier les zones avec une
forte concentration de comptes.

L’utilisation d’une Map visuelle (panneau synoptique) pour ce KPI permet de visualiser
facilement la répartition géographique des comptes.

Figure 5.17 – panneau synoptique

✥ Tableau de bord ”SOLDE” :

Figure 5.18 – Tableau de bord ”SOLDE”

53
• Solde par année : Ce KPI permet de suivre et d’analyser l’évolution du solde moyen des
comptes sur une base annuelle. Il offre une vision claire des tendances financières des
clients, en montrant comment le solde des comptes fluctue au fil des ans.
Nous avons présenté ce KPI par un graphique en aire qui permet de visualiser l’évolution
du solde en fonction de l’année comme montre la figure 5.19

Figure 5.19 – Graphique en aire

• Solde par type de compte : Ce KPI permet de différencier et d’étudier le solde moyen
des comptes détenus par des individus par rapport à ceux détenus par des sociétés. Cela
permet la personnalisation des méthodes clients pour mieux répondre aux besoins distincts
des clients physiques et moraux.
Nous avons exploité un graphique circulaire pour suivre la répartition du solde par type
de compte, représenté par la figure 5.20

Figure 5.20 – Graphique circulaire

54
• Solde par semestre : Ce KPI permet de suivre et d’analyser l’évolution du solde moyen
des comptes sur une base [Link] décideurs peuvent utiliser ces informations pour
mieux comprendre les comportements financiers des clients à court terme.
Nous avons choisi d’utiliser le graphique à colonnes empilées pour faire montrer le solde
par semestre, comme montre la figure 5.21

Figure 5.21 – Graphique à colonnes empilées

• Solde maximum d’un compte : Ce KPI permet de visualiser le solde le plus élevé détenu
dans un compte au sein de chaque agence d’un gouvernorat spécifique. Cela aide à identifier
les régions avec des clients ayant des capacités financières significatives.
• Solde minimum d’un compte : Ce KPI permet de visualiser le solde le plus faible détenu
dans un compte au sein de chaque gouvernorat. Il est utile pour identifier les régions où les
clients peuvent être financièrement vulnérables ou avoir des besoins financiers particuliers.

Figure 5.22 – Cartes présentant le maximum et le minimum du solde dans un compte

• Solde par gouvernorat : Ce KPI permet

de suivre et d’analyser le solde moyen des
comptes en fonction des différentes régions
géographiques (gouvernorats). Il aide à com-
prendre la répartition géographique des avoirs
financiers des clients, en identifiant les régions
avec des soldes moyens élevés ou faibles. Les
décideurs peuvent utiliser ces informations pour
adapter les stratégies de gestion de trésorerie
régionale

Figure 5.23 – Carte à plusieurs rangées

55
✥ Tableau de bord ”Statut Compte” :

Figure 5.24 – Tableau de bord ”Statut Compte”

• Nombre de mandataires par état de compte : En utilisant ce KPI, les gestionnaires peuvent
s’assurer que les comptes sous gestion bénéficient d’une supervision adéquate selon leur
situation juridique ou financière.
• Nombre de mandataires par type de compte : Ce KPI est essentiel pour comprendre com-
ment les mandataires judiciaires ou administrateurs sont répartis entre les comptes détenus
par des individus et ceux détenus par des entités juridiques telles que des entreprises ou
des associations.
Nous avons exploité ces deux graphes pour bien présenter ces KPIs : un graphique en
entonnoir qui présente la répartition des mandataires par état de compte (Voir la figure
5.25) et pour la répartition des mandataires en fonction de type des comptes est présentée
à l’aide d’un graphique à colonnes empilées (Voir la figure 5.26)

Figure 5.25 – graphique en entonnoir Figure 5.26 – Graphique à colonnes empilées

• Nombre de titulaires par état de compte : Ce KPI permet de suivre et d’analyser le

nombre de titulaires de compte en fonction de l’état de leur compte financier. En utilisant
ce KPI, les institutions financières peuvent prendre des décisions informées pour optimiser
la rentabilité et minimiser les risques associés aux différents états de compte.
• Nombre de titulaires par type de compte : Ce KPI permet de catégoriser et d’analyser le
nombre de titulaires de compte en fonction du type de titulaire. Il est utilisé pour com-

56
 prendre la répartition des clients individuels par rapport aux entités morales (entreprises,
associations, etc.) parmi les titulaires de comptes. En utilisant ce KPI, les institutions fi-
nancières peuvent mieux adapter leurs offres de produits et services financiers aux besoins
spécifiques des clients individuels et des entités morales.

Nous avons exploité ces deux graphes pour bien présenter ces KPIs : un graphique à barres
empilés qui présente la répartition des titulaires par état de compte (Voir la figure 5.27)
et pour la répartition des titulaires en fonction de type des comptes est présentée à l’aide
d’un graphique circulaire (Voir la figure 5.28)

Figure 5.27 – Graphique à barres empilés Figure 5.28 – Graphique circulaire

[Link] Tableaux de bord relatifs aux Crédits :

✥ Tableau de bord ”Performance des Crédits”

Figure 5.29 – Tableau de bord ”Performance des Crédits”

57
• Nombre de crédits : Ce KPI présente le nombre total de crédits accordés par votre institu-
tion financière sur une période donnée. Cela vous permet de suivre l’évolution de l’activité
de prêt et de comparer les performances par rapport aux périodes précédentes.
• Montant total des crédits : Ce KPI représente le montant global de tous les crédits en
cours, représentant la somme totale d’argent prêtée par votre institution financière. C’est
un indicateur crucial pour évaluer l’exposition financière et la capacité de prêt de votre
organisation.
• Taux de remboursement : Ce KPI présente le pourcentage des crédits accordés qui ont
été remboursés dans les délais convenus. Il permet d’évaluer la qualité du portefeuille de
crédit et la performance des emprunteurs dans le respect de leurs engagements.
• Taux d’intérêt moyen : Ce KPI montre le taux d’intérêt moyen appliqué sur l’ensemble
des crédits accordés. C’est un indicateur clé pour évaluer la rentabilité des prêts accordés
et l’impact financier global des opérations de crédit de votre institution.

Ces cartes dans la figure 5.30 présentent tous les quatres KPIs

Figure 5.30 – Cartes

• Nombre de crédits par type de crédit : Ce KPI permet de répartir et d’analyser le nombre
de crédits en fonction des différents types de produits de crédit offerts par votre institution
financière. Cela vous aide à comprendre quel type de produit de crédit est le plus populaire
parmi vos clients.
Le graphique à barres empilés montre le nombre de crédits en fonction de leurs types
comme montre la figure 5.31

Figure 5.31 – Graphique à barres empilés

• Nombre de crédits par nature de compte : Ce KPI permet de catégoriser et d’analyser le

nombre de crédits accordés en fonction de la nature du compte sur lequel ils sont basés.

Figure 5.32 – Graphique circulaire

58
• Taux de remboursement par nature de compte : Ce KPI mesure le pourcentage de crédits
remboursés dans les délais convenus, ventilé par la nature du compte. Cela permet d’évaluer
la performance de remboursement des emprunteurs selon le type de compte qu’ils utilisent.

Figure 5.33 – Graphique à colonnes empilées

✥ Tableau de bord ”Performance des Agences”

Figure 5.34 – Tableau de bord ”Performance des Crédits”

• Nombre de crédits par agence : Ce KPI montre le nombre total de crédits accordés par
chaque agence de votre institution financière. Il permet de mesurer l’activité de prêt de
chaque agence individuellement.

Figure 5.35 – Carte géographique

59
• Top 5 des agences en nombre de crédits : Cette carte identifie les cinq agences qui accordent
le plus grand nombre de crédits. Cela permet de reconnaı̂tre les agences les plus productives
en termes d’activité de prêt.

Figure 5.36 – Graphique à colonnes empilées

• Top 5 des agences en montant de crédits : Cette carte montre les cinq agences qui ont
accordé le montant total le plus élevé de crédits. Cela met en lumière les agences qui
traitent les montants de crédits les plus importants, indiquant potentiellement des marchés
plus riches ou des besoins de crédit spécifiques dans ces régions.

Figure 5.37 – Graphique à barres empilés

• Performance globale des agences : Ce KPI est un indicateur synthétique conçu pour évaluer
et comparer l’efficacité opérationnelle des différentes agences d’une institution financière.
Il combine plusieurs mesures clés pour fournir une vue d’ensemble de la contribution et de
la performance de chaque agence.
Cette carte radar, qui combine entre deux mesures : Nombre de crédits et le montant total
des crédits, montre la performance des agences en fonction des mesures citées, comme le
montre la figure 5.38

Figure 5.38 – Carte radar

60
✥ Tableau de bord ”Analyse des Crédits par Segment de clientèle”

Figure 5.39 – Tableau de bord ”Analyse des Crédits par Segment de clientèle”

• Répartition des crédits par tranche d’âge : Ce KPI permet de visualiser et d’analyser la
répartition des crédits accordés selon les différentes tranches d’âge des emprunteurs. Il
offre une perspective sur quelles tranches d’âge bénéficient le plus de prêts.

Figure 5.40 – Graphique à colonnes empilées

• Répartition des crédits par sexe : Ce KPI présente la distribution des crédits accordés en
fonction du sexe des emprunteurs. Il aide à identifier les différences de demande de crédit
entre hommes et femmes.

Figure 5.41 – Graphique en beignet

61
• Taux de défaut par sexe : Ce KPI mesure le pourcentage de crédits accordés par sexe qui
ont fait défaut, c’est-à-dire qui n’ont pas été remboursés selon les termes convenus. Cela
permet d’évaluer la qualité de crédit par sexe et de prendre des mesures pour améliorer la
gestion des risques.

Figure 5.42 – Histogramme

• Montant de crédits par tranche d’âge et sexe : Ce KPI présente le montant total des
crédits accordés ventilé par tranche d’âge et par sexe. Cela permet une analyse croisée
pour identifier les segments spécifiques de marché où les demandes de crédit sont les plus
élevées, tout en tenant compte des caractéristiques démographiques.

Figure 5.43 – Diagramme de dispersion

• Taux de défaut par tranche d’âge : Ce KPI mesure le pourcentage de crédits qui ont fait
défaut, ventilé par tranche d’âge des emprunteurs. Cela aide à évaluer comment le risque
de défaut varie avec l’âge des emprunteurs et à ajuster les politiques de prêt en fonction
de ces observations.

Figure 5.44 – Graphique en entonnoir

62
✥ Tableau de bord ”Risques des Crédits”

Figure 5.45 – Tableau de bord ”Risques des Crédits”

• Montant de crédits en risque, Le nombre de crédits en défaut et le taux de défaut : Ce sont

des KPIs qui permettent de prendre des mesures pro-actives pour atténuer ces risques et
permettent également à évaluer la santé du portefeuille de crédits. Cela aide alors à ajuster
les politiques de gestion des risques pour minimiser les pertes potentielles.

Figure 5.46 – Cartes

• Taux de défaut par nature de compte et le Taux de défaut par type de crédits : Ces
KPIs mesurent le pourcentage de comptes en défaut de paiement, segmenté par nature
de compte et type de crédits. Ils sont cruciaux pour les décideurs vu qu’ils permettent
d’identifier les segments de comptes les plus à risque et de prendre des décisions éclairées
pour améliorer la santé financière de l’institution et la qualité du portefeuille de crédits.

Ces KPIs sont présentés dans les figures 5.47 et 5.48 ci-dessous :

Figure 5.47 – Graphique en entonnoir Figure 5.48 – Graphique à colonnes empilées

63
• Le tableau montré au niveau de la figure 5.49 présente le montant total de crédits à risque
en fonction de nature de comptes et les tranches d’âge des clients. Ceci facilite la détection
des groupes d’âge les plus vulnérables et l’adaptation des stratégies de prêt et de gestion
des risques en conséquence afin de réduire les pertes potentielles et d’améliorer la qualité
du portefeuille de crédits.

Figure 5.49 – Matrice

✥ Tableau de bord ”Évolution des Crédits”

Figure 5.50 – Tableau de bord ”Évolution des Crédits”

• Filtres de temps (jour, mois, année) : Ces filtres de période jouent un rôle crucial dans les
tableaux de bord analytiques, offrant aux décideurs la possibilité de diviser et d’analyser
les données en fonction de différentes périodes de temps.

Figure 5.51 – Filtres de temps

• Nombre de crédits par année : Ce KPI permet de suivre le nombre total de crédits accordés
par notre institution financière chaque année. Cela donne aux décideurs une vue d’ensemble
de l’évolution de l’activité de prêt au fil du temps, ce qui est essentiel pour évaluer la
croissance et la performance annuelle du portefeuille de crédits.

64
 Figure 5.52 – Graphique en ligne

• Nombre de crédits par trimestre : Ce KPI montre le nombre total de crédits accordés par
trimestre. Il offre une vue plus granulaire de l’activité de prêt, ce qui permet de repérer
les périodes de pic ou de creux dans l’octroi des prêts au cours de l’année.
Le diagramme en cascade dans la figure 5.49 présente la répartition du nombre de crédits
accordés en fonction de trimestre

Figure 5.53 – Diagramme en cascade

• Taux de défaut par année : Ce KPI permet de détecter les périodes de risque accru,
d’analyser les causes des défauts de paiement et d’ajuster les politiques de gestion des
risques pour améliorer la performance du portefeuille de crédits.
• Taux d’intérêt moyen par année : Ce KPI mesure le taux d’intérêt moyen appliqué sur les
crédits accordés chaque année. Cela aide à ajuster les stratégies en fonction des conditions
du marché.

En utilisant le graphique en aire pour ces KPIs, nous obtenons une représentation visuelle
claire des tendances annuelles, facilitant ainsi l’analyse des fluctuations et des changements
au fil du temps comme montre la figure

Figure 5.54 – Graphique en aire

65
 • Montant total de crédit par année : Ce KPI présente le montant cumulé de tous les crédits
accordés chaque année. Il mesure l’exposition financière totale de notre banque.

Figure 5.55 – Graphique en ligne

5.5 Prédiction :

66