RapportNewFinalCopieMed Klibi

Remerciements
A l'issue de ce travail, nous remercions, en premier lieu, le bon Dieu de nous

avoir donné la force et le courage de le mener à terme.
Nous commençons par remercier Monsieur Chokri Chaaraoui, le directeur du

Système d’Informations, de nous avoir accueillis dans son établissement et
impliqués dans ce projet, ainsi que sa volonté de nous bien encadrer à travers ses
conseils et ses idées afin d’améliorer notre travail.
Nos remerciements les plus sincères s’adressent de même à Monsieur

Mohamed Manachou, Monsieur Rami Dridi nos encadrants professionnels pour
leurs conseils intéressants et leur encouragement continu.
Nous voulons exprimer notre gratitude et notre remerciement à Madame

Meriem Chekir notre encadrante à l'Ecole Supérieure Privée d’Ingénierie et de
Technologies (ESPRIT) par son soutien, par sa disponibilité et ses conseils.
Nous tenons à remercier également tous les responsables membres du jury

pour bien vouloir nous accorder de leur temps précieux pour commenter, discuter
et juger notre travail.
En fin, nous ne pouvons achever ce mémoire sans exprimer notre gratitude à

tout le cadre administratif, les professeurs de l'Ecole Supérieure Privée
d’Ingénierie et de Technologies (ESPRIT), pour leur assistance tout au long de
nos études de cycle d’Ingénieurs.
Dédicaces
Je dédie ce travail à…
Mon père Hassouna et Ma mère Fatma
A ce qu’est toujours mon meilleur exemple dans la vie : mon père

Hassouna, pour les sacrifices qu’il a consentis pour mon éducation et pour
l’avenir qu’il n’a cessé d’offrir,
Au symbole de douceur, de tendresse, d’amour et affection, et grâce au
sens du devoir et aux sacrifices immenses qu’elle a consentis : ma mère
Fatma, j’ai pu arriver à réaliser ce travail,
Ce travail est le fruit de vos sacrifices que vous avez consentis pour mon
éducation et ma formation.
Je vous dédie ce travail en témoignage de mon profond amour. Puisse
Dieu, le tout puissant, vous préserver et vous accorder santé, longue vie et
bonheur.
Mon cher petit frère Amine

Vous occupez une place particulière dans mon cœur. Je vous dédie ce
travail en vous souhaitant un avenir plein de joie, de bonheur et de succès.
A l’âme de ma chère tante Faouzia qui

nous a quitté brusquement
Je prie Dieu Tout Puissant de lui accorder Sa sainte miséricorde, de
l'accueillir en Son vaste paradis.
« Que son âme repose en paix »
A tous les membres de ma famille
Veuillez trouver dans ce modeste travail l’expression de mon affection.
A mes chers Amis

A ceux qui m’ont partagé le soutien moral durant l’élaboration du travail
de fin d’études avec tous mes vœux de bonheur, de santé et de réussite.
Liste des abréviations
Abréviation Désignation
BD Base de données
BI Business Intelligence
CGA Comité Général des Assurances
DSI Direction de Système d’Information
DWH Data Warehouse
ETL Extract-Transform-Load
KPI Key Performance Indicator
ISBI Information system and Business Intelligence
ODS Operational Data Store
OLE DB Object Linking and Embedding Database
RDI Recherche, Developpement et d'Innovation
SID Système d’information décisionnel
SQL Structured Query Language
SSDT SQL Server Data Tools
SSIS SQL Server Integration Services
TIC Technologie de l'information et de la communication
UML Unified Modeling Language

Résumé
Le présent rapport s’inscrit dans le cadre du projet de fin d’études pour l’obtention du
diplôme national d’ingénieur en informatique, effectué au sein de la DSI de l’école supérieure
privée d’ingénierie et de technologies en partenariat avec le Comité Général des Assurances. Il
consiste à la construction et la mise en place d'un système d'aide à la décision pour le CGA. Ce
système doit permettre aux décideurs, à travers les tableaux de bord, le contrôle et le suivi des
contrats d’assurance automobile et des sinistres.
Pour répondre à ces besoins nous décrivons les phases de la réalisation de notre solution en
suivant la méthodologie de Ralph Kimball qui s’adapte bien avec notre système décisionnel en
commençant par la planification et la spécification des besoins jusqu’à la réalisation des
tableaux de bords tout en présentant leurs valeurs ajoutées.
Mots clé : ETC (Extraction-Transformation-Chargement), Système d’aide à la décision,

entrepôt de données, magasin de données, Power BI, Tableaux de bord, DSI, CGA, Bonus-
Malus, Sinistres.
Abstract
This report is part of the graduation project for the national diploma of computer engineer,
carried out within the information system management of the Private Higher School of
Engineering and Technology in partnership with the General Insurance Committee. It consists
of building and setting up a decision support system for the GIC. This system must allow
decision makers to control and monitor new car insurance and claims through dashboards.
To answer these needs, we describe the phases of the realization of our solution following
the methodology of Ralph Kimball which adapts well with our decisional system starting with
the planning and the specification of the needs leading to the realization of the dashboards while
presenting their added values.
Keywords : ETL, Decision support system, Data Warehouse, Data Mart, Power BI, Dashboard,
Information System Management (ISM), General Insurance Committee (GIC), Bonus-Malus,
Losses.
Table des matières
Introduction Générale ............................................................................................................... 1

CHAPITRE I : Présentation du Projet ..................................................................................... 3
Introduction ....................................................................................................................................... 4
I. Contexte général ....................................................................................................................... 4
1. Présentation de l’Organisme d’accueil ................................................................................................. 4
2. Les missions de la Direction du Système d’Information ...................................................................... 5
II. Présentation de l’Organisme Intervenant .............................................................................. 6
1. Le Comité Général des Assurances ...................................................................................................... 6
2. Les missions du Comité Général des Assurance .................................................................................. 6
III. Cadre du projet .................................................................................................................... 7
1. Contexte du projet ................................................................................................................................ 7
2. Problématique ...................................................................................................................................... 7
3. Solution proposée ................................................................................................................................. 8
IV. Méthodologie de travail ....................................................................................................... 8
1. Le choix de la méthodologie de développement .................................................................................. 9
a. Caractéristiques majeures ................................................................................................................ 9
b. Avantages et inconvénients ............................................................................................................. 9
2. Définition de la méthodologie choisie (Ralph Kimball) .................................................................... 10
Conclusion ....................................................................................................................................... 12
CHAPITRE II : Planification du projet et Spécification des besoins ................................... 13
Introduction ..................................................................................................................................... 14
I. Planification du projet ........................................................................................................... 15
II. Spécification des besoins ........................................................................................................ 16
1. Identification des acteurs ................................................................................................................... 16
2. Besoins fonctionnels .......................................................................................................................... 16
3. Besoins non fonctionnels ................................................................................................................... 18
III. Diagramme de cas d’utilisation ........................................................................................ 19
1. Diagramme de cas d’utilisation général ............................................................................................. 19
2. Diagramme de cas d’utilisation raffiné .............................................................................................. 21
a. Description du cas d’utilisation du décideur ................................................................................. 21
b. Description du cas d’utilisation de l’administrateur ...................................................................... 22
Conclusion ....................................................................................................................................... 23
CHAPITRE III : Architecture et environnement technique ................................................. 24
Introduction ..................................................................................................................................... 25
I. Architecture technique........................................................................................................... 25
1. La phase de la collecte d’informations et préparation des données ................................................... 26
2. La phase de modélisation ................................................................................................................... 27
3. La phase de restitution ....................................................................................................................... 27
II. L’environnement technique................................................................................................... 28
1. StarUML ............................................................................................................................................ 28
2. MS VISIO 2016 ................................................................................................................................. 28
3. MS Project 2016 ................................................................................................................................ 29
4. SQL Server 2016................................................................................................................................ 29
5. SQL Server Data Tools (SSDT) pour visual studio 2015 .................................................................. 30
a. Le SQL Server Integration Services (SSIS) .................................................................................. 30
6. Tableau comparatif des outils de reporting ........................................................................................ 31
a. Power BI........................................................................................................................................ 31
Conclusion ....................................................................................................................................... 32
CHAPITRE IV : Préparation des données ............................................................................ 33
Introduction ..................................................................................................................................... 34
I. Modélisation dimensionnelle ................................................................................................. 35
1. Les tables de dimensions .................................................................................................................... 35
2. Définition des tables de faits .............................................................................................................. 38
II. Conception du modèle physique ........................................................................................... 39
III. Développement des éléments de la zone de préparation des données ........................... 43
1. Les connexions aux bases de données sources et destinations ........................................................... 43
2. Alimentation de l’ODS (Operational Data Store) .............................................................................. 43
3. Alimentation de la Data Warehouse................................................................................................... 45
a. Alimentation des dimensions ........................................................................................................ 46
b. Alimentation des tables de faits ..................................................................................................... 47
4. Déploiement du package SSIS ........................................................................................................... 48
5. La mise à jour automatique des données du Data Warehouse ........................................................... 51
Conclusion ....................................................................................................................................... 54
CHAPITRE V : Restitution des données ................................................................................ 55
Introduction ..................................................................................................................................... 56
I. Développement de l’application utilisateur.......................................................................... 56
1. Tableau de bord des compagnies d’assurance .................................................................................... 57
2. Tableau de bord des usages véhicule ................................................................................................. 58
3. Tableau de bord des classes Bonus-Malus ......................................................................................... 59
4. Tableau de bord des polices d’assurance ........................................................................................... 60
5. Tableau de bord des sinistres ............................................................................................................. 61
Conclusion ....................................................................................................................................... 62
CHAPITRE VI : Finalisation du système décisionnel .......................................................... 63
Introduction ..................................................................................................................................... 64
I. La publication de l’application utilisateur ........................................................................... 64
Conclusion ....................................................................................................................................... 66
Conclusion Générale ............................................................................................................... 67
Bibliographie et Webographie ................................................................................................ 68
Table des figures
Figure 1: Logo ESPRIT ........................................................................................................... 4

Figure 2: Organigramme d'Esprit Tech ................................................................................ 5
Figure 3: Logo CGA ................................................................................................................. 6
Figure 4: Cycle de vie de la solution décisionnelle selon l'approche Ralph Kimball ....... 10
Figure 5: Phase d'analyse selon le cycle de vie dimensionnel ............................................. 14
Figure 6: Diagramme de Gantt ............................................................................................. 15
Figure 7: Diagramme de cas d'utilisation global ................................................................. 19
Figure 8: Diagramme de cas d'utilisation d'un décideur.................................................... 21
Figure 9: Diagramme de cas d'utilisation d'un administrateur ......................................... 22
Figure 10: Phase d'architecture technique selon le cycle de vie dimensionnel ................. 25
Figure 11: Architecture technique de la solution décisionnelle ......................................... 26
Figure 12: Processus d'un ETL ............................................................................................. 27
Figure 13: StarUML............................................................................................................... 28
Figure 14: Microsoft Visio 2016 ............................................................................................ 28
Figure 15: Microsoft Project 2016 ........................................................................................ 29
Figure 16: Microsoft SQL Server 2016 ................................................................................ 30
Figure 17: Microsoft SQL Server Integration Services ...................................................... 30
Figure 18: Tableau comparatif des outils de reporting ...................................................... 31
Figure 19: Microsoft Power BI ............................................................................................. 32
Figure 20: Phase de la modélisation selon le cycle de vie dimensionnel ............................ 34
Figure 21: Dimension Assure ................................................................................................ 35
Figure 22: Dimension Police .................................................................................................. 35
Figure 23: Dimension Souscripteur ...................................................................................... 36
Figure 24: Dimension Véhicule ............................................................................................. 36
Figure 25: Dimension Bonus-Malus ..................................................................................... 36
Figure 26: Dimension Usage Véhicule .................................................................................. 37
Figure 27: Dimension Temps ................................................................................................ 37
Figure 28: Dimension Sinistre ............................................................................................... 37
Figure 29: Table de fait BonusMalus ................................................................................... 38
Figure 30: Table de fait Sinistres .......................................................................................... 39
Figure 31: Modèle du Data Warehouse (Schéma en constellation) ................................... 40
Figure 32: Modèle du Data Mart Bonus-Malus (Schéma en étoile) .................................. 41
Figure 33: Modèle du Data Mart Sinistres (Schéma en étoile) .......................................... 42
Figure 34: Interface de gestion de connexions SSIS............................................................ 43
Figure 35: Alimentation des tables de l'ODS ....................................................................... 44
Figure 36: Alimentation de la table "ODS_BonusMalus" ................................................. 44
Figure 37: Alimentation des dimensions et des tables de fait de la Data Warehouse ...... 45
Figure 38: Alimentation de la table DimPolice .................................................................... 46
Figure 39: Alimentation de la table de fait "FactBounsMalus" ........................................ 47
Figure 40: Alimentation de la table de fait "FactSinistres" ............................................... 48
Figure 41: Catalogue de services d'intégration ................................................................... 48
Figure 42: La première étape de déploiement ..................................................................... 49
Figure 43: La deuxième étape de déploiement .................................................................... 50
Figure 44: La dernière étape de de déploiement (Résultats) .............................................. 51
Figure 45: La création d'un job ............................................................................................ 52
Figure 46: L'ajout et la création d'une étape ....................................................................... 53
Figure 47: Planification du job ............................................................................................. 54
Figure 48: Phase de restitution selon le cycle de vie dimensionnel .................................... 56
Figure 49: Interface d'accueil de l'application décisionnelle de la CGA .......................... 56
Figure 50: Tableau de bord des compagnies d'assurance .................................................. 57
Figure 51: Tableau de bord des Usages Véhicule ................................................................ 58
Figure 52: Tableau de bord des classes Bonus-Malus ........................................................ 59
Figure 53: Tableau de bord des Polices d'assurance .......................................................... 60
Figure 54: Tableau de bord des Sinistres d'assurance ........................................................ 61
Figure 55: La phase de déploiement selon le cycle de vie dimensionnel ........................... 64
Figure 56: Déploiement sur Power BI .................................................................................. 65
Figure 57: Connexion à la passerelle et aux sources de données ....................................... 65
Figure 58: Planification automatique des données .............................................................. 66
Listes des tableaux
Tableau 1: Comparaison entre l'existant et la solution proposée ........................................ 8

Tableau 2: Caractéristiques majeures de l’approche Inmon et l’approche Kimball ........ 9
Tableau 3: Comparaison entre l’approche Inmon et l’approche Kimball ......................... 9
Tableau 4: Taches effectuées ................................................................................................. 15
Tableau 5: Description du diagramme de cas d'utilisation global..................................... 20
Tableau 6: Description du diagramme de cas d'utilisation d'un décideur ....................... 21
Tableau 7: Description du diagramme de cas d'utilisation d'un administrateur ............ 22
Introduction Générale
Dans un contexte où les technologies de l’information génèrent des données volumineuses
et complexes, les compagnies d’assurances se retrouvent confrontées à des difficultés qui
consistent à suivre leurs activités mais également lorsqu’il s’agit de prendre une décision rapide
et sûre, le problème n’est donc plus de les acquérir, mais de savoir traiter cette masse de
données.
Ainsi, le système d’aide à la décision ‘Business intelligence’ prend place au sein de la

direction des systèmes d’information de grandes entreprises. Il permettra à l’entreprise
d’assurer cet avantage par l’ensemble des moyens et méthodes. Il représente une opportunité
pour les assurances, d’optimiser le pilotage de leurs activités, d’anticiper sur les évolutions du
marché et de savoir le comportement de ses clients et ses consommateurs.
C’est dans ce contexte, où le Comité General des Assurances (CGA) souhaite se doter d’une
plateforme décisionnelle qui permettra de collecter et de traiter ses données, pour les
transformer en informations et les diffuser sous forme de tableaux de bord afin de garantir une
vue globale sur sa rentabilité.
Le présent rapport synthétisant tout le travail que j’ai réalisé au cours de mon projet s'articule
autour de six chapitres :
▪ Le premier chapitre intitulé ”Présentation du Projet” consiste à mettre le projet dans son
contexte, nous allons commencer par présenter l’organisme d’accueil et l’organisme
intervenant, par la suite nous allons analyser l’existant, aborder la problématique, proposer une
solution adéquate et parler de la méthodologie de développement choisie pour notre projet.
▪ Le deuxième chapitre ”Planification du projet et Spécification des besoins” portera sur
la planification des taches ainsi sur les besoins fonctionnels et non fonctionnels de notre
application.
▪ Le troisième chapitre ”Architecture et environnement technique” qui fera l’objet d’une
étude sur l’architecture technique ainsi qu’une présentation de l’outil sur lequel porte notre
projet.
1
▪ Le quatrième chapitre ” Préparation des données” sera dédié à la conception d’une

structure optimale de la data Warehouse et décrire les différentes phases qui ont abouti à sa
naissance.
▪ Le cinquième chapitre ” Restitution des données ” porte sur le développement de
l’application utilisateur qui se base sur des imprimes écrans des tableaux de bord de
l’application réalisée.
▪ Le dernier chapitre “Finalisation du système décisionnel“ porte sur le déploiement de
notre solution.
Finalement, ce rapport sera achevé par une conclusion générale qui présentera le bilan de ce
projet, les apports de point de vue savoir-faire ainsi que d’éventuelles perspectives.
2
CHAPITRE I : Présentation du Projet
Introduction
L’objectif de ce premier chapitre est de mettre ce travail dans son contexte général. Dans
un premier lieu, nous commencerons par présenter le cadre du projet. Puis, nous
présenterons l’organisme d’accueil et l’organisme intervenant et nous allons procéder à
l’étude de la solution existante au sein de la société. Ensuite, nous proposerons notre
solution passant par la livraison des critiques et problèmes existées. Enfin nous mettrons
l’accent sur la méthodologie à suivre.
I. Contexte général
Ce projet de fin d'études s’inscrit dans le cadre pour l’obtention du diplôme national
d’ingénieur en informatique, effectué au sein de la direction de système d’information (DSI) de
l’école supérieure privée d’ingénierie et de technologies (ESPRIT) en partenariat avec le
Comité Général des Assurances (CGA). Il consiste à la construction et mise en place d'un
système d'aide à la décision pour le Comité General Des Assurances : les contrats d’assurance
automobile et les sinistres.
1. Présentation de l’Organisme d’accueil
Figure 1: Logo ESPRIT
ESPRIT « Ecole Supérieure Privée d’Ingénierie et de Technologies » est une école

d’ingénierie pluridisciplinaire, créée afin de renforcer le système national des études
d’ingénieur et de diversifier les modes de formation en misant particulièrement sur
l’alternance et l’apprentissage. Sa vocation consiste entre autres, à enseigner les
technologies de l’information et de la communication (TIC). ESPRIT a renforcé ces atouts
par une pédagogie innovante orientée « projets ». En effet, elle a pour mission de contribuer
à des actions de recherche et de développement dans le cadre de projets nationaux et
internationaux. C’est dans ce cadre qu’ESPRIT a créé l’unité de Recherche,
4
Développement et d’Innovation (RDI) : ESPRIT-TEC, au sein de laquelle notre projet de

fin d’études a vu le jour.
Les projets choisis au sein de l’unité de l’RDI mobilisent des équipes de plusieurs
chercheurs, enseignants chercheurs, ingénieurs et étudiants en projet de fin d’études sous
la conduite d’un chef de projet. Des étudiants en PFE, mastère ou doctorat d’autres
institutions peuvent aussi être intégrés dans les équipes de projets dans le cadre de
convention et de partenariat avec d’autres labos et/ou unités de recherche des établissements
publics.
Notre projet a été réalisé au sein de la direction des systèmes d’information et

informatique décisionnelle (ISBI : Information system and Business Intelligence), il entre
également dans le cadre du besoin d’interne d’Esprit en collaboration avec le CGA.
Figure 2: Organigramme d'Esprit Tech
2. Les missions de la Direction du Système d’Information

La DSI a pour mission le suivi, la mise en cohérence et le développement du Système
d’Information global (SI) de l’université, dont les orientations stratégiques et les priorités
sont définies par le comité de pilotage du SI. Elle est chargée de la maîtrise d’œuvre des
projets définis par ce comité devant lequel elle rend compte de l’état d’avancement des
travaux. Elle assure également un rôle d’assistance à la maîtrise d’ouvrage auprès de ce
comité, de la direction et des instances de l’université.
Dans ce cadre, elle est chargée de l’établissement et de la mise en œuvre du schéma

directeur, mettant en cohérence les initiatives prises et les projets portés par les différents
acteurs en rationalisant l’utilisation des moyens techniques et humains dont dispose
l’université.
5
II. Présentation de l’Organisme Intervenant

Comme nous avons déjà mentionné, ce projet a été au sein de la DSI de l’école supérieure
privée d’ingénierie et de technologies en partenariat avec le Comité Général des Assurances.
1. Le Comité Général des Assurances

Le Comité Général des Assurances [1], est un organisme doté de la personnalité morale et
de l'autonomie financière et qui relève du Ministère des Finances.
Il a pour objectifs de protéger les droits des assurés et de sauvegarder les capacités des
entreprises d’assurances et de réassurances à honorer leurs engagements. Il intervient dans le
Contrôle des entreprises d’assurances et de réassurances et des professions liées au secteur,
dans le Suivi de l’activité du secteur, dans l'étude de toutes les questions d’ordre juridique et
technique se rapportant aux opérations d’assurances et de réassurances et préparation des textes
y afférant, dans l'étude de toutes les questions relatives au développement et à l’organisation du
secteur et enfin dans le suivi de l’activité du secteur des associations mutuelles (approbation
des statuts et contrôle de l’activité). Le CGA effectue ses procédures de contrôle sur pièce sur
la base des dossiers annuels des entreprises d’assurances, ou bien sur place, par des contrôleurs
accrédités et sans ordre de mission préalable.
Figure 3: Logo CGA
2. Les missions du Comité Général des Assurance

Le Comité Général des Assurances veille à la protection des droits des assurés et des
bénéficiaires des contrats d’assurance et à la solidité de l'assise financière des entreprises
d’assurance et des entreprises de réassurance et leur capacité à honorer leurs engagements. [2]
Dans le cadre des missions qui lui sont attribuées, le comité est chargé notamment :
• Du contrôle des entreprises d’assurances, des entreprises de réassurance et des

professions liées au secteur des assurances et du suivi de leurs activités,
• De l'étude des questions d'ordre législatif, réglementaire et organisationnel se

rapportant aux opérations d'assurance et de réassurance, aux entreprises d'assurance et
6
aux entreprises de réassurance que lui soumet le ministre des finances et de l'élaboration
des projets de textes y afférents sur sa demande,
• De l'étude des questions d’ordre technique et économique se rapportant au

développement du secteur des assurances et à son organisation et la présentation de
propositions à cet effet au ministre des finances,
• Et en général, d'étudier et d'émettre son avis sur toute autre question relevant de
ses attributions.
III. Cadre du projet

L'une des principales missions du CGA est de collecter et centraliser des données issues des
compagnies d’assurances, il doit donc se procurer des solutions mettant en place une
architecture qui facilitera, à travers une vision métier, la prise de décision grâce à des outils
d'analyse. C'est ainsi que ce projet a vu le jour.
1. Contexte du projet
Le sujet du projet consiste à concevoir et mettre en place d’un système d’aide à la décision
dédiée à l’analyse et le suivi des opérations sur le marché en matière d’assurance pour les
contrats d’assurance du système Bonus-Malus et les sinistres.
L'information résultante assurée par cette solution décisionnelle doit être présentée de
manière compréhensible pour l'utilisateur final. En effet, afin d'être plus réactif, il est nécessaire
de donner à l'utilisateur les moyens d'être autonome, en lui permettant de naviguer dans
l'information en fonction des questions qu'il se pose.
2. Problématique
Suite à une croissance exponentielle du volume des données et des informations qui doivent
être assurées par une assurance, le CGA a rencontré des problèmes de suivi et d’analyse dans
le domaine de l’assurance automobile.
Parmi lesquelles, nous citons :
• Le calcul de certaines données se fait d’une manière manuelle ce qui peut donner des
résultats incorrects.
• L’analyse des données et la création des rapports se font à la fin de chaque mois et non
au jour même ce qui engendre un grand retard pour agir.
• L’interface offerte par Excel est limitée.
7
• Vu que les données de suivi mensuelles des compagnies d’assurance sont enregistrées
dans plusieurs fichiers Excel séparés, ceci engendre une perte de temps au niveau de suivi des
KPI et une possibilité de perte des données.
3. Solution proposée
La solution visée est un système d’information décisionnel tout en conférant aux décideurs
un support fiable pour une meilleure prise de décision concernant le suivi des compagnies
d’assurances ainsi, les principaux objectifs assignés au projet sont :
• Collecter toutes les informations de toutes les compagnies d’assurance dans une base de
données en assurant leur persistance et les empêcher d’être perdues.
• Offrir des informations fiables, cohérentes et pertinentes grâce à l’automatisation des

calculs.
• Diffuser les données et mettre à jour les rapports quotidiennement.
• Offrir à un responsable la possibilité de faire des analyses appropriées selon plusieurs axes.
• Faciliter la prise de décision grâce à des indicateurs pertinents.
• Réduire les coûts de la procédure de l’analyse et de Reporting actuelle.
Les fonctionnalités offertes par notre solution sont exprimées dans le tableau [1] :
Fonctionnalité Existant Solution
L’automatisation du calcul des indicateurs. Non Oui
L’historisation des données. Non Oui
L’automatisation des rapports. Non Oui
La mise à jour des rapports automatique chaque jour. Non Oui
Tableau 1: Comparaison entre l'existant et la solution proposée
IV. Méthodologie de travail

Un projet décisionnel nécessite un savoir-faire propre et une méthodologie adaptée à un
projet dont la réussite repose avant tout sur des aspects fonctionnels et une très forte implication
des utilisateurs.
8
1. Le choix de la méthodologie de développement

Lors de la conception d’un datawarehouse, deux approches se confrontent : la méthode de
Bill Inmon et celle de Ralph Kimball [3], chacune adaptée à son environnement d’intégration
et présentant ses avantages et inconvénients.
a. Caractéristiques majeures
Le tableau [2] présente les caractéristiques majeures des deux approches :
Inmon Kimball
Commence par la conception du modèle de DW Commence par la conception du modèle dimensionnel
pour les datamarts
Architecture composée d’un staging area Architecture qui consiste en un staging area et de
permanent, d’un DW et de datamarts dépendants datamarts, le DW physique n’existe pas
Le DW est orienté entreprise et les datamarts sont Les datamarts contiennent les données atomiques et
orientés processus agrégées
Le DW contient les données atomiques ; les Les datamarts peuvent fournir une vue entreprise ou
datamarts et les données agrégées processus
Le DW utilise un modèle normalisé de toute Les datamarts sont implémentés de façon incrémentale
l’entreprise ; les datamarts utilisent des données et intégrée en utilisant les dimensions conformes
dimensionnelles orientés sujet
Les utilisateurs peuvent effectuer des requêtes sur
le DW et les datamarts
Tableau 2: Caractéristiques majeures de l’approche Inmon et l’approche Kimball
b. Avantages et inconvénients
Le tableau [3] présente la comparaison entre les deux approches :
Inmon Kimball
Construction Couteux en temps Rapide
Maintenance Facile Difficile redondance à gérer
Cout Coût initial élevé Cout initial modéré
Durée mise en œuvre Long Court si mode incrémental
Compétences utiles Equipe spécialisée Equipe généraliste
Intégration des données Au niveau entreprise Par domaine métier
Tableau 3: Comparaison entre l’approche Inmon et l’approche Kimball
Après avoir étudié les deux approches et malgré l'opposition effective des deux modèles,
nous avons choisi l’approche de Ralph Kimball qui est la plus adéquate pour notre projet vu
qu’elle s’adapte mieux à nos besoins en termes de compétences, de temps, de coût et d’exigence
en ce qui concerne l’intégration de données.
9
2. Définition de la méthodologie choisie (Ralph Kimball)

Ralph Kimball est un informaticien et chef d’entreprise américain. Il est connu comme
auteur d’ouvrages informatiques, notamment sur le thème du décisionnel. Son approche est
basée sur la méthodologie de modélisation dimensionnelle qui permet de faire un requêtage
facile et performant pour les utilisateurs.
Les étapes du cycle de vie d’un projet décisionnel selon l’approche de Kimball sont illustrées
dans la « figure 4 ».
Définition de Installation et
l architecture selection des
technique produits
Conception et
Définition des Conception du développement
Planification du Modélisation des éléments de la Maintenance
besoins de modèle Déploiement
projet dimensionnelle zone de et croissance
l entreprise physique
préparation des
données
Spécification de Développement de
l application l application
utilisateur utilisateur
Gestion du projet
Figure 4: Cycle de vie de la solution décisionnelle selon l'approche Ralph Kimball

Les phases de cette méthodologie sont :
1. Planification du projet :
La planification du projet a une influence sur la définition et la portée du projet. Elle dépend
des besoins, comme indiqué par la flèche à double sens reliant ces deux activités.
2. Définition des besoins de l’entreprise :

Les besoins de l’entreprise peuvent se définir par la bonne compréhension des utilisateurs et
de leurs besoins, ainsi comprendre les facteurs clés qui conduisent l’entreprise à vouloir
déterminer ses besoins et traduire les facteurs pour les intégrer lors de la phase de conception.
3. Définition de l’architecture technique :

Définir les outils et les technologies nécessaires pour l’intégration et le développement dans
un environnement de datawarehouse et fournir une vision globale de la structure de
l'architecture technique à mettre en œuvre.
10
4. Installation et sélection des produits :

En se basant sur l’architecture technique, et en répondant aux besoins de notre projet nous
avons choisi de définir l’outil sur lequel se base notre projet.
5. Modélisation dimensionnelle des données :
• En premier lieu : définir la méthodologie choisie ainsi que les différents modèles.
• En deuxième lieu : la conception du modèle multidimensionnel : Identification des
faits et des dimensions.
• En dernier lieu : définir les dimensions ainsi que les mesures.
6. Conception du modèle physique de données :

Définir les structures physiques nécessaires pour l’implémentation de la base de données
logique.
7. Conception et développement des éléments de la zone de préparation des données :

Préparation des dimensions et de la table des faits ainsi, l’implémentation de l’ETL
(l’extraction, la transformation et le chargement des données).
8. Spécification de l’application utilisateur :

Préparation des maquettes d’états selon les critères de l’utilisateur.
9. Développement de l’application utilisateur :

Développement des tableaux de bords qui vont répondre aux besoins de l’utilisateur à partir
de l’ETL.
10. Déploiement :
Convergence de la technologie, des données, et des applications utilisateurs accessibles à
partir du poste de travail et mise en place des processus de communication, support utilisateur,
prise en compte des demandes d’évolution ou de correction.
11. Maintenance et croissance :

Assurer le fonctionnement optimal du système et fournir un service de support et une formation
continue.
12. Gestion du projet :
Garantir le bon déroulement et la synchronisation des activités du cycle de vie dimensionnel
et contrôler l’état d’avancement du projet, Ainsi, détecter et résoudre les problèmes et contrôler
les changements.
11
Conclusion
Ce chapitre a été consacré pour la description du contexte général de notre mission à savoir
les organismes d'accueil ainsi que le cadre du projet. Il sera suivi par un chapitre spécifiant les
besoins ainsi que les objectifs de notre application.
12
CHAPITRE II : Planification du projet
et Spécification des besoins
CHAPITRE II : Planification du projet et Spécification des besoin
Introduction
Ce chapitre matérialise l’étape de spécification des besoins qui consiste à la planification du
projet et les besoins fonctionnels et non fonctionnels ainsi que les diagrammes de cas
d’utilisation pour mettre en évidence les relations fonctionnelles entre les acteurs et le système.
Dans la « figure 5 », nous présentons la planification et les besoins de notre solution suivant
le cycle de vie dimensionnel.
Définition de Installation et
l architecture selection des
technique produits
Conception et
Définition des Conception du développement
Planification du Modélisation des éléments de la Maintenance
besoins de modèle Déploiement
projet dimensionnelle zone de et croissance
l entreprise physique
préparation des
données
Spécification de Développement de
l application l application
utilisateur utilisateur
Gestion du projet
Figure 5: Phase d'analyse selon le cycle de vie dimensionnel
14
I. Planification du projet
Le diagramme de Gantt présenté dans la « figure 6 », expose la planification prévisionnelle
définie afin de répondre à la problématique posée.
Figure 6: Diagramme de Gantt

Pour mieux comprendre le diagramme de GANTT réalisé, nous présentons dans le tableau
[4] les différentes tâches réalisées dans notre stage, leurs dates de début et de fin :
Tache Date début Date fin

Planification du projet 23/04/2018 30/04/2018
Etude sur le domaine de l’assurance 30/04/2018 07/05/2018
Spécification des besoins 07/05/2018 21/05/2018
Modélisation et développement du modèle 21/05/2018 31/05/2018
Conception du modèle physique 31/05/2018 11/06/2018
Préparation des données 12/06/2018 22/07/2018
Développement de l’application utilisateur 23/07/2018 16/08/2018
Déploiement 16/08/2018 17/08/2018
Rédaction du rapport 02/07/2018 22/09/2018
Tableau 4: Taches effectuées
15
II. Spécification des besoins

La spécification des besoins représente la première phase du cycle de développement d'un
système décisionnel. C’est au cours de celle-ci que les besoins de l’utilisateur sont identifiés et
précisés. Ces besoins représentent aussi les fonctionnalités à réaliser dans le système. Dans ce
chapitre, nous allons évoquer les besoins fonctionnels et non fonctionnels de notre projet dans
un premier lieu et établir le diagramme de cas d’utilisation global dans un second lieu.
1. Identification des acteurs

Un acteur est une abstraction d’une entité externe au système. En général, il permet
d’interagir avec ce système. Ainsi, il peut lire ou modifier des informations et il ne peut être
qu’un utilisateur humain ou un système connexe qui interagit avec l’application courante.
Administrateur : C’est la personne qui tient en charge l’administration de notre système.
• Gestion des données.

• Gestion des tableaux de bord.
Utilisateur (Décideur) : C’est la personne en charge de la modification et la consultation

des tableaux de bord et de la prise de décision.
2. Besoins fonctionnels
Afin d'améliorer la prise de décision et satisfaire les besoins du client, notre solution doit assurer
certaines fonctionnalités :
• Intégration des données :
Pour faire l’intégration des données nous commençons par l’exécution de la partie ETL
(Extraire, transformer et charger les données) à partir des sources de données dont le but
est de concevoir un modèle dimensionnel qui va aider le client à avoir une nouvelle
structure de ses données suivant ses besoins.
• Visualisation des rapports et des indicateurs de performance.

• Mise à jour automatique et exécution des jobs au sein de l’entrepôt des données afin
d’assurer l’actualisation des informations.
• Réalisation des tableaux de bord :
Après avoir créé le modèle dimensionnel nous pouvons passer à la phase de restitution
pour répondre aux besoins du client.
16
• Générer une analyse selon les compagnies des assurances :

− Suivre le nombre des contrats Bonus-Malus par compagnie d’assurance.
− Suivre le nombre des contrats Bonus-Malus par mois.
− Suivre le nombre des bonus.
− Suivre le nombre des malus.
− Suivre le nombre des assures.
− Suivre le nombre des polices.
− Suivre le nombre des agences.
• Générer une analyse des polices de l’assurance (par type et nature) :
− Suivre l’évolution du nombre de contrats Bonus-Malus des polices par compagnie
d’assurance.
− Suivre l’évolution du nombre de contrats Bonus-Malus de type police par mois.
− Suivre l’évolution du nombre de contrats Bonus-Malus de nature police par mois.
− Suivre le nombre des assures par type et nature police.
− Suivre le nombre des polices par type et nature police.
− Suivre le nombre des véhicules par type et nature police.
• Générer une analyse des classes Bonus-Malus :
− Suivre l’évolution du nombre de contrats Bonus-Malus des classes par mois.
− Suivre l’évolution du nombre de contrats Bonus-Malus des classes par compagnie
d’assurance.
− Suivre le nombre des assures par classe Bonus-Malus.
− Suivre le nombre des polices par classe Bonus-Malus.
− Suivre le nombre des véhicules par classe Bonus-Malus.
• Générer une analyse par usage (privé ou autres usages) des classes Bonus-Malus :
− Suivre l’évolution des Bonus par rapport aux Malus des usages par mois.
− Suivre l’évolution des usages véhicules par mois.
− Suivre l’évolution du nombre de contrats Bonus-Malus des usages véhicules par
compagnie d’assurance.
− Suivre le taux des contrats Bonus-Malus par usages véhicules.
− Suivre le nombre des véhicules par usages véhicules.
− Suivre le nombre des marques véhicules par usages véhicules.
17
• Générer une analyse des sinistres :

− Suivre l’évolution des sinistres par mois.
− Suivre l’évolution des sinistres par compagnie d’assurance.
− Suivre le taux des sinistres par nature.
3. Besoins non fonctionnels

Une fois les besoins fonctionnels sont spécifiés, il est très important de passer à la
spécification non fonctionnelle. Il s’agit des besoins qui représentent les exigences implicites
qui décrivent les critères de qualité auquel le système doit répondre.
• La présentation ergonomique des données : Les tableaux de bord doivent être faciles à
utiliser. En effet, les interfaces utilisateurs doivent être conviviales en d’autres termes simples,
ergonomiques et adaptées à l'utilisateur.
• La fiabilité : Les rapports générés doivent être bien précis et basés sur des données exactes.
• L’aptitude à la maintenance : L'application doit être facile à maintenir.
• La performance et la disponibilité : notre système d’aide à la décision doit être performant
notamment à travers ses fonctionnalités, il doit répondre aux exigences des usagers et assurer
la disponibilité des services et Intégrité des données.
18
III. Diagramme de cas d’utilisation

Les diagrammes de cas d’utilisation permettent de décrire le comportement de système de
point de vue utilisateur. Ils permettent aussi de structurer les besoins des utilisateurs et les
objectifs de système ainsi que décrire l’interaction entre le système et ses acteurs.
1. Diagramme de cas d’utilisation général

Pour mener à bien notre projet, nous avons choisi d’utiliser la méthodologie UML (Unified
Modeling Language) pour concevoir le diagramme de cas d’utilisation de notre système
décisionnel.
Figure 7: Diagramme de cas d'utilisation global
19
Le tableau [5] présente la description détaillée du cas d’utilisation général.
Acteur Actions Description
Décideur Consulter les tableaux de bord Permet aux décideurs de visualiser

les tableaux de bord déployés.
Décideur Modifier les tableaux de bord Permet de modifier les tableaux de

bord selon les besoins.
Administrateur Gérer les tableaux de bord Permet à l’administrateur de mettre

en place un nouveau rapport ou
modifier un autre et le faire
déployer selon les besoins.
Administrateur Consulter les tableaux de bord Permet à l’administrateur de

consulter les tableaux de bord et
donner une vue claire au client.
Administrateur Gérer l’ETL Permet à l’administrateur de gérer

les données (extraction,
transformation et chargement des
données) et de faire le déploiement
et la mise à jour automatique de ces
derniers pour avoir un modèle
adapté au besoin du client.
Décideur/Administrateur Authentification Le décideur et l’administrateur

doivent s’authentifier pour accéder
à la solution.
Tableau 5: Description du diagramme de cas d'utilisation global
20
2. Diagramme de cas d’utilisation raffiné

a. Description du cas d’utilisation du décideur
Le diagramme de cas d’utilisation présenté dans cette « figure 8 » détaille le cas d’utilisation
du décideur.
Figure 8: Diagramme de cas d'utilisation d'un décideur
Le tableau [6] présente la description détaillée du cas d’utilisation du décideur.
Actions Description
Choisir les axes d’analyse Le décideur doit choisir les dimensions à analyser.
Analyser les tableaux de bord Permet d’analyser les tableaux de bord selon des critères prédéfinis.
Exporter les données Permet l’exportation des données en plusieurs formats.
Modifier le tableau de bord Permet de modifier les tableaux de bord selon le besoin du client.
Publier le tableau de bord Le décideur doit publier les tableaux de bord modifiés.
Tableau 6: Description du diagramme de cas d'utilisation d'un décideur
21
b. Description du cas d’utilisation de l’administrateur

Le diagramme de cas d’utilisation présenté dans cette « figure 9 » détaille le cas d’utilisation
de l’administrateur.
Figure 9: Diagramme de cas d'utilisation d'un administrateur
Le tableau [7] présente la description détaillée du cas d’utilisation de l’administrateur.
Actions Description
Planifier l’ETL Permet de faire le planning et de lancement des jobs de l’alimentation

de l’entrepôt des données.
Modifier l’ETL Permet de faire les transformations nécessaires des dimensions et de

la table des faits pour avoir des données bien intégrées et nettoyées.
Exécuter l’ETL Permet de faire le chargement des données.
Ajouter, modifier et supprimer le Permet la création, la modification ou la suppression d’un tableau de

tableau de bord bord selon le besoin du client.
Publier le tableau de bord L’administrateur doit publier les tableaux de bord crées ou modifiés.
Tableau 7: Description du diagramme de cas d'utilisation d'un administrateur
22
Conclusion
Dans ce chapitre, nous nous sommes intéressés à la spécification des besoins qui procurent
une compréhension plus profonde des tâches à réaliser.
Ces besoins vont être la base sur laquelle nous allons réaliser la conception de notre système.
Cette conception fera l’objet du chapitre suivant.
23
CHAPITRE III : Architecture et
environnement technique
CHAPITRE III : Architecture et environnement technique
Introduction
Après la phase de spécification des besoins décrits dans le chapitre précédent, nous allons
nous intéresser dans ce chapitre à la partie concernant l'architecture technique et la sélection et
l’installation des produits.
Dans la « figure 10 », nous présentons l’environnement technique de notre solution suivant

le cycle de vie dimensionnel.
Figure 10: Phase d'architecture technique selon le cycle de vie dimensionnel
I. Architecture technique
La mise en place d’un système décisionnel selon notre méthodologie repose sur une
architecture bien définie détaillant le processus depuis le stockage des données jusqu’à leur
restitution. Tout ceci, en gardant constamment à l’esprit que c’est le besoin spécifique de
l’utilisateur qui doit être la finalité de l’outil.
25
La « figure 11 » montre une illustration de l’architecture et des composants principaux d'un

système BI :
ODS
Data Mart
(Contrats Bonus-Malus)
Datawarehouse
ETL
Data Mart (Sinistres)
Collecte d informations Intégration Modélisation Restitution
Figure 11: Architecture technique de la solution décisionnelle
1. La phase de la collecte d’informations et préparation des

données
La phase de la collecte et de préparation des données est primordiale [4]. C’est une étape qui
permet de détecter, de sélectionner, d’extraire et de filtrer les données brutes issues des
environnements pertinents pour obtenir des indicateurs utiles dans le cadre de l’aide à la
décision. Ces données applicatives sont donc extraites, transformées et chargées dans un
entrepôt de données par un outil de type ETL (Extract-Tranform-Load) ou en français ETC
(Extraction-Transformation-Chargement).
26
La « figure 12 » permet de mieux comprendre le processus ETL qui est considéré comme le
plus important pour garantir la fiabilité des données chargées dans notre entrepôt de données.
Processus ETL
Source Destination
Extract Transform Load
Figure 12: Processus d'un ETL

L'ETL (Extract-Transform-Load) est un processus d'intégration des données qui permet de
transférer des données brutes d'un système source, de les préparer pour une utilisation en aval
et de les envoyer vers une base de données, un entrepôt de données ou un serveur cible.
2. La phase de modélisation
Dans cette phase nous avons des données stockées dans l’entrepôt de données ou
datawarehouse sous une forme adaptée pour les analyses. Elle fait aussi intervenir les notions
de cubes et de datamarts nécessaires pour répondre aux questions des décideurs.
3. La phase de restitution
Après l’intégration et la modélisation au niveau de l’entrepôt de données, l’étape suivante
est appelée reporting, durant cette phase nous allons présenter les données sous forme de
tableaux de bord pour permettre aux utilisateurs finaux de les analyser et les interpréter.
27
II. L’environnement technique

1. StarUML
StarUML [5] est un logiciel de modélisation UML, cédé comme open source par son éditeur,
à la fin de son exploitation commerciale, sous une licence modifiée de GNU GPL. Il gère la
plupart des diagrammes spécifiés dans la norme UML 2.0.
Figure 13: StarUML
2. MS VISIO 2016
Visio 2016 [6] est une puissante application de création de diagrammes qui vous permet de
créer visuellement toutes sortes de diagrammes. Avec plus de 12 millions d'utilisateurs, elle est
leader du secteur. Visio 2016 facilite la définition des processus métier, la documentation des
meilleures pratiques, la visualisation de l'état d'avancement des initiatives de transformation et
la maîtrise des connaissances opérationnelles de votre entreprise. En utilisant Office 365, vous
pouvez partager des diagrammes Visio avec tout le monde et communiquer une version de la
vérité pour pousser l’alignement à l’échelle de l’organisation.
Figure 14: Microsoft Visio 2016
28
3. MS Project 2016
Microsoft Project (ou MS Project ou MSP) [7] est un logiciel de gestion de projets édité
par Microsoft. Il permet aux chefs de projets et aux planificateurs de planifier et piloter les
projets, de gérer les ressources et le budget, ainsi que d'analyser et communiquer les données
des projets.
Figure 15: Microsoft Project 2016
4. SQL Server 2016

SQL Server [8] est un système de gestion de base de données (SGBD) développé et
commercialisé par Microsoft depuis 1994. Il représente le service central de la suite Microsoft
SQL Server et permet de stocker, traiter et sécuriser les données. Le moteur de base de données
permet de contrôler les accès et de traiter rapidement les transactions pour répondre aux besoins
des applications consommatrices de données les plus exigeantes d’une entreprise.
Parmi les fonctionnalités principales de SQL Server :
• Gestion de bases de données relationnelles.

• Gestion et déploiement centralisé de plusieurs instances et applications depuis un seul
point de contrôle.
• Optimisation de stockage des bases de données volumineuses (tables et indexes
partitionnées, compression de données, …).
• Prise en charge des données géographiques.
• Gestion de la haute disponibilité.
• Ordonnanceur intégré (SQL Agent).
29
• Service de notification.
• Gestion de la réplication.
• Prise en charge de la virtualisation.
• Gestion de la sécurité.
Figure 16: Microsoft SQL Server 2016

Vu que notre source de données est le backup de la solution « CGA » qui est de type .bak
adapté que sur SQL Server 2016, et que nous avons besoin d’un système de gestion de base de
données relationnel et à la fois multidimensionnel. Nous avons choisi d’utiliser SQL Server ;
plus précisément SQL Server Management studio 2016.
5. SQL Server Data Tools (SSDT) pour visual studio 2015

SQL Server Data Tools, SSDT, anciennement BIDS (Business Intelligence Development
Studio) est l’utilitaire permettant de créer les lots SSIS, de concevoir des cubes SSAS et des
rapports SSRS.
a. Le SQL Server Integration Services (SSIS)

Le SSIS gère l’extraction et l’enregistrement des données en dehors de l’outil de production.
Il joue donc le rôle d’un ETL (Extract, Transform and load) et y ajoute toute une série d’outils
pour monitorer la performance des processus d’extraction et de transformation de la donnée.
Figure 17: Microsoft SQL Server Integration Services
Nous avons choisi d’utiliser l’outil SSIS car il possède de nombreux connecteurs disponibles
(Oracle, Teradata, SAP, CRM …), en plus il dispose d’une interface d’administration complète
30
et facile à utiliser vu qu’il est très visuel. Aussi, il permet de nous faciliter le déploiement en
présence d’instances SQL Server.
6. Tableau comparatif des outils de reporting

La figure ci-dessous présentera un tableau comparatif des outils utilisés pour le reporting.
Figure 18: Tableau comparatif des outils de reporting
Nous avons choisi d’utiliser Power BI pour le Reporting car il nous a permis d’incorporer
facilement des visuels de données interactifs et de fournir des rapports exceptionnels avec une
haute-fidélité sur tous les appareils. Ainsi, il nous a offert la possibilité de générer les rapports
dans un site web et de les partager avec notre organisation tout en gardant leur sécurité.
a. Power BI
Power BI [9], lancé en juillet 2015, est une suite d’outils BI axée sur la visualisation de
données interactives et le partage d’information.
Ses principales fonctionnalités :
• Création de rapports et tableaux de bord interactifs et très visuels (il existe de

nombreuses visualisations natives ou à télécharger).
• Création de rapports à partir de différentes sources de données : Fichier (Excel, csv,

JSON…), bases de données (SQL Server, Analysis Services, SAP HANA…), Azure
31
(Azure HDInsight, Azure SQL Data Warehouse, …), services en ligne (google
analytics, facebook, dynamics CRM online, …).
• Possibilité de créer des modèles de rapports.
• Publication, centralisation et facilité d’accès des rapports sur le service web.
• Partage les visualisations, rapports et tableaux de bords via Power BI Service.
• Edition des rafraichissements de données via Power BI Service.
• Visualisation des Reportings sur plusieurs devices via Power BI Mobile.
Figure 19: Microsoft Power BI
Conclusion
Dans ce chapitre, nous avons détaillé l’architecture technique du notre projet en expliquant
ses différentes phases. Par la suite, nous avons défini l'environnement du travail et les
technologies adoptées pour la réalisation de notre projet.
Dans le chapitre suivant intitulé « Analyse et modélisation de l’entrepôt des données » nous
allons présenter la conception du modèle physique ainsi que la conception et le développement
de la zone de préparation des données.
32
CHAPITRE IV : Préparation des
données
CHAPITRE IV : Préparation des données
Introduction
Dans ce chapitre, nous présentons la modélisation dimensionnelle et la conception de la zone
de préparation des données du cycle de vie décisionnel.
Dans la « figure 20 », nous présentons la phase de préparation des données de notre solution
suivant le cycle de vie dimensionnel.
Figure 20: Phase de la modélisation selon le cycle de vie dimensionnel
34
I. Modélisation dimensionnelle
Dans cette section, nous présentons les différents éléments nécessaires pour la modélisation
dimensionnelle :
• Les tables de dimensions.

• Les tables de faits.
1. Les tables de dimensions

Dimension Assure :
Cette dimension contient des informations relatives à l’assure.
Figure 21: Dimension Assure
Dimension Police :
Cette dimension contient des informations relatives à la police d’assurance.
Figure 22: Dimension Police
35
Dimension Souscripteur :
Cette dimension contient des informations relatives au souscripteur.
Figure 23: Dimension Souscripteur
Dimension Véhicule :
Cette dimension contient des informations relatives au véhicule.
Figure 24: Dimension Véhicule
Dimension Bonus-Malus :
Cette dimension contient des informations relatives au bonus-malus.
Figure 25: Dimension Bonus-Malus
36
Dimension des usages véhicule :

Cette dimension contient des informations relatives à l’usage véhicule.
Figure 26: Dimension Usage Véhicule
Dimension Temps :
Cette dimension contient les informations nécessaires liées à la date et nous offre beaucoup
d’axes d’analyse à savoir (date, jour de la semaine, le mois et l’année …).
Figure 27: Dimension Temps
Dimension Sinistre :
Cette dimension contient des informations relatives au sinistre de l’assurance.
Figure 28: Dimension Sinistre
37
2. Définition des tables de faits

La table de fait contient toutes les clés des tables de dimensions et les mesures nécessaires
pour l’analyse et les tableaux de bords.
Dans notre Solution, nous avons deux tables de faits :
• Data Mart des contrats Bonus-Malus : Fait Bonus-Malus.

• Data Mart des sinistres : Fait Sinistre.
Table de fait Bonus-Malus :
Figure 29: Table de fait BonusMalus
Les mesures à analyser dans cette table sont les suivantes :

• Nombre des contrats Bonus-Malus.
• Nombre des assures.
• Nombre des voitures.
• Nombre des Marques.
• Nombre des polices.
• Nombre des agences de l’assurance.
• Nombre des Bonus.
• Nombre des Malus.
38
Table de fait Sinistre :
Figure 30: Table de fait Sinistres
La mesure à analyser dans cette table est :

• Nombre des sinistres
II. Conception du modèle physique

Dans notre solution nous utilisons comme modèle d’entrepôt des données :
• Le modèle en constellation.
Ce modèle répond mieux à nos besoins car il y a deux tables de faits du modèle en étoile
(FactBonusMalus, FactSinistres) qui ont des tables de dimensions communes (DimPolice,
DimVehicule, DimAssure, DimTemps).
39
La « figure 31 » présentera le modèle physique de données pour notre data Warehouse.
Figure 31: Modèle du Data Warehouse (Schéma en constellation)
40
La « figure 32 » présentera le modèle physique de données qui est un modèle en étoile pour
la première Data mart des contrats Bonus-Malus.
Figure 32: Modèle du Data Mart Bonus-Malus (Schéma en étoile)
41
La « figure 33 » présentera le deuxième modèle physique de données qui est un modèle en

étoile du Data mart des sinistres.
Figure 33: Modèle du Data Mart Sinistres (Schéma en étoile)
42
III. Développement des éléments de la zone de préparation

des données
Pour créer notre ETL (Extract, Transform, Load) à partir de la base de données sous SQL
Server, nous établissons les connexions nécessaires avec les bases sources et destinations (OLE
DB source et OLE DB destination).
1. Les connexions aux bases de données sources et destinations

La « figure 34 » présentera l’interface de gestion de connexions qui contient des différentes
bases de données du serveur localhost.
Figure 34: Interface de gestion de connexions SSIS
2. Alimentation de l’ODS (Operational Data Store)

Après la modélisation et la conception du modèle physique, nous passons par l’alimentation
de l’ODS qui représente une extraction des données de production source vers une base de
données destination (CGA_ODS).
Dans la mise à jour du package ODS, la requête « Truncate » permet de nettoyer toutes les
tables, ensuite les faires charger dans la base (CGA_ODS).
43
Nous présentons dans la « figure 35 » l’alimentation de l’ODS.
Figure 35: Alimentation des tables de l'ODS
Exemple : Cas de l’alimentation de la table « ODS_BonusMalus »
Figure 36: Alimentation de la table "ODS_BonusMalus"
44
La « figure 36 » présente l’alimentation de la table « ODS_BonusMalus » qui consiste à

extraire les données de la base de production source avec l’outil (OLE DB Source) et les charger
vers la base de données destination avec l’outil (OLE DB Destination).
3. Alimentation de la Data Warehouse

Suite à l’alimentation de la partie ODS, nous avons présenté dans cette étape l’alimentation
de la Data Warehouse qui contient les dimensions et les tables de faits.
• La première étape consiste à la préparation de l’ETL à travers l’abandonnement des clés

étrangères pour faire le nettoyage des tables de faits et dimensions.
• La deuxième étape consiste à faire charger les tables de dimensions.
• La troisième étape consiste à faire charger les tables de faits.
• La dernière étape consiste à restaurer les clés étrangères des dimensions et tables de
faits.
En cas d’erreur l’administrateur du système ETL sera notifié par mail.
Nous présentons dans la « figure 37 » l’alimentation de la Data Warehouse.
Figure 37: Alimentation des dimensions et des tables de fait de la Data Warehouse
45
a. Alimentation des dimensions

Exemple : Cas de l’alimentation de la table « Dim_Police »
Pour implémenter la dimension « Dim_Police », nous avons utilisé les outils SSIS suivants :
• OLE DB Source : pour extraire les données de la table source « Police » inclus dans la
base de données « CGA_ODS ».
• Lookup (Compagnies) : il consiste à faire une comparaison entre les données de la table
source « Compagnies » inclus dans la base de données « CGA_ODS », avec le jeu de
données de table existant et filtrer les données correspondantes.
• Flat File Destination (LogCompagnies) : si les données ne sont pas correspondantes
nous utilisons cet outil pour créer un fichier log qui consiste à voir les données non
équivalentes entre table source et destination.
• Lookup : pour faire référence entre la table source « Police » et la table destination de
la dimension « Dim_Police ».
• OLE DB Command : si les données existent nous utilisons cet outil pour faire la mise à
jour.
• OLE DB Destination : si les données n’existent pas nous créons cet outil pour faire
l’insertion des données dans la dimension « Dim_Police » de la base de Data Warehouse
(CGA_DW).
La « figure 38 » présentera l’interface de l’implémentation de la dimension police.
Figure 38: Alimentation de la table DimPolice
46
b. Alimentation des tables de faits

Pour implémenter les tables de faits « FactBonusMalus » et « FactSinistres », nous avons
utilisé les outils SSIS suivants :
• OLE DB Source : pour extraire les données de la table source inclus dans la base de
données « CGA_ODS ».
• Data Conversion : pour faire les transformations nécessaires des données selon les
besoins.
• Flat File Destination : si les données ne sont pas correspondantes nous utilisons cet outil
pour créer un fichier log qui consiste à voir les données non équivalentes entre table
source et destination.
• Lookup : pour faire référence entre les tables source et les tables destination.
• OLE DB Destination : pour faire une insertion des données dans la table de faits de la
base de Data Warehouse (CGA_DW).
La « figure 39 » présentera l’interface de l’implémentation de la table de faits

FactBonusMalus.
Figure 39: Alimentation de la table de fait "FactBounsMalus"
47
La « figure 40 » présentera l’interface de l’implémentation de la table de faits FactSinistres.
Figure 40: Alimentation de la table de fait "FactSinistres"
4. Déploiement du package SSIS

Le déploiement d’un package SSIS est une étape primordiale dans notre projet. Cependant,
un déploiement du package sur le serveur est plus avantageux, en particulier pour automatiser
l’exécution.
Dans la première étape nous avons créé un catalogue de services d’intégration (Integration
Services Catalogs) « SSISDB » au niveau de SQL Server Management Studio pour qu’il soit la
destination du déploiement de notre projet SSIS.
Figure 41: Catalogue de services d'intégration
48
Dans la deuxième et dernière étape consiste à déployer le projet SSIS en respectant les trois
phases suivantes :
La première phase consiste à sélectionner le projet SSIS à déployer.
Figure 42: La première étape de déploiement
49
La deuxième phase consiste à sélectionner la destination comme le montre la « figure 43 ».
Figure 43: La deuxième étape de déploiement
50
La dernière phase c’est de faire le déploiement du projet SSIS. Cette dernière est présentée
dans la « figure 44 » :
Figure 44: La dernière étape de de déploiement (Résultats)
5. La mise à jour automatique des données du Data Warehouse

Après le deploiement de notre projet SSIS dans sql server, l’étape suivante c’est qu’il est
nécessaire de faire un rafraîchissement automatique des données. Pour cela nous avons besoins
d’un agent SQL server, en effet l'agent SQL Server est le service installé par SQL Server qui
nous a permis d'automatiser et de planifier des tâches en exécutant ses travaux.
51
Le processus de mise à jour est composé de trois étapes :

• La création d’un nouveau job (travail).
Figure 45: La création d'un job
52
• L’ajout des étapes du job (travail).
Figure 46: L'ajout et la création d'une étape
53
• La création d’une planification d’exécution du job (travail).
Figure 47: Planification du job
Conclusion
Dans ce chapitre nous avons présenté les étapes de modélisation dimensionnelle, les
dimensions et les tables de fait qui constituent notre modèle de données.
Dans le chapitre suivant intitulé « Restitution des données » nous allons présenter les
imprimes écrans des Dashboard du système décisionnel.
54
CHAPITRE V : Restitution des données
Introduction
Après l’analyse de notre application, nous allons nous intéresser à la présentation de la phase
de restitution des données qui consiste à développer les tableaux de bord de notre système
décisionnel.
Dans la « figure 48 », nous présentons la phase de restitution des données de notre solution
suivant le cycle de vie dimensionnel.
Figure 48: Phase de restitution selon le cycle de vie dimensionnel
I. Développement de l’application utilisateur

La « figure 49 » présentera l’interface d’accueil de notre application décisionnelle.
Figure 49: Interface d'accueil de l'application décisionnelle de la CGA
56
1. Tableau de bord des compagnies d’assurance

Le tableau de bord suivant permet de suivre l’évolution du nombre des contrats Bonus-Malus
par compagnies d’assurance.
Ce tableau de bord contient ces visualisations :
• Une carte qui contient la valeur du nombre des bonus.
• Une carte qui contient la valeur du nombre des malus.
• Une carte qui contient la valeur du nombre des polices.
• Une carte qui contient la valeur du nombre des assures.
• Une carte qui contient la valeur du nombre des agences.
• Un histogramme groupé qui présente l’évolution du nombre des contrats par mois.
• Un histogramme groupé qui présente l’évolution du nombre des contrats par

compagnies d’assurance.
Ce tableau de bord est interactif et subit plusieurs filtres : mois, trimestre, année et par
Figure 50: Tableau de bord des compagnies d'assurance
57
2. Tableau de bord des usages véhicule

par usage vehicules.
• Un graphique en aires qui contient l’évolution des bonus par rapport aux malus par mois.
• Un graphique en anneau qui contient l’évolution du taux des contrats Bonus-Malus par
usages véhicule.
• Une carte qui contient la valeur du nombre des marques.
• Une carte qui contient la valeur du nombre des véhicules.
• Une matrice qui montre l’évolution des usages véhicule par mois.
• Une matrice qui montre l’évolution du nombre des contrats des usages véhicule par
Ce tableau de bord est interactif et subit plusieurs filtres : mois, trimestre, année et par usages
véhicule.
Figure 51: Tableau de bord des Usages Véhicule
58
3. Tableau de bord des classes Bonus-Malus

par classes.
• Un graphique à barre groupées qui contient l’évolution du nombre des contrats par
• Un graphique en courbes qui contient l’évolution du nombre des contrats par mois.
Ce tableau de bord est interactif et subit plusieurs filtres : mois, trimestre, année et par classe
Bonus-Malus.
Figure 52: Tableau de bord des classes Bonus-Malus
59
4. Tableau de bord des polices d’assurance

par polices d’assurance.
• Une matrice qui montre l’évolution du nombre des contrats du nature police par mois.
• Une matrice qui montre l’évolution du nombre des contrats du type police par mois.
• Un histogramme groupé qui présente l’évolution du nombre des contrats des polices par
Ce tableau de bord est interactif et subit plusieurs filtres : mois, trimestre, année, nature
police et type police.
Figure 53: Tableau de bord des Polices d'assurance
60
5. Tableau de bord des sinistres

Le tableau de bord suivant permet de suivre l’évolution du nombre des sinistres.
• Un graphique en secteurs qui présente le taux des sinistres par nature (Matériel,
corporel).
• Un histogramme groupé qui présente l’évolution des sinistres par mois.
• Un histogramme groupé qui présente l’évolution des sinistres par compagnies

d’assurance.
Ce tableau de bord est interactif et subit plusieurs filtres : mois, trimestre, année et par nature
sinistre.
Figure 54: Tableau de bord des Sinistres d'assurance
61
Conclusion
Dans ce chapitre nous avons présenté les tableaux de bord nécessaires pour le suivi et
l’analyse des compagnies d’assurance dans la partie sinistre et contrat Bonus-Malus en
présentant les imprimes écran du résultat obtenu.
Dans le chapitre suivant intitulé « Finalisation du système décisionnel » nous allons

présenter la dernière phase du cycle de vie dimensionnel qui est la phase de déploiement.
62
CHAPITRE VI : Finalisation du
système décisionnel
CHAPITRE IV : Finalisation du système décisionnel
Introduction
Après la phase de restitution de nos données, nous allons nous intéresser dans ce dernier
chapitre à la présentation de la partie du déploiement qui est la dernière phase du cycle de vie
décisionnel.
Dans la « figure 55 », nous présentons la phase de déploiement de notre solution suivant le

cycle de vie dimensionnel.
Figure 55: La phase de déploiement selon le cycle de vie dimensionnel
I. La publication de l’application utilisateur

Après avoir créé les rapports demandés, nous passons à l’étape suivante qui consiste à
publier ces derniers sur le Power BI Service.
64
Figure 56: Déploiement sur Power BI

En effet le Power BI Service est un service Cloud qui nous permet de publier nos rapports
en toute sécurité à notre organisation et de configurer une actualisation automatique des
données afin que tout le monde dispose des informations les plus récentes.
Figure 57: Connexion à la passerelle et aux sources de données
Pour cela nous avons besoin tout d’abord des passerelles Power BI pour connecter notre base
de données SQL Server à nos tableaux de bord dans Power BI.
65
Ensuite nous avons planifié l’actualisation de nos rapports chaque jour à sept heures matin
comme le montre la « figure 58 ».
Figure 58: Planification automatique des données
Conclusion
Dans ce chapitre nous avons présenté la partie de déploiement effectué dans notre application
décisionnelle.
66
Conclusion Générale
Conclusion Générale
Au terme de la réalisation de notre projet de fin d‘études dans le cadre de l’obtention du

diplôme national d’ingénieur en informatique, effectué au sein de la DSI de l’école supérieure
privée d’ingénierie et de technologies en partenariat avec le CGA, nous soulignons le prévalu
acquis suite à la mise en pratique de nos connaissances théoriques dans un environnement
professionnel.
L’objectif de notre projet était de concevoir et mettre en place un système d’aide à la décision
dédiée à l’analyse et le suivi des opérations sur le marché en matière d’assurance pour les
contrats d’assurance du système Bonus-Malus et les sinistres pour faciliter la prise de décisions
aux décideurs.
Dans une première partie nous avons étudié le cadre général du projet, analysé et spécifié
les besoins qui nous ont permis de distinguer les différents acteurs interagissant avec
l'application et de déterminer les besoins fonctionnels et non fonctionnels du système.
Par la suite, nous avons défini l’architecture de notre solution, ainsi que l’implémentation de
notre entrepôt de données.
La dernière partie du projet est consacrée à la partie concernant la restitution et le

déploiement des tableaux de bord en présentant des interfaces graphiques.
Cette expérience nous a amenés à découvrir et nous approfondir dans le domaine du Business
Intelligence et ses principales phases en utilisant la méthodologie de Ralph Kimball. Elle nous
a permis d’apprendre à manipuler de nouveaux outils tels que Power BI.
Finalement, cette expérience nous a permis d’enrichir nos connaissances, notre formation
théorique et pratique acquise tout au long de notre cursus universitaire et ainsi d’améliorer nos
capacités à nous intégrer dans la vie professionnelle.
En termes de perspective, nous pouvons améliorer notre système en ajoutant de nouveaux

axes à traiter et des tableaux de bord selon le besoin du client.
Dans le même contexte, nous pouvons les publier sur un portail collaboratif comme
SharePoint et former les utilisateurs sur le nouveau système.
67
Bibliographie et Webographie
[1] : http://www.finances.gov.tn/index.php?option=com_content&view=article&id
=94:organigramme-cga&catid=31:organigrammes&Itemid=513&lang=fr
[2] : http://www.cga.gov.tn/index.php?id=7&L=0
[3] : https://www.aerow.group/a16u1509/
[4] : http://igm.univ-mlv.fr/~dr/XPOSE2006/DELTIL_PEREIRA/processus.html
[5] : http://inf1410.teluq.ca/teluqDownload.php?file=2014/01/INF1410-
PresentationStarUML.pdf
[6] : https://www.comparex-group.com/web/microsites/microsoft/products/office/ms-
visio/ms-visio-2016.htm
[7] : https://www.next-decision.fr/editeurs/pmo/ms-project
[8] : https://www.next-decision.fr/editeurs/decisionnel-big-data/base-de-donnees/microsoft-
sql-server
[9] : https://www.next-decision.fr/editeurs/decisionnel-big-data/restitution/microsoft-power-bi
68

RapportNewFinalCopieMed Klibi

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

RapportNewFinalCopieMed Klibi

Transféré par

Droits d'auteur :

Formats disponibles

Remerciements

A l'issue de ce travail, nous remercions, en premier lieu, le bon Dieu de nous

Nous commençons par remercier Monsieur Chokri Chaaraoui, le directeur du

Nos remerciements les plus sincères s’adressent de même à Monsieur

Nous voulons exprimer notre gratitude et notre remerciement à Madame

Nous tenons à remercier également tous les responsables membres du jury

En fin, nous ne pouvons achever ce mémoire sans exprimer notre gratitude à

A ce qu’est toujours mon meilleur exemple dans la vie : mon père

Mon cher petit frère Amine

A l’âme de ma chère tante Faouzia qui

A mes chers Amis

CGA Comité Général des Assurances

DSI Direction de Système d’Information

DWH Data Warehouse

KPI Key Performance Indicator

ISBI Information system and Business Intelligence

ODS Operational Data Store

OLE DB Object Linking and Embedding Database

RDI Recherche, Developpement et d'Innovation

SID Système d’information décisionnel

SQL Structured Query Language

SSDT SQL Server Data Tools

SSIS SQL Server Integration Services

TIC Technologie de l'information et de la communication

UML Unified Modeling Language

Mots clé : ETC (Extraction-Transformation-Chargement), Système d’aide à la décision,

Introduction Générale ............................................................................................................... 1

Figure 1: Logo ESPRIT ........................................................................................................... 4

Tableau 1: Comparaison entre l'existant et la solution proposée ........................................ 8

Ainsi, le système d’aide à la décision ‘Business intelligence’ prend place au sein de la

▪ Le quatrième chapitre ” Préparation des données” sera dédié à la conception d’une

1. Présentation de l’Organisme d’accueil

Figure 1: Logo ESPRIT

ESPRIT « Ecole Supérieure Privée d’Ingénierie et de Technologies » est une école

Développement et d’Innovation (RDI) : ESPRIT-TEC, au sein de laquelle notre projet de

Notre projet a été réalisé au sein de la direction des systèmes d’information et

Figure 2: Organigramme d'Esprit Tech

2. Les missions de la Direction du Système d’Information

Dans ce cadre, elle est chargée de l’établissement et de la mise en œuvre du schéma

II. Présentation de l’Organisme Intervenant

1. Le Comité Général des Assurances

Figure 3: Logo CGA

2. Les missions du Comité Général des Assurance

• Du contrôle des entreprises d’assurances, des entreprises de réassurance et des

• De l'étude des questions d'ordre législatif, réglementaire et organisationnel se

• De l'étude des questions d’ordre technique et économique se rapportant au

III. Cadre du projet

Parmi lesquelles, nous citons :

• Offrir des informations fiables, cohérentes et pertinentes grâce à l’automatisation des

• Diffuser les données et mettre à jour les rapports quotidiennement.

• Faciliter la prise de décision grâce à des indicateurs pertinents.

• Réduire les coûts de la procédure de l’analyse et de Reporting actuelle.

Fonctionnalité Existant Solution

L’automatisation du calcul des indicateurs. Non Oui

L’historisation des données. Non Oui

L’automatisation des rapports. Non Oui

La mise à jour des rapports automatique chaque jour. Non Oui

Tableau 1: Comparaison entre l'existant et la solution proposée

IV. Méthodologie de travail

1. Le choix de la méthodologie de développement

2. Définition de la méthodologie choisie (Ralph Kimball)

Figure 4: Cycle de vie de la solution décisionnelle selon l'approche Ralph Kimball

2. Définition des besoins de l’entreprise :