R publique Tunisienne

Minist re de lEnseignement Sup rieur

et de la Recherche Scientique

Universit de Carthage

Facult des sciences conomiques et de gestion de Nabeul

Rapport de Projet de Fin d tudes

Pr sent en vue de lobtention du

Dipl me De Mast re Professionel Ing nierie des Syst mes dInformation et des

Connaissances

Par

Khaoula BOUGHZELA

Reporting temps r el sur un cluster MongoDB

Encadrant professionnel :

Monsieur Ibrahim BELAZREG

Encadrant acad mique :

Monsieur Taieb FELFEL

R alis au sein de Vermeg

Ann e Universitaire 2017 - 2018

Encadrant professionnel, Monsieur Ibrahim BELAZREG

Signature et cachet

Encadrant acad mique, Monsieur Taieb FELFEL

Signature

D dicaces

Je d die ce travail toute ma famille et particuli rement

A ma m re , mon p re , aux membre de ma famille qui mont combl

de leur soutien, que cet humble travail t moigne mon aection.

A ma ch re grand-m re, pour son soutien quotidien, ses encouragements

quelle trouve ici lexpression et le t moignage de ma gratitude ressentie.

A mon anc Wassim , pour sa compr hension, son soutien et

ses encouragements, quil trouve ici lexpression de ma reconnaissance.

ma SSur Khouloud pour son soutien moral,

des bons conseils et du r confort.

mes coll gues,ma cousine et les personnes aupr s desquelles jai toujours

trouv le bon accueil et un joli sourire.

iii

Remerciements

Cest avec plaisir que je r serve ces quelques lignes en signe de gratitude et de profonde

reconnaissance tous ceux qui mont cout , conseill , critiqu , encadr et contribu dune fa on

ou dune autre laboutissement de ce travail.

Je tiens remercier dans un premier temps, Monsieur Taieb FELFEL, mon encadrant acad mique

la facult des sciences conomiques et de gestion de Nabeul, pour laide et les conseils pertinents quil

ma apport s lors de ses di rents suivis concernant les missions voqu es dans ce rapport et durant

tout mon projet.

Je remercie galement Monsieur Ibrahim BELAZREG, mon encadrant technique Vermeg,

pour mavoir bien accueilli au sein de l quipe, pour mavoir accord ce stage et cru en moi et pour

mavoir guid et conseill au cours de mes di rentes missions. Jexprime envers lui tous mes sentiments

dappr ciation et de gratitude.

Jadresse mes remerciements aux membres du jury pour avoir accepter de juger ce travail.

Ainsi que tous les professeurs qui ont contribu ma formation et qui mont largement fait poter de

leurs connaissances et leurs conseils.

Table des mati res

Introduction g n rale

1 Contexte G n ral

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1 Entreprise daccueil : VERMEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.1 Organisation de Vermeg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.2 Produits et activit s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.3 Unit daccueil

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 Pr sentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.1 Contexte du projet

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.2 Travail demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3 M thodologie de d veloppement : 2TUP . . . . . . . . . . . . . . . . . . . . . . . . . .

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 tude Pr alable

2.1 Concepts du domaine de lassurance

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.1 Pr sentation de lassurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.2 Les acteurs

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.3 Le contrat dassurance ou Police dassurance

. . . . . . . . . . . . . . . . . . .

2.1.4 Les avenants

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.5 Prime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.6

Sinistre

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Le projet d cisionnel

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1 Choix de la base de donn es NoSql

. . . . . . . . . . . . . . . . . . . . . . . .

2.2.2 Choix de la Base de donn es MongoDB . . . . . . . . . . . . . . . . . . . . . .

2.3 Les tableaux de bord

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.1 R les des tableaux de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.2 Les instruments du tableau de bord . . . . . . . . . . . . . . . . . . . . . . . .

2.3.3 Choix des indicateurs dun tableau de bord . . . . . . . . . . . . . . . . . . . .

2.4 Le reporting

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5 Concept de clustering (regroupement de bases de donn es) . . . . . . . . . . . . . . . .

2.6 Les contraintes dint grations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6.1 Protocoles de transmision de messages SOAP . . . . . . . . . . . . . . . . . . .

2.6.2 Conversion de SOAP REST . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Analyse des Besoins

3.1

Identication des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.1 LIT analyste : Lexpert dassurance . . . . . . . . . . . . . . . . . . . . . . . .

3.1.2 Ladministrateur m tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Recensement des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.1 Besoins fonctionnels

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.3 Besoins techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.1 Diagrammes de cas dutilisation global . . . . . . . . . . . . . . . . . . . . . . .

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Conception et architecture

4.1 Architecture globale du syst me

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1.1 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1.2 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 La mod lisation des donn es dans le cluster mongoDB . . . . . . . . . . . . . . . . . .

4.2.1 Les donn es sources

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.2 Lint gration des donn es

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3 Aspect statique du syst me . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3.1 Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3.2 D ploiement de lapplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 R alisation

5.1 Environnement de travail

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1.1 Environnement mat riel

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 Les Serveurs

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2.1

Conteneur web de servlets : Apache Tomcat Apache . . . . . . . . . . . . . . .

5.2.2

Serveur de base de donn es :MongoDB . . . . . . . . . . . . . . . . . . . . . . .

5.2.3

Serveur de la restitution : Qlik Sense

. . . . . . . . . . . . . . . . . . . . . . .

5.3 R alisation de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3.1

Impl mentation et d ploiement de larchitecture du cluster MongoDB . . . . .

5.3.2 R alisation de lapplication spring boot

. . . . . . . . . . . . . . . . . . . . . .

5.4 R alisation du tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.4.2 La visualisation du Tableau de bord Claims . . . . . . . . . . . . . . . . . . . .

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conclusion G n rale

Bibliographie

vii

Table des gures

1.1 Clients de Vermeg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 Les D partements de Vermeg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3 Solution propos e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4 Processus 2TUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 Le secteur dassurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 La chaine d cisionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3 Les types des bases NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4 Architecture replication cluster

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5 Architecture shard cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6 Architecture JAXB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 Diagramme de cas dutilisation g n ral

. . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Diagramme de cas dutilisation : G rer les donn es sources . . . . . . . . . . . . .

3.3 Diagramme de cas dutilisation : G rer les tableaux de bord

. . . . . . . . . . . .

3.4 Diagramme de cas dutilisation : G rer les utilisateurs . . . . . . . . . . . . . . . . .

3.5 Diagramme de cas dutilisation : Consulter les tableaux de bord . . . . . . . . . . .

4.1 Architecture physique de lapplication . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3

Invoquer WS dans SoapUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4 Le document Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5 La mod lisation des donn es de notre tableau de bord . . . . . . . . . . . . . . . . . .

4.6 Le Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.7 Le Diagramme de d ploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1

Interface graphique de draw.io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3 Architecture du cluster Mongodb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.4 Connexion au master

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.5 La connexion entre le Master et les cong servers . . . . . . . . . . . . . . . . . . . . .

5.6 La conguration des replicats sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.7 Tester web service dans soapUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

viii

5.8 Les classes g n rer

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.9 Code de consommation des donn es . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.10 Application springboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.11 Persistance des donn es

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.12 Page dauthentication

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.13 Dashboard des sinistres

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.14 Le tableau de suivi des sinistres et les ltres

. . . . . . . . . . . . . . . . . . . . . . .

5.15 Repr sentation du nombre des sinistres selon leurs statuts . . . . . . . . . . . . . . . .

5.16 repr sentation des types de sinistres les plus aect

. . . . . . . . . . . . . . . . . . .

5.17 Pepr sentation des types de sinistres les plus fr quent

. . . . . . . . . . . . . . . . . .

Liste des tableaux

2.1 Comparaison SQL / MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 Description textuelle de cas dutilisation g n ral

. . . . . . . . . . . . . . . . . . . . .

3.2 Description textuelle CU G rer les donn es sources . . . . . . . . . . . . . . . . . .

3.3 Description textuelle CU G rer les tableaux de bord . . . . . . . . . . . . . . . . .

3.4 Description textuelle CU G rer les utilisateurs . . . . . . . . . . . . . . . . . . . .

3.5 Description textuelle CU Consulter les tableaux de bord . . . . . . . . . . . . . . .

4.1 Les r gles de passage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1 Framework et outils utilis s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 Conguration des nSud du cluster

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3 Architecture KPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Introduction G n rale

De nos jours, le contexte de mondialisation est caract ris par lomnipr sence de linformation

qui repr sente une mati re premi re strat gique tous les niveaux de la prise de d cision. La dicult

ne r side plus dans la collecte de linformation, mais plut t dans la mise disposition de celle-ci sous

le bon format, au bon moment et la bonne personne qui saura lexploiter et en tirer de la valeur

ajout e. Avec lessor des grandes plateformes Web (par exemple, Google, Facebook, Twitter, Amazon),

ont t d velopp es des solutions de gestion des m gadonn es (big data) bas es sur des approches

d centralis es permettant la gestion et le stockage de gigantesques masses de donn es.

Cette approche d centralis e repose sur le principe de la scalabilit , cest- -dire lajustement

dune mani re progressive et continue du stockage et des traitements au volume des donn es. Les SGBD

de Big data, quali s de syst mes not-only-SQL (ou NoSQL), relaxent les fondements de lapproche

relationnelle pour pouvoir supporter les masses de donn es distribu es. De ce fait, il est envisageable

de construire des entrep ts de donn es massives reposant sur ce principe de scalabilit de lespace de

stockage.

C t entreprises, ces informations repr sentent un v ritable potentiel davantage concurrentiel, une

possibilit de connaissance innie sur son environnement et un l ment di renciateur long terme.

Dans ce contexte, linformatique d cisionnelle (Business intelligence ou BI) occupe une place

pr dominante du fait quelle permet lorganisation dassurer sa position avant-gardiste. Cet objectif

se concr tise travers lensemble de moyens permettant de mettre en place des tableaux de bord ayant

pour but dorir aux d cideurs la fois une vue densemble sur lactivit de lentreprise et la prise de

d cisions.

Les assureurs commencent tout juste entrevoir les possibilit s quouvre lanalyse de donn es

pour leur m tier, notamment pour d nir les prols de risque et acc l rer sur la pr vention.

Les tableaux de bord permettent de suivre en temps r el les performances de la gestion des sinistres et

des quipes correspondantes laide de repr sentations visuelles faciles comprendre. Cette fonctionnalit

permet aux superviseurs de mieux g rer leurs quipes, aux gestionnaires de sinistres de r partir leur

charge de travail plus ecacement et lencadrement de suivre l volution des performances et des

tendances sur une p riode donn e, que ce soit l chelle de lentreprise ou bien dans des domaines

sp ciques.

Notre mission consiste collecter les donn es partir des web services Solife et les stocker dans un

cluster mongoDB an de r aliser une restitution sous forme de tableaux de bord. La partie applicative,

va consister en un d ploiement dun cluster mongoDB avec tous ses composants dans un environnement

Introduction g n rale

distribu .

Le pr sent rapport sarticule autour de cinq chapitres :

Le premier chapitre intitul "Contexte G n ral" pr sente lorganisme daccueil, donne une

pr sentation g n rale de notre projet ainsi que la m thodologie adopt e.

Le deuxi me chapitre intitul "Etude pr alable"consiste introduire les concepts cl s n cessaires

la compr hension de notre projet et toutes les tudes eectu es pour la r alisation du projet.

Le troisi me chapitre intitul "Analyse des besoins " pr sente lanalyse des besoins fonctionnels

et non fonctionnels suivi par une mod lisation de ces besoins par le recours aux diagrammes de

cas dutilisation.

Le quatri me chapitre intitul "Conception et architecture" comporte larchitecture, lanalyse

et la conception de la solution.

Le cinqui me chapitre intitul "R alisation " permet de pr senter les di rents frameworks et

technologies que nous avons manipul es pour aboutir la solution nale ainsi que le fonctionnement

de notre solution.

Nous cl turons ce rapport par une "Conclusion G n rale" dans laquelle nous r sumons notre

solution et exposons quelques perspectives futures.

Chapitre 1

Contexte G n ral

Plan

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Entreprise daccueil : VERMEG . . . . . . . . . . . . . . . . . . . . . . . . .

Pr sentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 M thodologie de d veloppement : 2TUP . . . . . . . . . . . . . . . . . . . .

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Chapitre 1. Contexte G n ral

Introduction

Ce chapitre a pour but de situer le projet dans son environnement organisationnel et contextuel.

Nous commen ons par pr senter lenvironnement du stage travers une pr sentation de lentreprise

daccueil. Par la suite, nous d crivons le travail demand , ainsi que la m thodologie utilis e pour

r soudre les probl matiques du projet.

1.1 Entreprise daccueil : VERMEG

Le projet a t r alis au sein de VERMEG situ e aux Berges du lac Tunis, cest une entreprise

o-shore d velopp e depuis plus de 20 ans comme int grateur de solutions et de services. VERMEG

est d sormais un partenaire cl pour les transformations m tier et digitale dans le secteur de lassurance

et de la nance. Elle est dot e dune ing nierie experte en mon tique et en dition de logiciels bancaires

et nanciers pour la gestion des titres et des capitaux. Depuis sa cr ation, elle na cess de d velopper

son expertise en nance pour orir une large gamme de logiciels innovants pour les middle et back-oces

des institutions nanci res concern es par le traitement des titres. Son atout majeur est sa capacit de

capitalisation dexpertise utilis e des ns dinnovation, ce qui explique lutilisation de ses produits

par de grandes institutions nanci res dans quinze pays travers trois continents.

VERMEG a plusieurs clients renomm s travers le monde englobant les banques, les gestionnaires de

fonds, les assurances tels que le Banco Santander, la Banque de France, BNP paribas, HSBC,Nordea

et Soci t G n rale gure 1.1.

Elle compte aujourdhui plus de 700 collaborateurs, principalement des consultants daaires et des

technologies de linformation, leur mission est douvrir des services sp cialis s dans le domaine de la

nance, de conseiller les clients et d tre l coute de leurs besoins an de les satisfaire dans la mesure

du possible.

Dans le cadre de son expansion, VERMEG a pris le contr le de BSB, une entreprise belge sp cialis e

en dition de logiciels dassurances et de gestion dactifs nanciers.

Chapitre 1. Contexte G n ral

Figure 1.1: Clients de Vermeg

1.1.1 Organisation de Vermeg

Vermeg couvre toute la cha ne de valeur par le biais de 3 m tiers et propose des services

num riques ainsi quune technologie pour accompagner les mutations de plusieurs m tiers. Ces 4

domaines dexpertise correspondent galement 4 divisions en termes dorganisation :

Assurance de personnes /Assurance de biens

Gestion dactifs et de patrimoine

March s nanciers et metier titre

Bespoke Solutions Development

Chaque domaine dexpertise au sein de Vermeg correspond un d partement et chacun a developp

son produit dans le march . On cite donc :

Bespoke Solutions Development : Palmyra By Vermeg

March s nanciers et metier titre : Megara By Vermeg

Assurance de personnes : Solife By Vermeg

Gestion dactifs et de patrimoine :Soliam By Vermeg

Assurance de biens :Massai By Vermeg

Chapitre 1. Contexte G n ral

Figure 1.2: Les D partements de Vermeg

1.1.2 Produits et activit s

Vermeg ore une gamme de produits, parmi lesquels nous citons la suite Megara et Omega FA,

une plateforme de d veloppement Palmyra ainsi que le logiciel dassurance vie Vermeg Life.

Megara suite : Megara est un ensemble de modules pour le traitement des valeurs mobili res

pouvant tre impl ment s s par ment et ind pendamment. Elle permet une automatisation des

t ches du middle et back oce des principales institutions bancaires poss dant une structure

multi-march , multidevises et multi entit s.

Omega FA : Omega FA est une application orient e m tier, fournissant les fonctionnalit s Front-oce,

Middle-oce et Back-oce qui sont destin es aux gestionnaires dactifs. Elle est con ue aussi

bien pour sint grer facilement avec les syst mes dinformations des clients que pour assurer une

meilleure productivit . Omega FA est compatible avec lenvironnement Windows.

Palmyra : Palmyra est un Framework propre Vermeg. Son objectif principal tant de g n rer

automatiquement toute une application partir dun simple mod le UML. Les applications que

g n re PALMYRA visent principalement les m tiers de la banque et de la bourse. Il repose

sur lanalyse et la conception orient objet, et utilise des mod les et des outils standards tels

que le mod le UML et le standard J2EE. En Novembre 2007, Le label IBM SOA Exploit a t

d cern au Framework PALMYRA, apr s plusieurs suites de tests techniques et m tier, faisant

ainsi de ce Framework la base du concept darchitecture orient e services des applications de

Vermeg.

Vermeg Life :Cest un progiciel dadministration de police dassurance-vie. Il ore la gestion du

Chapitre 1. Contexte G n ral

cycle de vie du contrat depuis la souscription, en passant par la cr ation jusqu la cl ture. La

premi re version tait d velopp e en 2005.Dun point de vue technologique, Vermeg Life utilise

une architecture orient e services (SOA) et est d velopp en technologie Java.

Vermeg est compos de quatre unit s appel Business Unit (BU) qui sont les suivantes :

Pension and Insurance : cest lunit charg de d velopper la solution SoLife pour la gestion des

polices dassurance.

Wealth and Asset Management : Cest lunit charg de d velopper la solution SOLIAM pour la

gestion des portefeuilles des gestionnaires dactifs institutionnels de fortune.

Financial Markets and Securities Services : il sagit de lunit qui d veloppe la solution Megara

d di e au traitement des titres.

Digital Financial Services : unit responsable de la solution Palmyra.

1.1.3 Unit daccueil

Vermeg Turkana anciennement BSB est le d partement daccueil. BSB a t repris par Vermeg

group en 2014 apr s 4 ann es de r sultats n gatifs. Elle a t cr e en 1995 sous le nom de Business

Solutions Builders , par trois personnes initi es au monde de la consultance bancaire : Jean Martin,

Michel Isaac, et Marc van Steenwinkel.

BSB est un diteur de logiciels ax sur lassurance-vie, les pensions et les soins de sant , la

gestion dactifs et les secteurs de gestion de patrimoine. En eet, BSB d veloppe des solutions m tiers

et fournit des services IT aux professionnels de la nance et de lassurance.

Solife est un syst me dadministration des politiques complet et performant, con u par et pour

les assureurs, sur la base dune connaissance et dune pratique de lexp rience utilisateur depuis 20 ans.

Elle permet aux soci t s dassurance vie et sant de g rer de bout en bout leurs nouvelles activit s,

polices et sinistres, avec toutes les fonctionnalit s n cessaires : gestion de tr sorerie et des v nements,

gestion des ux, distribution et frais, gestion des d clarations...

La biblioth que tendue dAPI de Solife permet une int gration transparente avec les r seaux

bancaires, les interm diaires et les partenaires, les portails dassurance num rique.[1]

Chapitre 1. Contexte G n ral

1.2 Pr sentation du projet

Dans cette section, nous pr sentons les objectifs de notre stage de n d tudes. Dans un premier

temps nous voquons le contexte du projet et nous enchainons par la suite avec la description du travail

demand .

1.2.1 Contexte du projet

La mise en place dune solution d cisionnelle est devient n cessaire pour lassurance qui vise

sam liorer et se d velopper de mani re continue et qui fournit aux d cideurs une vision synth tique

du pass , du pr sent et ,par cons quent, du futur de lassurance.

La nalit g n rale derri re ce type de solutions est davoir un tableau de bord compos dun ensemble

de graphiques et dinformations signicatives qui donnent une id e sur la performance du client Solife

tout moment.

1.2.2 Travail demand

An de faciliter la prise de d cision et automatisation des processus de traitement et danalyse

et la visualisation des donn es pour le client Solife. Nous proposons de d velopper une plateforme de

reporting pour la solution de Solife .

Notre travail comporte trois principales parties :

Le d veloppement dune application pour la consommation des donn es partir des web services

SOAP du client Solife.

Le stockage des donn es dans un cluster MongoDB.

La cr ation dun tableau de bord qui communique avec le cluster MongoDB et qui donne

lopportunit de g n rer des rapports automatiques pour des ns danalyse et de suivi.

La gure 1.3 est larchitecture de la solution propos e qui r capitule ce que nous souhaitons mettre en

place.

Chapitre 1. Contexte G n ral

Figure 1.3: Solution propos e

1.3 M thodologie de d veloppement : 2TUP

Le cycle de d veloppement dun logiciel d signe toutes les tapes du d veloppement dun

logiciel. Cest un processus qui conduit la production dun logiciel. Il commence avec la d cision de

d velopper un logiciel et se termine avec sa livraison et son installation. Ainsi, plusieurs m thodologies

de d veloppement sont apparues an de couvrir les di rents types de projets. Les m thodes agiles et

uni es[2] sont les plus adopt es pour de d veloppement logiciel.

Nous avons opt pour la m thodologie 2TUP vu quelle garantit une volution exible de notre

application en exploitant laxe fonctionnel et laxe technique en parall le. La nature du projet repr sente

des besoins de nature m tier, solife assurance vie, reporting et fonctionnelle au m me degr que les

besoins techniques identi s en termes de techniques de collecte, de stockage ,cluster Mongodb, KPI,

technique outil BI pour front end et la nature de la base.

Le processus 2TUP (Two Track Unied Process) est un processus de d veloppement uni qui

pr conise un cycle de d veloppement en Y et qui dissocie les aspects fonctionnels de lapplication des

aspects techniques et architecturaux. Le processus 2TUP commence par une tude pr liminaire qui

permet de cerner le p rim tre du projet et d tudier sa faisabilit .

Chapitre 1. Contexte G n ral

Au cours de cette tape, le concepteur tablit une premi re id e sur le syst me impl menter. Il

recense les traitements informatiques pr vus et identie larchitecture candidate. La gure 1.4 pr sente

les di rentes tapes constituants les branches du processus 2TUP. Le processus 2TUP est compos

de trois branches qui sont les suivantes :

La branche technique : Dans cette branche, il faut xer les besoins techniques et d terminer

larchitecture logicielle et mat rielle. Dans cette partie, nous avons choisi les technologies et les

outils ad quates. Dans cette partie, nous avons choisi les techniques de consommation des donn es

ainsi que les technologies et les outils utiliser.Ensuite, nous avons tabli la conception g n rique

qui d nit les l ments essentiels la construction de larchitecture technique ind pendamment

des aspects fonctionnels.

La branche fonctionnelle : Cette branche permet la capture des besoins fonctionnels et danalyser

ses besoins pour obtenir une id e de ce que va r aliser le syst me en terme de m tier.

Au cours de cette tape, nous avons essay de comprendre le m tier de lassurance vie et d gager

les indicateurs cl de performance . Nous avons aussi d termin les besoins fonctionnels et non

fonctionnels de notre futur syst me.

Branche conception et d veloppement logiciel : Cette branche correspond la fusion des deux

pr c dentes an davoir un syst me qui r pond aux attentes des utilisateurs naux.[3]

Figure 1.4: Processus 2TUP

Chapitre 1. Contexte G n ral

Conclusion

Dans ce premier chapitre, nous avons commenc par la pr sentation de lorganisme daccueil,

ensuite nous avons d crit le cadre g n ral du projet. En vue davoir une id e plus claire sur le projet, une

tude pr alable fait lobjet du prochain chapitre pour comprendre les concepts g n raux et d tudier

les outils existants.

Chapitre 2

tude Pr alable

Plan

Concepts du domaine de lassurance

. . . . . . . . . . . . . . . . . . . . . . 13

Le projet d cisionnel

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Les tableaux de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Le reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Concept de clustering (regroupement de bases de donn es) . . . . . . . . . 23

Les contraintes dint grations . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Chapitre 2. tude Pr alable

Introduction

Ce chapitre constitue le maillon de d part de notre projet. il expose une pr sentation du monde

de lassurance. Dans la deuxi me partie, il pr sente une tude pour le choix de la base de donn es NoSQL

mongoDb. Enn, il d nit les notions n cessaires pour la bonne compr hension de notre projet.

2.1 Concepts du domaine de lassurance

Dans cette partie, nous d crivons les di rents concepts qui constituent le fondement du projet

an de mieux comprendre notre travail. Nous pr sentons ci-dessous quelques concepts utilis s dans le

m tier des assurances.

2.1.1 Pr sentation de lassurance

Une assurance est un service qui fournit une prestation lors de la survenance dun risque. La

prestation, g n ralement nanci re, peut tre destin e un individu, une association ou une entreprise,

en change de la perception dune cotisation ou prime.

Par extension, lassurance est le secteur conomique qui regroupe les activit s de conception, de

production et de commercialisation de ce type de service. La gure 2.1 est une repr sentation g n rale

du secteur dassurance.

Figure 2.1: Le secteur dassurance

Chapitre 2. tude Pr alable

Le secteur de lassurance contient deux m tiers ind pendants :

Les Assurances Non Vie (Assurances de Biens, Assurances de Responsabilit et Assu-rances Sant ).

Les Assurances Vie (Vie, d c s, pargne, retraite...).

Cette distinction entre ces deux types dassurances repose sur la di rence du mode de gestion des

primes. En eet, de mani re g n rale, les Assurances Non Vie g rent les primes par r partition, cest

un mode de gestion collectif o les primes de la communaut des assur s servent payer les sinistres

de la communaut des assur s au titre du m me exercice.

Les Assurances Vie les g rent par capitalisation, cest un mode de gestion individuel o les primes de

lassur servent lui d livrer une prestation au moment de la survenance du risque.[5]

2.1.2 Les acteurs

Les assureurs

Un assureur est une personne physique ou morale qui, moyennant le paiement dune prime, accepte de

prendre nanci rement en charge un risque que lui demande de garantir un souscripteur qui, le plus

souvent dans les contrats individuels, se confond avec lassur .

Le souscripteur

Dans un contrat individuel, cest la personne physique ou morale qui souscrit le contrat dassurance vie

directement aupr s dune soci t dassurance vie pour garantir certains risques. Il a le droit de choisir

les b n ciaires de la rente ou bien du capital en cas de d c s de lassur .

Lassur

Cest la personne sur laquelle repose le risque, il doit tre consentant. Pour les assurances en cas de

d c s, cest lui qui remplit le questionnaire m dical le cas ch ant.

Le b n ciaire

Cest la personne d sign e qui percevra la prestation. En cas de vie le souscripteur est g n ralement

le b n ciaire, en cas de d c s le b n ciaire est celui qui a t d sign par le souscripteur. Il peut

tre d sign directement (nom, pr nom), indirectement (le conjoint, les enfants, etc.) ou encore tre

b n ciaire acceptant. Le b n ciaire peut tre la fois lassur et m me le souscripteur.

Chapitre 2. tude Pr alable

Lagent dassurance

Lagent g n ral dassurances est un professionnel ind pendant exer ant lactivit dinterm diaire pour

le compte dune ou de plusieurs compagnies dont il a re u un mandat. La compagnie dassurance xe

des objectifs ses agents qui doivent tre atteints la n de la p riode x e.

Certains contrats ou d cisions ne peuvent tre r alis s directement par les agents et doivent passer la

compagnie dans un premier temps.

Le courtier

Un courtier dassurances est un commer ant ind pendant, servant dinterm diaire dans une op ration

commerciale entre une compagnie dassurances et le consommateur nal. Il ne faut pas confondre

entre le courtier en assurances et lagent g n ral dassurances. Si le premier est un interm diaire en

assurances, le second na pas la qualit de commer ant ind pendant. Lagent est limit dans le choix

des produits ou de sa politique commerciale. Ind pendant de la pression des objectifs commerciaux des

compagnies, le courtier fournit un conseil objectif.

Expert dassurances

Apr s un sinistre, lexpert dassurances intervient la demande dun client et il doit valuer le montant

des dommages mat riels et ventuellement, celui du pr judice moral subi par le client.

2.1.3 Le contrat dassurance ou Police dassurance

Cest un document qui constate lengagement r ciproque de lassureur et de lassur . Ce document

est compos au moins des conditions g n rales et des conditions particuli res dans lesquelles le service

sera rendu. Il comprend la prime, la prestation et le risque.

2.1.4 Les avenants

Au cours dun contrat dassurance, le souscripteur a la possibilit denvoyer plusieurs types de

r clamations son assureur :

Un avenant de pr cision

Un avenant dappr ciation ou de d pr ciation de lobjet assur .

Un avenant de changement de garanties.

<...

Rapport de Projet de Fin d’Études: Reporting temps réel sur un cluster MongoDB

Rapport de Projet de Fin d’Études: Reporting temps réel sur un cluster MongoDB