Reporting temps réel sur un cluster MongoDB

29

29

29

30

30

31

31

31

36

37

38

38

39

40

40

41

44

44

45

46

47

48

48

49

52

52

52

vi

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 l’architecture du cluster MongoDB . . . . .

5.3.2 Réalisation de l’application spring boot

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

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

5.4.1 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

Conclusion Générale

Bibliographie

53

53

53

55

59

60

61

64

65

66

vii

Table des figures

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

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

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

5

6

9

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

10

2.1 Le secteur d’assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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 d’utilisation général

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

3.2 Diagramme de cas d’utilisation : « Gérer les données sources » . . . . . . . . . . . . .

3.3 Diagramme de cas d’utilisation : « Gérer les tableaux de bord »

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

3.4 Diagramme de cas d’utilisation :« Gérer les utilisateurs » . . . . . . . . . . . . . . . . .

3.5 Diagramme de cas d’utilisation :« Consulter les tableaux de bord» . . . . . . . . . . .

4.1 Architecture physique de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . .

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 config servers . . . . . . . . . . . . . . . . . . . . .

5.6 La configuration des replicats sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

13

17

19

24

25

27

32

34

34

35

36

38

39

41

42

43

44

45

49

50

53

54

55

55

56

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 d’authentification

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

5.13 Dashboard des sinistres

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

5.14 Le tableau de suivi des sinistres et les filtres

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

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

5.16 représentation des types de sinistres les plus affecté

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

5.17 Peprésentation des types de sinistres les plus fréquent

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

57

58

58

59

61

61

62

63

63

64

ix

Liste des tableaux

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

20

3.1 Description textuelle de cas d’utilisation 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 » . . . . . . . . . . . . . . .

33

34

35

35

36

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

42

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

5.2 Configuration des nœud du cluster

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

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

50

54

60

x

Introduction Générale

De nos jours, le contexte de mondialisation est caractérisé par l’omniprésence de l’information

qui représente une matière première stratégique à tous les niveaux de la prise de décision. La difficulté

ne réside plus dans la collecte de l’information, mais plutôt dans la mise à disposition de celle-ci sous

le bon format, au bon moment et à la bonne personne qui saura l’exploiter et en tirer de la valeur

ajoutée. Avec l’essor 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é, c’est-à-dire l’ajustement

d’une manière progressive et continue du stockage et des traitements au volume des données. Les SGBD

de Big data, qualifiés de systèmes not-only-SQL (ou NoSQL), relaxent les fondements de l’approche

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 l’espace de

stockage.

Côté entreprises, ces informations représentent un véritable potentiel d’avantage concurrentiel, une

possibilité de connaissance infinie sur son environnement et un élément différenciateur à long terme.

Dans ce contexte, l’informatique décisionnelle (Business intelligence ou BI) occupe une place

prédominante du fait qu’elle permet à l’organisation d’assurer sa position avant-gardiste. Cet objectif

se concrétise à travers l’ensemble de moyens permettant de mettre en place des tableaux de bord ayant

pour but d’offrir aux décideurs à la fois une vue d’ensemble sur l’activité de l’entreprise et la prise de

décisions.

Les assureurs commencent tout juste à entrevoir les possibilités qu’ouvre l’analyse de données

pour leur métier, notamment pour définir les profils 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 à l’aide 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 efficacement et à l’encadrement de suivre l’évolution des performances et des

tendances sur une période donnée, que ce soit à l’échelle de l’entreprise ou bien dans des domaines

spécifiques.

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

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

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

1

Introduction générale

distribué.

Le présent rapport s’articule autour de cinq chapitres :

— Le premier chapitre intitulé "Contexte Général" présente l’organisme d’accueil, 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 effectuées pour la réalisation du projet.

— Le troisième chapitre intitulé "Analyse des besoins " présente l’analyse des besoins fonctionnels

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

cas d’utilisation.

— Le quatrième chapitre intitulé "Conception et architecture" comporte l’architecture, l’analyse

et la conception de la solution.

— Le cinquième chapitre intitulé "Réalisation " permet de présenter les différents frameworks et

technologies que nous avons manipulées pour aboutir à la solution finale 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.

2

Chapitre 1

Contexte Général

Plan

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

1

2

Entreprise d’accueil : VERMEG . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

4

4

8

9

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 l’environnement du stage à travers une présentation de l’entreprise

d’accueil. 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 d’accueil : VERMEG

Le projet a été réalisé au sein de VERMEG située aux Berges du lac à Tunis, c’est une entreprise

« off-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 l’assurance

et de la finance. Elle est dotée d’une ingénierie experte en monétique et en édition de logiciels bancaires

et financiers pour la gestion des titres et des capitaux. Depuis sa création, elle n’a cessé de développer

son expertise en finance pour offrir une large gamme de logiciels innovants pour les middle et back-offices

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

capitalisation d’expertise utilisée à des fins d’innovation, ce qui explique l’utilisation de ses produits

par de grandes institutions financiè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 figure 1.1.

Elle compte aujourd’hui plus de 700 collaborateurs, principalement des consultants d’affaires et des

technologies de l’information, leur mission est d’ouvrir des services spécialisés dans le domaine de la

finance, de conseiller les clients et d’être à l’écoute de leurs besoins afin 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 d’assurances et de gestion d’actifs financiers.

4

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 qu’une technologie pour accompagner les mutations de plusieurs métiers. Ces 4

domaines d’expertise correspondent également à 4 divisions en termes d’organisation :

— Assurance de personnes /Assurance de biens

— Gestion d’actifs et de patrimoine

— Marchés financiers et metier titre

— Bespoke Solutions Development

Chaque domaine d’expertise 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 financiers et metier titre : Megara By Vermeg

— Assurance de personnes : Solife By Vermeg

— Gestion d’actifs et de patrimoine :Soliam By Vermeg

— Assurance de biens :Massai By Vermeg

5

Chapitre 1. Contexte Général

Figure 1.2: Les Départements de Vermeg

1.1.2 Produits et activités

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

une plateforme de développement Palmyra ainsi que le logiciel d’assurance 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 office 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-office,

Middle-office et Back-office qui sont destinées aux gestionnaires d’actifs. Elle est conçue aussi

bien pour s’intégrer facilement avec les systèmes d’informations des clients que pour assurer une

meilleure productivité. Omega FA est compatible avec l’environnement Windows.

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

automatiquement toute une application à partir d’un 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 l’analyse 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 d’architecture orientée services des applications de

Vermeg.

— Vermeg Life :C’est un progiciel d’administration de police d’assurance-vie. Il offre la gestion du

6

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.D’un 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 : c’est l’unité chargé de développer la solution SoLife pour la gestion des

polices d’assurance.

— Wealth and Asset Management : C’est l’unité chargé de développer la solution SOLIAM pour la

gestion des portefeuilles des gestionnaires d’actifs institutionnels de fortune.

— Financial Markets and Securities Services : il s’agit de l’unité 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é d’accueil

Vermeg Turkana anciennement BSB est le département d’accueil. 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 l’assurance-vie, les pensions et les soins de santé, la

gestion d’actifs et les secteurs de gestion de patrimoine. En effet, BSB développe des solutions métiers

et fournit des services IT aux professionnels de la finance et de l’assurance.

Solife est un système d’administration des politiques complet et performant, conçu par et pour

les assureurs, sur la base d’une connaissance et d’une pratique de l’expérience utilisateur depuis 20 ans.

Elle permet aux sociétés d’assurance 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 flux, distribution et frais, gestion des déclarations...

La bibliothèque étendue d’API de Solife permet une intégration transparente avec les réseaux

bancaires, les intermédiaires et les partenaires, les portails d’assurance numérique.[1]

7

Chapitre 1. Contexte Général

1.2 Présentation du projet

Dans cette section, nous présentons les objectifs de notre stage de fin 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 d’une solution décisionnelle est devient nécessaire pour l’assurance qui vise à

s’amé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 l’assurance.

La finalité générale derrière ce type de solutions est d’avoir un tableau de bord composé d’un ensemble

de graphiques et d’informations significatives qui donnent une idée sur la performance du client Solife

à tout moment.

1.2.2 Travail demandé

Afin de faciliter la prise de décision et automatisation des processus de traitement et d’analyse

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 d’une 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 d’un tableau de bord qui communique avec le cluster MongoDB et qui donne

l’opportunité de générer des rapports automatiques pour des fins d’analyse et de suivi.

La figure 1.3 est l’architecture de la solution proposée qui récapitule ce que nous souhaitons mettre en

place.

8

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 d’un logiciel désigne toutes les étapes du développement d’un

logiciel. C’est un processus qui conduit à la production d’un 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 afin de couvrir les différents types de projets. Les méthodes agiles et

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

Nous avons opté pour la méthodologie 2TUP vu qu’elle garantit une évolution flexible de notre

application en exploitant l’axe fonctionnel et l’axe 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 identifié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 Unified Process) est un processus de développement unifié qui

préconise un cycle de développement en Y et qui dissocie les aspects fonctionnels de l’application 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é.

9

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 identifie l’architecture candidate. La figure 1.4 présente

les diffé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 fixer les besoins techniques et déterminer

l’architecture 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éfinit les éléments essentiels à la construction de l’architecture technique indépendamment

des aspects fonctionnels.

— La branche fonctionnelle : Cette branche permet la capture des besoins fonctionnels et d’analyser

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 l’assurance 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 afin d’avoir un système qui répond aux attentes des utilisateurs finaux.[3]

Figure 1.4: Processus 2TUP

10

Chapitre 1. Contexte Général

Conclusion

Dans ce premier chapitre, nous avons commencé par la présentation de l’organisme d’accueil,

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

étude préalable fait l’objet du prochain chapitre pour comprendre les concepts généraux et d’étudier

les outils existants.

11

Chapitre 2

Étude Préalable

Plan

1

2

3

4

5

6

Concepts du domaine de l’assurance

. . . . . . . . . . . . . . . . . . . . . . 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 d’inté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 l’assurance. Dans la deuxième partie, il présente une étude pour le choix de la base de données NoSQL

mongoDb. Enfin, il définit les notions nécessaires pour la bonne compréhension de notre projet.

2.1 Concepts du domaine de l’assurance

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

afin 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 l’assurance

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

prestation, généralement financière, peut être destinée à un individu, une association ou une entreprise,

en échange de la perception d’une cotisation ou prime.

Par extension, l’assurance est le secteur économique qui regroupe les activités de conception, de

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

du secteur d’assurance.

Figure 2.1: Le secteur d’assurance

13

Chapitre 2. Étude Préalable

Le secteur de l’assurance 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 d’assurances repose sur la différence du mode de gestion des

primes. En effet, de manière générale, les Assurances Non Vie gèrent les primes par répartition, c’est

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, c’est un mode de gestion individuel où les primes de

l’assuré 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 d’une prime, accepte de

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

souvent dans les contrats individuels, se confond avec l’assuré.

Le souscripteur

Dans un contrat individuel, c’est la personne physique ou morale qui souscrit le contrat d’assurance vie

directement auprès d’une société d’assurance vie pour garantir certains risques. Il a le droit de choisir

les bénéficiaires de la rente ou bien du capital en cas de décès de l’assuré.

L’assuré

C’est la personne sur laquelle repose le risque, il doit être consentant. Pour les assurances en cas de

décès, c’est lui qui remplit le questionnaire médical le cas échéant.

Le bénéficiaire

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

le bénéficiaire, en cas de décès le bénéficiaire 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éficiaire acceptant. Le bénéficiaire peut être à la fois l’assuré et même le souscripteur.

14

Chapitre 2. Étude Préalable

L’agent d’assurance

L’agent général d’assurances est un professionnel indépendant exerçant l’activité d’intermédiaire pour

le compte d’une ou de plusieurs compagnies dont il a reçu un mandat. La compagnie d’assurance fixe

des objectifs à ses agents qui doivent être atteints à la fin de la période fixé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 d’assurances est un commerçant indépendant, servant d’intermédiaire dans une opération

commerciale entre une compagnie d’assurances et le consommateur final. Il ne faut pas confondre

entre le courtier en assurances et l’agent général d’assurances. Si le premier est un intermédiaire en

assurances, le second n’a pas la qualité de commerçant indépendant. L’agent 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 d’assurances

Après un sinistre, l’expert d’assurances intervient à la demande d’un 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 d’assurance ou Police d’assurance

C’est un document qui constate l’engagement réciproque de l’assureur et de l’assuré. 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 d’un contrat d’assurance, le souscripteur a la possibilité d’envoyer plusieurs types de

réclamations à son assureur :

— Un avenant de précision

— Un avenant d’appréciation ou de dépréciation de l’objet assuré.

— Un avenant de changement de garanties.

— Une demande de résiliation

— Une demande de rachat.

15

Chapitre 2. Étude Préalable

2.1.5 Prime

C’est un versement effectué par le souscripteur ou l’adhérent en contrepartie des garanties

accordées par l’assureur.

2.1.6 Sinistre

Réalisation de l’événement incertain, créant des dommages. [4]

2.2 Le projet décisionnel

Introduction

La Busine