Conception des systèmes décisionnels basée sur l'analyse des processus métiers; Application au domaine des assurances par la mise en place d'un environnement décisionnel et de production

Institut Africain d'Informatique
Etablissement Inter-états d'Enseignement Supérieur
BP : 2263 Libreville (Gabon)
Tel. [phone] 56 00
Site web: www.iaisiege.com
E-mail: [e-mail]

Conception des systèmes décisionnels basée

sur l'analyse des processus métiers ;

application au domaine des assurances par la

mise en place d'un environnement

décisionnel et de production

Année académique 2015-2016

Présenté et soutenu par :

Superviseur :

DJYAMO Azore

Pr. Souleymane KOUSSOUBE Enseignant chercheur à l'IAI

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

TABLE DES MATIERES

DEDICACE I

REMERCIEMENTS II

EPIGRAPHE III

AVANT-PROPOS IV

RESUME V

ABSTRACT VI

SIGLES, ABREVIATIONS ET ACRONYMES VII

FIGURES IX

TABLEAUX XI

INTRODUCTION GENERALE 1

PARTIE 1 : PRESENTATION GENERALE 3

CHAPITRE 1 : STRUCTURE D'ACCUEIL ET SUJET 4

1.1 STRUCTURE D'ACCUEIL 4

1.1.1 Présentation de l'IAI 4

1.1.2 Le LAIMA 4

1.2 SUJET 5

1.2.1 Contexte et intitulé 5

1.2.2 Problématiques 5

1.2.3 Intérêts 6

CHAPITRE 2 : CONCEPTS LIES AUX DOMAINES D'ETUDE 8

2.1 Assurances 8

2.1.1 Définitions 8

2.1.2 Historiques 8

2.1.3 Différents types d'assurances 9

2.1.4 Le code CIMA 12

2.1.4.1 Objectifs 13

2.1.4.2 Quelques articles du code CIMA 14

2.2 Informatique décisionnelle (Business Intelligence) 16

2.2.1 Entrepôt de données (Data Warehouse) 17

2.2.1.1 Définition 17

2.2.1.2 Bref aperçu 18

2.2.2 Notions de SIO et SID 19

2.2.3 Différence entre SID et SIO 19

2.2.4 Technologies d'implantation des données (systèmes OLAP) 20

2.2.4.1 Le système à architecture ROLAP 21

2.2.4.2 Le système à architecture MOLAP 21

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

2.2.4.3 Le système à architecture HOLAP 22

2.2.4.4 Architecture ROLAP vs architecture MOLAP 22

2.2.5 Schémas de modélisation ROLAP 22

2.2.5.1 Le schéma en étoile 22

2.2.5.2 Le schéma en flocon de neige 24

2.2.5.3 Choix d'un schéma 24

PARTIE 2 : ANALYSE ET CONCEPTION 27

CHAPITRE 1 : OUTILS D'ANALYSE ET DE CONCEPTION 28

1.1 Modélisation des données source 28

1.1.1 Méthodes d'analyse et de conception 28

1.1.2 Choix d'une méthode 28

1.2 Modélisation de l'entrepôt de données 28

1.2.1 Approches de conception 28

1.2.1.1 L'approche Top-Down de Bill Inmon 28

1.2.1.2 L'approche Bottom-Up de Ralph Kimball 30

1.2.1.3 L'approche Middle-Out 31

1.2.2 Etat de lieu des techniques de conception dimensionnelle 31

CHAPITRE 2 : Conception basée sur l'analyse des processus métiers 33

2.1 Identification des processus métier d'une compagnie d'assurance 33

2.2 Identification des acteurs d'une compagnie d'assurance 34

2.3 Identification des interactions entre acteurs et processus 36

2.4 Description des processus métiers 36

2.4.1 Processus métier « Gestion des demandes de devis » 37

2.4.2 Processus métier « Gestion de police d'assurance » 37

2.4.3 Processus métier « Gestion des indemnisations » 38

2.4.4 Processus métier « Recouvrement des primes » 39

2.5 Annotation des processus métiers 40

2.5.1 Processus métier « Gestion des demandes de devis » 41

2.5.2 Processus métier « Gestion de police d'assurance » 41

2.5.3 Processus métier « Gestion des indemnisations » 42

2.5.4 Processus métier « Recouvrement des primes » 43

2.6 Analyse des processus métiers 43

CHAPITRE 3 : ANALYSE ET CONCEPTION 46

3.1 Expression préliminaire des besoins fonctionnels 46

3.1.1 Besoins fonctionnels 46

3.1.2 Identification des acteurs 46

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.1.3 Diagramme de contexte statique 47

3.1.3.1 Contexte statique du SIO 47

3.1.3.2 Contexte statique du SID 47

3.1.4 Identification des cas d'utilisation 48

3.1.5 Diagramme des cas d'utilisation 49

3.1.5.1 Diagramme des cas d'utilisation du Système transactionnel 49

3.1.5.2 Diagramme des cas d'utilisation du Système décisionnel 50

3.1.6 Classification des cas d'utilisation et découpage en itération 50

3.1.7 Description textuelle de quelques cas d'utilisation 52

3.1.7.1 Cas d'utilisation « s'authentifier » 52

3.1.7.2 Cas d'utilisation « demander devis » 53

3.1.7.3 Cas d'utilisation « gérer police d'assurance » 53

3.2 Expression des besoins non fonctionnels 54

3.3 Identification des classes conceptuelles 55

3.4 Conception du modèle décisionnel 56

3.4.1 Matrice dite d'analyse des priorités [Kimball, 2004] 57

3.4.2 Volet « Gestion des demandes de devis » 57

3.4.2.1 Activité « suivi des demandes de devis » 57

3.4.2.2 Grain de l'activité « suivi des demandes de devis » 57

3.4.2.3 Choix des dimensions participantes 58

3.4.2.4 Choix des mesures 61

3.4.2.5 Schéma en étoile de l'activité « suivi de demandes de devis » 63

3.4.3 Volet « Gestion des polices d'assurance » 63

3.4.3.1 Activité « suivi des polices d'assurance » 63

3.4.3.2 Grain de l'activité « suivi police d'assurance » 63

3.4.3.3 Choix des dimensions participantes 64

3.4.3.4 Choix des mesures 65

3.4.3.5 Schéma en étoile de l'activité « suivi police d'assurance » 66

3.4.4 Volet « suivi des primes » 66

3.4.4.1 Activité « recouvrement des primes » 66

3.4.4.2 Grain de l'activité « recouvrement des primes » 66

3.4.4.3 Choix des dimensions participantes 67

3.4.4.4 Choix des mesures 68

3.4.4.5 Schéma en étoile de l'activité « suivi des primes » 69

3.4.5 Volet « Gestion des indemnités » 69

3.4.5.1 Activité « suivi des indemnités » 69

3.4.5.2 Grain de l'activité « suivi des indemnités » 70

3.4.5.3 Choix des dimensions participantes 70

3.4.5.4 Choix des mesures 72

3.4.5.5 Schéma en étoile de l'activité « suivi des indemnités » 73

3.5 Modèles dynamiques 74

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.5.1 Diagrammes de séquence 74

3.5.1.1 Diagramme de séquence du cas d'utilisation « S'authentifier» 74

3.5.1.2 Diagramme de séquence du cas d'utilisation « demander devis» 74

3.5.1.3 Diagramme de séquence du cas d'utilisation « consulter reporting» 75

3.5.1.4 Diagramme de séquence du cas d'utilisation « Gérer police

d'assurance » 75

3.5.2 Diagrammes d'activités 76

3.5.2.1 Diagramme d'activité « demander devis » 76

3.5.2.2 Diagramme d'activité « Consulter reporting» 76

3.5.2.3 Diagramme d'activité « Gérer police d'assurance » 77

3.6 Diagramme de déploiement 77

3.7 Architecture technique 79

PARTIE 3 : MISE EN OEUVRE ET CONDUITE DE PROJET 81

CHAPITRE 1 : MISE EN OEUVRE 82

1.1 Choix et mise en place des outils décisionnels libres 82

1.1.1 Choix de l'outil BI 82

1.1.1.1 Installation et configuration de SpagoBI 83

1.1.1.2 Lancement de SpagoBI 83

1.1.2 Choix de l'ETL 85

1.1.2.1 Installation de Talend Open Studio (TOS) 85

1.1.2.2 Lancement de Talend Open Studio(TOS) 89

1.1.3 Politique et opérations d'entreposage des données 89

1.1.3.1 L'extraction des données 90

1.1.3.2 La transformation et le chargement des données 91

1.2 Choix des autres outils 93

1.2.1 Outils de modélisation 93

1.2.2 Outils d'implémentation 93

1.2.2.1 Plateformes de développement et IDE pour SIO 93

1.2.2.2 Langages de programmation 94

1.2.2.3 Bibliothèques et Framework 94

1.2.3 Plateformes de développement et IDE pour SID 96

1.2.3.1 Langage de programmation 97

1.2.3.2 Bibliothèques et Frameworks 97

1.3 Captures d'écran des solutions 97

1.3.1 Présentation de l'application opérationnelle 97

1.3.2 Présentation des reporting sous SpagoBI 5.0 100

1.3.3 Présentation de la partie mobile (SpagoBIMobileEngine) 102

CHAPITRE 2 : CONDUITE DE PROJET 104

2.1 Gestion de projet 104

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

2.1.1 Diagramme de Gantt prévisionnel 104

2.1.2 Diagramme de Gantt réel 104

2.1.3 Intervenants au projet 104

2.1.4 Estimation des charges du projet 105

2.2 Evaluations et perspectives 106

2.2.1 Apports 106

2.2.2 Difficultés 106

2.2.3 Perspectives 106

CONCLUSION GENERALE 108

BIBLIOGRAPHIE 109

WEBOGRAPHIE 110

ANNEXES 111

Quelques dispositions du code CIMA utiles à la modélisation 111

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | I

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

DEDICACE

Ils sont le reflet des parents parfaits, ceux qui sacrifient toute leur vie pour leur progéniture. Ce travail est en votre honneur papa FARKASNA HINIMSALA et maman KATOUA Alliance.

Ils sont tous de frères silencieux, et aux coeurs desquels l'on a toujours un exemple à copier. FREDE, KIMPA, NDIKBA, ABLAO, FROUMSIA, WIWA, AKA, BODONA et ADJEWA ; si vous croyez que j'ai pu vous faire plaisir, sachez que vous m'avez tous donné de raisons de persévérer et de croire en l'avenir.

Pour moi elle est unique, jamais loin de mon sourire, toujours à la recherche de mon épanouissement et de la protection de mon honneur de futur époux, SOLYAL MACO Harmony sans toi j'aurais peut-être réussi ce challenge, mais jamais avec un si grand plaisir et enthousiasme.

Si je manque de te citer dans la liste de mes frères, c'est par ce que tu as quelque chose de supplémentaire frangin MBAIBAROUM TENGAR.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | II

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

REMERCIEMENTS

Du fond du coeur je tiens à remercier:

Y Pr Souleymane KOUSSOUBE, pour le temps qu'il a consacré à la supervision de mon travail, son envie intangible de recherche qui m'a guidé vers d'autres univers de l'informatique;

Y Le Ministère des finances et du Budget du Tchad à travers la SOLDE pour sa tutelle sans quoi je n'aurais pas reçu cette formation ;

Y L'ensemble du corps enseignant de l'IAI pour la tâche difficile qu'il a accepté afin que nous sortions de cette Ecole muris et utiles;

Y Mes chers condisciples pour la collaboration multiculturelle que je n'avais jamais rencontrée ;

Y Tous ceux qui ont, un tant soit peu apporté ne fût-ce qu'une infime participation, active ou passive ; que vous en soyez bénis ;

Enfin, que la nature créatrice reçoive bénédiction à travers les fruits à venir de mes efforts.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | III

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

EPIGRAPHE

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

AVANT-PROPOS

Le défi de la formation dans le domaine de l'informatique est le cheval de bataille de l'Institut Africain d'Informatique (IAI) qui a déjà formés depuis plus de quatre décennies, de grands cadres exerçant notamment en Afrique mais aussi au-delà des frontières du continent.

Dans le but de gagner ce challenge, l'IAI a créé en son sein les filières de formation suivantes : le cycle d'Analystes Programmeur (AP), le cycle de Licence Professionnel (né en 2014/2015), le cycle Ingénieurs, le cycle de Maîtrise d'Informatique Appliquée à la Gestion des Entreprises (MIAGE), et un cycle de Master en Administration Réseaux et Télécommunication (MART), Master Management Support et Application IT (MMSAIT), puis Master en Conception de Systèmes d'Information (MCSI). La fin de chaque cycle est marquée par un stage de fin de cycle.

C'est ainsi qu'en qualité d'étudiant de Master en Conception de Systèmes d'Information, nous avons reçu un travail de recherche intitulé : « Conception des systèmes décisionnels basée sur l'analyse des processus métiers ; application au domaine des assurances par la mise en place d'un environnement décisionnel et de production ». Ce thème est traité au laboratoire de l'IAI (le LAIMA). Ce dernier sera présenté dans la première partie de notre mémoire.

Le présent mémoire vise à présenter notre démarche conceptuelle basée sur l'analyse des processus métiers pour la mise en place des systèmes décisionnels (modèles dimensionnels). Cette démarche s'appuiera sur le domaine des assurances pour nous permettre de la pratiquer en mettant en place un système d'information décisionnel. Enfin, dans le but de disposer de données sources cohérentes, nous mettrons en place, d'abord un système d'information opérationnel.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | IV

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | V

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

RESUME

Le besoin d'être réactif dans les activités des entreprises prend de l'ampleur et, ceci, pour répondre aux besoins de clients de plus en plus exigeants. Ainsi, l'informatique décisionnelle se fait une place dans les entreprises pour permettre aux décideurs de disposer des indicateurs nécessaires à de prises de décisions rapides, efficaces et adaptées aux réalités extraites des données visualisées. Pourtant, les principaux précurseurs de l'entreposage des données ne fournissent pas de démarches ou techniques concises pour la conception des systèmes décisionnels.

Le LAIMA (Laboratoire Africain d'Informatique et de Mathématiques Appliquées) nous a donc soumis le thème intitulé : « Conception des systèmes décisionnels basée sur l'analyse des processus métiers ; application au domaine des assurances par la

mise en place d'un environnement décisionnel et de production ». Ce sujet se décompose donc en la mise en place d'une démarche de conception dimensionnelle basée sur l'analyse des processus métiers et, pour appliquer cette démarche, nous avons mis en oeuvre un Système d'Information Décisionnel (SID) et un Système d'Information Opérationnel (SIO) pour les compagnies d'assurance.

En effet, nous avons, dans le but de réaliser méthodiquement nos analyses, décrit au préalable les processus métiers au sein des compagnies d'assurance. Ensuite, nous avons choisi des méthodes de conception : UML couplé à 2TUP pour le SIO, la conception des systèmes décisionnels basée sur l'analyse des processus métiers pour le SID. Par ailleurs, pour l'ensemble du processus décisionnel, nous avons opté pour des logiciels libres : PostgreSQL pour l'entreposage des données, SpagoBI comme suite décisionnelle et Talend Open Studio (TOS) comme ETL.

Le système d'information décisionnel obtenu est enrichi des « engines » ou moteurs de SpagoBI permettant aussi et surtout de visualiser des rapports depuis un terminal mobile ou une tablette à travers SpagoBIMobileEngine.

Mots clés : processus métiers, SID, SIO, suite décisionnelle, analyse, conception

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | VI

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

ABSTRACT

The need to be proactive in business activities is growing in order to meet the increasing customers demanding. In this way, Business Intelligence (BI) is given a place in companies to enable decision-makers to have the necessary indicators for rapid, efficient decision-making adapted to the realities extracted from the visualized data.

The LAIMA (African Laboratory of Computer Science and Applied Mathematics) in its prerogatives of research has submitted to us the subject entitled « Methodology for designing decision-making systems based on business process analysis; Application to the insurance field by setting up a decision-making and production environment». This subject is thus decomposed into the implementation of a dimensional design approach based on the analysis of business processes. To implement this approach, we have made a Decision Information System (DIS) and an Operational Information System (OIS) for insurance companies.

Indeed, we have, in order to carry out methodically our analysis, described beforehand the business processes within the insurance companies. Then, in accordance with the complexity of tasks, we have chosen the following methods: UML coupled with 2TUP for the OIS, methodology for designing decision-making systems based on business process analysis for the DIS. Therefore, for the entire decision-making process, we have opted for open source software, and PostgreSQL for data warehousing, SpagoBI for decision suite and Talend Open Studio (TOS) as ETL.

The decision-making information system obtained is enriched by the engines of SpagoBI allowing, above all, to view reports from a mobile terminal or a tablet through SpagoBIMobileEngine.

Key words: Business processes, Decisional Information System, Operational Information System, decision suite, methodology, design.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | VII

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

SIGLES, ABREVIATIONS ET ACRONYMES

Sigles et abréviations Significations

IAI	Institut Africain d'Informatique
SID	Système d'Information Décisionnel
BI	Business Intelligence
LAIMA	Laboratoire Africain d'Informatique et de Mathématique Appliquée
AG	Assemblée Générale
CA	Conseil d'Administration
CS	Conseil Scientific
CP	Conseil des Professeurs
DG	Direction Générale
DAF	Direction des Finances et du Budget
DRD	Direction des Recherches et Développement
DE	Direction des Etudes
CC	Centre de Calcul
IARD	Incendie, Accidents et Risques Divers
ETL	Extract Transform and Load
RC	Responsabilité Civile
CIMA	Conférence Interafricaine des Marchés d'Assurances
CICA	Conférences Internationale des Contrôles d'Assurances
DW	Data Warehouse
SIO	Système d'Information Opérationnel
SIT	Système d'Information Transactionnelle
PME	Petite et Moyenne Entreprise
3FN	Troisième Forme Normale
OMT	Object Modeling Technique
UML	Unified Modeling Language
OMG	Object Management Group
UP	Unified Process
2TUP	Two Track Unified Process
OLTP	Online Transaction Processing
OLAP	On-Line Analytical Processing
ROLAP	Relationnal OLAP

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

MOLAP	Multidimentionnal OLAP
HOLAP	Hybride OLAP
SQL	Structured Query Language
SGBD	Système de Gestion de Base de Données
DNS	Domaine Name Service
SMTP	Simple Mail Transfer Protocol
NTP	Network Time Protocol
PHP	Hypertext Preprocessor
IDE	Integrated Development Language
JEE	Java Enterprise Edition
JSE	Java Standard Edition
ERP (SI)	Enterprise Ressource Planning
CRM (SI)	Customer Relationship Management
SCM (SI)	Supply Chain Management
SFA (SI)	Sales Force Automation

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | VIII

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | IX

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

FIGURES

Figure 1: Architecture de base ROLAP 21

Figure 2: Architecture de base MOLAP 22

Figure 3: Schéma en étoile 23

Figure 4: Schéma en Flocon 24

Figure 5: Vision architecturale de l'approche de Bill Inmon 29

Figure 6: Vision architecturale de l'approche de Ralph Kimball 31

Figure 7: Processus métier « Gestion des demande de devis » 37

Figure 8: Processus métier « Gestion des polices d'assurance » 38

Figure 9: Processus métier « Gestion des indemnités » 39

Figure 10: Processus métier « Recouvrement des primes » 40

Figure 11: Processus métier « Gestion des demandes de devis » annoté 41

Figure 12: Processus métier « Gestion de police d'assurance» annoté 41

Figure 13: Processus métier « Gestion des indemnisations » annoté 42

Figure 14: Processus métier « Recouvrement des primes » annoté 43

Figure 15: Diagramme de contexte SIO 47

Figure 16: Diagramme de contexte SID 47

Figure 17: Diagramme de cas d'utilisation (SIO) 49

Figure 18: Diagramme de cas d'utilisation (SID) 50

Figure 19: Diagramme de classe 55

Figure 20: Matrice d'analyse des priorités de Kimball 57

Figure 21: Processus métier « Gestion de demandes de devis » avec métriques 58

Figure 22: Dimension « Client » 59

Figure 23: Dimension « Actuaire » 59

Figure 24: Dimension « Zone_Geographique » 60

Figure 25: Dimension « Guichetier » 60

Figure 26: Dimension « ObjetAssure » 60

Figure 27: Dimension « Temps » 61

Figure 28: Branches « décision » du processus métier « Gestion de demandes de devis » 62

Figure 29: Schéma en étoile du fait « suivi_demandes» 63

Figure 30: Processus métier « Gestion de police d'assurance » avec des métriques 64

Figure 31: Dimension « Police_assurance » 65

Figure 32: Dimensions communes aux deux (2) premiers faits 65

Figure 33: Etude des métriques 65

Figure 34: Fait « Suivi_Police » 66

Figure 35: Processus métier « Gestion de primes » avec métriques 67

Figure 36: Dimension « Comptable » 68

Figure 37: Fait « Recouvrement_Primes » 69

Figure 38: Processus métier « Gestion des indemnités» avec métriques 70

Figure 39: Dimension « Expert » 71

Figure 40: Dimension « Expert_externe » 71

Figure 41: Dimension « Autorite_judiciaire» 71

Figure 42: Dimension « Sinistre/Dommage» 72

Figure 43: Fait « Suivi_Indemnités » 73

Figure 44: DS du CU « S'authentifier 74

Figure 45: Diagramme de séquence « demander devis » 74

Figure 46: Diagramme de séquence « consulter reporting » 75

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Figure 47: Diagramme de séquence « Gérer police d'assurance» 75

Figure 48: Diagramme d'activité « demander devis » 76

Figure 49: Diagramme d'activité « consulter reporting » 76

Figure 50: Diagramme d'activité « gérer police d'assurance » 77

Figure 51: Diagramme de déploiement 78

Figure 52: Architecture technique 79

Figure 53: Page d'authentification de SpagoBI 84

Figure 54: Page d'accueil « biadmin » de SpagoBI 84

Figure 55: Page après lancement de l'exécutable TOS 86

Figure 56: Licence TOS 86

Figure 57: Configuration de TOS 87

Figure 58: Configuration de TOS (suite) 87

Figure 59: Chargement des bibliothèques TOS 88

Figure 60: Guide de prise en main de TOS 88

Figure 61: Page d'accueil TOS 89

Figure 62: Configuration de la connexion à la source 90

Figure 63: Extraction des tables 91

Figure 64: Préparation de la transformation des données 91

Figure 65: Transformation des données 92

Figure 66: Entête de page d'accueil du SIO 98

Figure 67: Page de connexion du SIO 98

Figure 68: Page d'accuei de l'adminstrateur du SIO 99

Figure 69: Liste des polices d'assurance 99

Figure 70: Formulaire d'enregistrement des polices d'assurance 100

Figure 71: Page de connexion de SpagoBI 100

Figure 72: Jeux de données 101

Figure 73: Tableau de bord pour observer le comportement des clients 101

Figure 74: Tableau de bord du fait « suivi_PoliceAssurance » 102

Figure 75: Page de connexion et liste des rapports 102

Figure 76: Histogramme et tableau dans SpagoBIMobileEngine 103

Figure 77: Diagramme de Gantt prévisionnel 104

Figure 78: Diagramme de Gantt réel 104

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | X

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

TABLEAUX

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | XI

Tableau 1: Etude SIO vs SID 20

Tableau 2: ROLAP vs MOLAP 22

Tableau 3: Cas d'utilisation 48

Tableau 4: Classification des cas d'utilisation en itérations 51

Tableau 5: Nombre d'itérations 52

Tableau 6: Dimensions communes aux trois (3) premiers faits 68

Tableau 7: Dimensions communes aux faits 73

Tableau 8: Pentaho vs SpagoBI 82

Tableau 9: Intervenants au projet 104

Tableau 10: Charges du projet 105

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 1

Mise en place d'un Système d'Information Décisionnel (SID) pour assurances

INTRODUCTION GENERALE

De plus en plus l'Homme cherche à adapter ses compétences et ses entreprises aux domaines qui répondent les mieux à un contexte d'actualité. Ceci est un principe général pour les Hommes soucieux de s'accomplir.

Si ce principe, réaliste et vérifiable dans nos sociétés existe dans la vie courante, que dire du domaine de l'informatique perpétuellement en mutation et de plus en plus diversifié ? Un domaine dont les défis majeurs sont : l'innovation, la créativité, la recherche quotidienne des solutions améliorées pour une gestion efficace, prompte et éclairée de l'ensemble des processus d'une organisation.

De l'informatique pour la stricte gestion des activités bureautiques (outils de calculs, courriers électroniques...), nous sommes rapidement passés à l'informatique pour la gestion transactionnelle sous diverses formes (le transactionnel simple, les ERP, les solutions cloud...). Puis du transactionnel, nous atterrissons au décisionnel qui représente probablement aujourd'hui, dans le monde du management, l'informatique adéquate pour une gestion guidée des entreprises. Cette diversification de solutions répond au besoin d'apporter des solutions clés à des problèmes capitaux, courants dans les activités de l'Homme et avérés facteurs de baisse de production. Dans ce contexte précis, il s'agit de la question de la gestion des entreprises.

Vous êtes manager ou décideur, vous voulez garder un regard sur la croissance de votre chiffre d'affaire, vous êtes soucieux de contrôler les performances de vos équipes, vous souhaitez suivre l'ensemble des charges imposées à votre production (matières premières, ressources humaines...), mais vos systèmes d'information opérationnels ne sont pas capables de vous fournir les informations datées et historiques pour maîtriser cette gestion. Ces derniers, disons-le, vous aident à la gestion des activités, des ressources financières et matérielles de façon à ne rien indiquer de précis sur les évolutions de tous ces facteurs à la base de votre production. Ils ne vous disent jamais si en ce jour, en cette semaine, en ce mois, ou encore en cette année vous avez réalisé un gain ou un déficit dans tel ou tel autre agence de votre entreprise pour telle ou telle autre raison. Ces mêmes systèmes transactionnels, peu importe leur nombre, sont conçus pour une gestion propre, nous voulons dire en nettoyant les doublons de leur base de données, en conservant une base de données actualisée... fournissant ainsi des observations historiques limitées. Les nombreuses tables et jointures (dans le but de répondre à la 3FN) des bases de données transactionnelles ne sont pas favorables à de requêtes performantes.

Ainsi, Les professionnels de l'informatique, pour répondre aux limites des systèmes transactionnels, ont fait naître, dans les années 90, l'informatique décisionnelle (Business Intelligence en anglais). Le but du BI est d'aider à mieux connaitre et comprendre les

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 2

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

processus et les résultats pour la prise des décisions. Cette forme de pratique informatique vise, entre autre, à fournir un environnement idéal pour tirer des informations stratégiques, un temps de réponse aux requêtes assez bref, et surtout un environnement uniquement dédié aux décideurs.

Pourtant, la documentation sur la mise en oeuvre de ces systèmes d'information reste totalement générique, et surtout en ce qui concerne la conception des modèles dimensionnels. Il est clair que la réussite d'un projet décisionnel passe nécessairement par la réussite de la conception dimensionnelle. Ralph Kimball et Bill Inmon, les pères fondateurs de l'informatique décisionnelle ont introduit deux méthodes de conception qui font totalement abstraction des éléments préalables aux succès d'une bonne conception décisionnelle. La phase d'analyse des besoins est réduite ou occultée : les méthodes de développement passent directement à la modélisation des données du SID. Les besoins des utilisateurs peuvent donc ne pas être satisfaits par la mise en place du SID entrainant en outre, une mauvaise analyse des concepts métiers à prendre en compte lors de la conception. De plus, la confrontation est alourdie suivant le nombre de schémas résultant de l'analyse des besoins utilisateurs et sources.

C'est pourquoi, nous avons reçu le thème : « Conception des systèmes décisionnels basée sur l'analyse des processus métiers ; application au domaine des assurances par la mise en place d'un environnement décisionnel et de production ». Il s'agit en effet de présenter une technique de conception dimensionnelle inspirée par l'analyse des processus métiers. L'assurance sera notre domaine applicatif pour la mise en oeuvre de cette technique de conception. La mise en place d'un environnement de production est uniquement motivée par le besoin de disposer de sources de données cohérentes tandis que l'environnement décisionnel sera la matérialisation de la conception décisionnelle basée sur l'analyse des processus métiers.

Le présent document est subdivisé en trois grandes parties :

- La présentation générale qui présente la structure d'accueil (LAIMA), le sujet et son contexte ainsi que les concepts liés au sujet.

- L'analyse et la conception évoque quant à elle des outils et techniques d'analyse puis de l'analyse et de la conception elle-même. C'est précisément dans cette partie que nous mettrons en oeuvre notre démarche de conception dimensionnelle.

- Enfin la troisième et dernière partie présente la mise en oeuvre du projet (présentation des outils de mise en oeuvre et de la conduite de projet).

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

PARTIE 1 : PRESENTATION GENERALE

Afin de clarifier le contexte et les éléments fondamentaux de cette étude, nous avons consacré la première partie de notre mémoire à la présentation générale qui comporte deux chapitres. Le premier présente la structure d'accueil (IAI-LAIMA) et le sujet (intitulé, problématiques et intérêts), et le deuxième évoque des concepts rattachés aux domaines d'étude.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 3

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 4

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

CHAPITRE 1 : STRUCTURE D'ACCUEIL ET SUJET

1.1 STRUCTURE D'ACCUEIL

1.1.1 Présentation de l'IAI

L'institut Africain d'Informatique (IAI) est une école inter-état d'enseignement supérieur créée en 1971 à Fort-Lamy (actuel Ndjamena). Son siège est à Libreville au GABON. Elle compte onze (11) pays membres qui sont : le Bénin, le Burkina Faso, le Cameroun, la République du Congo, la Côte d'Ivoire, le Gabon, le Niger, la République Centrafricaine, le Sénégal, le Tchad et le Togo.

? Formation

L'IAI intègre dans son cursus de formation des profils d'Analystes Programmeurs (AP), d'Ingénieurs de conception, de Maîtres Informaticiens (MIAGE), de différents profils qualifiés Master et de Licences Professionnelles (LP). Ces filières sont regroupées en deux cycles : le premier est constitué de la filière AP et LP et le second, des trois autres. L'entrée à l'IAI se fait par voie de concours pour l'ensemble des cycles à l'exception du cycle Master et LP.

? Partenariats

L'IAI a des représentions dans trois pays à savoir : le Cameroun, le Niger et le Togo. Divers partenariats lient cette école à d'autres à travers le monde. On peut citer l'Université de Poitier, de LIMOS, de LIAS et bien d'autres.

1.1.2 Le LAIMA

L'IAI abrite un laboratoire de recherche dénommé « LAIMA » (Laboratoire Africain d'Informatique et de Mathématiques Appliquées) qui a pour vocation d'offrir un environnement de recherche propice et adéquat.

Le LAIMA accueille les étudiants en fin de cycle désirant y préparer leurs projets de fin de formation. Ce qui est en effet notre cas. Le LAIMA est sous la supervision de la DRD (Direction de Recherche et de Développement).

Les objectifs du LAIMA sont de contribuer au rayonnement scientifique international de l'IAI à travers trois types d'activités :

V' La publication des articles de recherche dans de revues scientifiques avec facteur d'impact ;

V' Participation aux manifestations scientifiques (colloques, séminaires, ...) au niveau national sous régional et international ;

V' Participation à des manifestations scientifiques d'envergure internationale.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 5

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Le LAIMA évolue selon plusieurs axes qui sont orientés dans les domaines de l'informatique et des mathématiques telles que : l'Optimisation, les Statistiques, l'Informatique décisionnelle, le Calcul scientifique, l'Intelligence Artificielle, l'Analyse Numérique...

1.2 SUJET

1.2.1 Contexte et intitulé

La tâche d'analyse située en amont du processus de développement a pour objectif de définir l'environnement du projet et la majorité des données et des traitements nécessaires au processus de développement. Elle impacte donc tout le processus de développement. De plus, le SID a pour fonction de centraliser plusieurs domaines d'activités ; il est donc transversal à l'organisation. Il vise donc à répondre aux besoins des décideurs stratégiques et des décideurs tactiques qui ont parfois des intérêts divergents. Les spécificités du SID et l'importance de la tâche d'analyse au sein du processus de développement justifient une méthode d'analyse des besoins spécifique au SID. De plus, 80% des projets ne répondent pas aux besoins des décideurs [Schiefer et al. 2002] car cette étape est occultée ou pas développée dans des projets réels.

Ces chiffres, s'expliquent par le fait que de nombreuses méthodes de développement de SID commencent directement par la mise en place du schéma conceptuel. Malheureusement ces méthodes ne proposent pas une phase d'analyse spécifique au SID. Ils sont aussi le fruit d'une mauvaise communication entre les utilisateurs et les informaticiens [Mazon et al. 2005].

Cependant, parmi ces méthodes, aucune n'est largement reconnue car toutes les tâches précédant la création du schéma ne sont pas traitées complètement par les méthodes existantes. Elles ne reposent pas sur un support formel et d'autre part, les concepteurs ne sont pas guidés. Ces derniers sont donc uniquement guidés par leurs expériences et leurs seules capacités d'analyse. Pourtant, les concepteurs, relativement à leurs compétences, pouvaient se servir d'une technique formelle permettant de guider leurs analyses et ainsi, de minimiser la marge d'erreur jusqu'alors attribuée à la conception des SID.

Sur la base de l'ensemble, ou du moins de la plupart de ces raisons, nous avons reçu comme sujet de mémoire : « Conception des systèmes décisionnels basée sur l'analyse des processus métiers ; application au domaine des assurances par la mise en place d'un environnement décisionnel et de production ».

1.2.2 Problématiques

La tâche qui nous est confiée consiste à la mise en place d'une démarche conceptuelle pour les SID basée sur l'analyse des processus métiers avec pour domaine d'application, les compagnies d'assurance.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 6

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Etant donné la délicatesse d'une telle tâche, il est judicieux, à fin d'espérer une démarche claire et méthodique, de s'exercer à savoir :

- Quels sont les atouts offerts par les méthodes de conceptions existantes ?

- Quels éléments de ces méthodes peuvent-ils s'avérer complémentaires par rapport à la nôtre ?

- Quelles informations pourrons-nous tirer de façon quasi-automatique de la description et de l'analyse des processus métiers ?

- Quelle technique d'analyse rigoureuse faudra-t-il envisager pour valoriser la démarche par l'analyse des processus métiers ?

En ce qui concerne le domaine d'application :

- De quelle conception doit être schématisée la base de données source pour

favoriser une extraction, un traitement et un transfert cohérent vers l'entrepôt ?

- Que faut-il savoir des politiques d'assurance pour être en accord avec les réalités

et les contraintes techniques, juridiques, ... ?

- Quel outil ETL choisir pour assurer un transfert de source aussi bien homogène

qu'hétérogène ?

- Quelle technique de conception choisir pour notre entrepôt de données ?

- Quelle suite BI faut-il choisir pour implémenter un tel entrepôt ?

- Quelle technique mettre en place pour la fouille des données ?

- Comment réaliser les analyses dans le but de produire des tableaux de bord utiles

à la prise des décisions ?

- Comment permettre aux utilisateurs d'effectuer des analyses personnalisées et de

fabriquer leurs propres tableaux de bord ?

- Quelle politique de sécurité mettre en place pour un tel SID ?

- Quel rôle accorder à l'environnement juridique dans lequel évoluent les

compagnies et mutuelles d'assurance ?

La conclusion du présent document est censée apporter des réponses satisfaisantes à l'ensemble de ces questions qui, jusqu'à ce paragraphe tourbillonnent notre esprit.

1.2.3 Intérêts

La mise en oeuvre définitive d'une telle solution renferme deux intérêts :

Les intérêts scientifiques et techniques :

? Apporter une nouvelle approche d'analyse et de conception des SID qui prendrait en compte la description et l'analyse des processus métiers ;

? Offrir un environnement décisionnel totalement open source ;

? Disposer de moyens de visualisation de données sur tout type de terminal

Les intérêts opérationnels :

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

' gérer la production au sein de compagnies d'assurance ;

' observer en temps réel l'évolution des activités ;

' faire des analyses propres, suivant des axes relativement délicats ;

' avoir des données datées et stockées pour des durées assez longues ;

' être à l'écoute des clients ;

' générer de façon automatique des états statistiques ;

' être réactifs vis-à-vis de la clientèle.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 7

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 8

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

CHAPITRE 2 : CONCEPTS LIES AUX DOMAINES D'ETUDE

2.1 Assurances

2.1.1 Définitions

« L'assurance est une opération par laquelle une partie, l'assuré, se fait promettre, moyennant une rémunération, prime ou cotisation, une prestation par une autre partie - l'assureur - en cas de survenance d'un sinistre. » [Encyclopedia Universalis].

« Contrat par lequel, une partie, l'assuré, se fait remettre moyennant une rémunération (la prime), pour lui ou pour un tiers, en cas de réalisation d'un risque, une prestation par une autre partie, l'assureur, qui, prenant en charge un ensemble de risques, les compense conformément à la loi de la statistique. » [Lexique des termes juridiques 2012].

2.1.2 Historiques

Les premières traces de l'assurance ont été retrouvées dans les 2000 ans avant Jésus Christ (J.C), en effet les habitants de Babylone utilisaient l'ancêtre de la méthode de transfert de risques, méthode qui fut par la suite reprise dans le Code d' Hammourabi. Le principe de cette méthode se résumait au fait que si une personne devait emprunter pour faire transporter ces marchandises et bien il devait payer un surplus à la personne qui lui avait prêté l'argent, par contre si les biens transportés étaient subtilisés ou perdus et bien la personne n'avait rien à rembourser.

Ce n'est qu'au premier millénaire av. J.C. que l'on a vu apparaître les prémices de l'assurance moderne, en effet les habitants de la ville de Rhodes mirent au point un système appelé "mutualisation". Le principe est simple, les personnes dont la marchandise arrive à bon port doivent donner de l'argent aux personnes dont la marchandise a été détruite. Par la suite en l'an 400 av. J.C., le prêt à la grosse aventure est introduit par les marchands venant de Grèce, le principe est simple, un bateau est affrété aux frais d'un tiers, si ce navire arrive à bon port avec l'intégralité de la marchandise et bien le tiers se voit remboursé son prêt avec un taux d'intérêt bien supérieur au taux d'usure, par contre si le bateau n'arrive pas et bien le tiers perd l'intégralité de son prêt.

Plus tard, l'assurance vie et l'assurance santé firent leur apparition sous l'impulsion des Romains et des Grecs. Cependant, il est important de noter que dans le Moyen Âge, c'était les guides qui étaient en charge des frais d'obsèques.

Bien sûr tout ceci n'était que les prémices de l'assurance, mais c'est en Europe au 17e siècle que l'on vit apparaître les bases d'une assurance moderne. En effet, fin 17e, Londres prend une ampleur de plus en plus considérable et rassemble de plus en plus de marchands, de ce fait la demande en assurance maritime augmente elle aussi. C'est ainsi qu'Edward Lloyd ouvrit l'un des hauts lieux de l'assurance maritime, cet endroit permettait aux marins et aux personnes qui assuraient les bateaux de se rencontrer. De

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 9

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

nos jours, cet endroit existe encore et il reste encore l'un des plus glorieux endroits de l'assurance maritime. Londres est l'un des berceaux de l'assurance moderne, en effet c'est après le terrible incendie de Londres en 1666 (plus de 13000 bâtiments furent dévastés par les flammes) que Nicholas Barbon ouvrit une agence destinée à assurer les bâtiments.

Aux États-Unis aussi, on vit apparaitre quelques innovations grâce à Benjamin Franklin (Philadelphia Contributionship for the Insurance of Houses from Loss by Fire) qui fut le premier à ne pas vouloir assurer des maisons qui étaient trop soumises aux risques d'incendie.

2.1.3 Différents types d'assurances

On distingue deux grandes familles d'assurance :

Les assurances de dommages : regroupent à la fois des assurances de responsabilité (responsabilité civile familiale, responsabilité civile du conducteur, responsabilité professionnelle...) et des assurances de biens (assurance des biens meubles et immeubles, des dommages causés au véhicule...).

Les assurances de la personne : couvrent les risques inhérents à la vie humaine et proposent un ensemble complet de solutions adaptées à chaque situation. Certains contrats prévoient des prestations en cas d'atteinte à l'intégrité physique : décès, invalidité (assurances en cas de décès), d'autres permettent la constitution d'une épargne et le versement de celle-ci sous forme de rente ou de capital si la personne assurée est en vie au terme du contrat (assurances en cas de vie)...

Ainsi, une liste non exhaustive des différents types d'assurances peut être présentée. Il s'agit de :

? L'assurance responsabilité civile, familiale ou vie privée : Aussi appelée RC, elle couvre les conséquences financières, parfois très importantes, de dommages découlant de la vie privée. Cette assurance protège des fautes d'attention et des imprudences qui provoquent un dommage à autrui mais aussi des dégâts engendrés par tes enfants, tes animaux domestiques, etc.

? L'assurance accidents du travail et maladies professionnelles des exploitants agricoles (ATEXA) : Assurance qui couvre les risques professionnels ; accidents de travail, maladies professionnelles. Elle ouvre droit à des prestations en nature et en espèces.

? L'assurance capitalisation : Contrat par lequel, en contrepartie de primes périodiquement versées par l'assuré, une société d'assurance s'engage à verser la capitalisation de ces sommes, augmentées des produits financiers issus de leur placement, diminuées des frais de gestion, soit à l'assuré s'il est toujours en vie, soit, en cas de décès, à un bénéficiaire désigné par lui. Dans la mesure ou le capital

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 10

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

sera nécessairement payé par l'assureur, l'application à ce contrat, des articles L. 132-12 et 132-13 du code des assurances, prévus pour l'assurance-vie, a été posée et résolue favorablement par la jurisprudence.

> L'assurance vie : Contrat d'assurance par lequel, une personne (le souscripteur), obtient d'une autre (l'assureur), moyennant payement d'une prime, le versement, à elle-même si elle survit à une date déterminée ou, en cas de décès, à un tiers (l'assuré) qu'elle désigne, un capital ou une rente. Il bénéficie d'un régime fiscal de faveur.

> L'assurance en cas de vie : Assurance par laquelle, le risque couvert est constitué par la survie de l'assuré à un âge déterminé ou à une date déterminée.

> L'assurance décès : Assurance qui garantit aux ayants droit de l'assuré qui décède le payement d'une somme appelée capital-décès.

> L'assurance de protection juridique : Opération par laquelle un assureur, moyennant payement d'une prime ou d'une cotisation, prend en charge, en cas de litige opposant l'assuré à un tiers, les frais de la procédure civile, pénale ou administrative dans laquelle l'assuré est impliqué comme défendeur ou comme demandeur (dans la limite de certains plafonds) ou fournit des services pour aider l'assuré à résister à une réclamation dont il est l'objet ou à obtenir réparation à l'amiable du dommage qu'il subit. L'assurance de protection juridique relaie opportunément l'aide juridictionnelle pour tous ceux qui n'y ont pas accès du fait de leurs ressources.

> L'assurance chômage : Système d'indemnisation du chômage total, à base conventionnelle, créé en 1958 par une convention interprofessionnelle, étendue et rendue obligatoire en 1967.

> L'assurance en cas de décès : Assurance par laquelle l'assureur s'engage, moyennant payement d'une prime, à verser au tiers désigné dans le contrat un capital ou une rente en cas de mort de l'assuré souscripteur.

> L'assurance garantie des salaires : Système d'assurance contre risque de non-paiement des salaires et sommes assimilées, lorsque l'entreprise est en état de redressement ou de liquidation judiciaire. L'employeur est tenu d'assurer ses salariés et verse à cet effet une cotisation à l'association patronale « Assurance garantie des salaires » perçue par l'organisme gestionnaire du régime d'assurance chômage qui avance les fonds au profit des salariés bénéficiaires de la garantie.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 11

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

> L'assurance invalidité : Assurance accordant aux personnes ayant subi de manière durable une réduction de leur capacité de travail. Le risque invalidité est couvert dans tous les régimes de Sécurité sociale.

> L'assurance-maladie : Assurance procurant des « prestations en espèces » et des « prestations en nature » en cas de maladie. Le risque maladie est couvert dans tous les régimes de base obligatoires.

> L'assurance-maladie des exploitants agricoles (AXEMA) : Cette assurance couvre les risques maladie, maternité, invalidité pour de exploitant agricoles. En cas de maladie, elle n'ouvre droit qu'à des prestations en nature.

> L'assurance maternité : Assurance procurant des prestations en espèces et des prestations en nature sans ticket modérateur en cas de maternité. Le régime maternité est couvert dans tous les régimes à base obligatoires. Toutefois certains régimes n'accordent pas d'indemnités journalières mais des allocations forfaitaires par exemple régime des professions non salariées non agricoles.

> L'assurance veuvage : Dispositif qui garantit au conjoint survivant de l'assuré du régime général une allocation de veuvage temporaire lorsque, résident en France, il satisfait à de conditions d'âge et de ressources fixées par décret.

> L'assurance vieillesse : Assurance accordant une pension aux personnes qui justifient d'une certaine durée d'assurance et qui partent à la retraite à 60 ans. Certains régimes accordent toutefois des pensions à des personnes qui partent en retraite avant 60 ans.

> L'assuré social : Toute personne affiliée à un régime de Sécurité sociale.

> L'assurance RC Auto : Attention que seule la RC auto est obligatoire si tu possèdes une voiture. L'assurance auto est plus large que la RC classique: elle vise aussi l'assurance omnium, l'assurance conducteur... Les garanties sont parfois présentées différemment en fonction des assureurs notamment en matière de franchise (somme de base à débourser en cas d'accident). Tu dois donc bien examiner la portée des différentes assurances « auto » et lire tous les termes du contrat qui t'est proposé. Le prix dépendra de nombreuses choses comme les services demandés, le type d'auto (citadine ou roadster) et de la cylindrée. De nombreux jeunes cherchent l'assurance la moins chère mais sans toujours prendre conscience qu'ils seront peut-être moins bien protégés aussi.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 12

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

? Assurance incendie : Il s'agit de l'assurance la plus répandue. Elle peut indemniser les dommages matériels causés par l'incendie, l'explosion, la foudre ou encore le heurt par un animal ou moyen de transport, la grêle et les catastrophes naturelles sur le bâtiment. Si tues en kot et qu'il n'est pas assuré et que tu y mets le feu, tu devras rembourser tous les dégâts. Certains contrats de bail incluent d'office ce type d'assurance. Vérifie avant auprès de tes parents s'ils en possèdent déjà une te couvrant (banque, assureur, etc.). Attention: l'assurance incendie ne couvre pas forcément tes biens personnels!

? Assurance hospitalisation : La mutualité rembourse, via l'assurance obligatoire soins de santé et indemnités, une partie des frais liés à une hospitalisation mais pas l'entièreté. La souscription d'une assurance hospitalisation te permet d'obtenir le remboursement de prestations non remboursées par l'assurance maladie obligatoire. Elle est individuelle mais certains employeurs proposent une assurance collective.

? Assurance voyage : Ces assurances sont très variées et vont du rapatriement au dépannage d'une jeep au fond de la jungle. Elles sont proposées par les agences de voyages, les organismes de cartes de crédit, les banques, les agents ou courtiers d'assurances, les mutuelles, etc. Tu dois te renseigner auprès de chacune car elles n'offrent pas les mêmes garanties.

? Assurance volontaire : Si tu travailles comme volontaire dans une petite association, tu as droit à une assurance qui te couvre durant les heures d'activité que tu prestes. Demande-là auprès de l'organisme qui t'emploie. Concrètement, les organisations qui travaillent avec des volontaires peuvent s'enregistrer et demander un agrément auprès de leur province ou commune.

? Etc.

2.1.4 Le code CIMA

La CIMA (Conférence Interafricaine des Marchés d'Assurance) est un organisme communautaire du secteur des assurances. Il est issu de l'évolution de la Conférence Internationale des Contrôles des Assurances (CICA) née le 17 juillet 1962 à paris entre la France d'une part et quatorze Etats africains et Malgache d'autre part.

Le 10 juillet 1992, la CICA devient Conférence Interafricaine des Marchés d'Assurance (CIMA). Le traité est signé à Yaoundé (Cameroun) instituant une organisation intégrée de l'industrie des assurances dont l'organe communautaire est la CIMA.

Les Etats signataires de ce traité sont : Bénin, Burkina Faso, Cameroun, Centrafrique, Congo, Comores, Côte d'Ivoire, Gabon, Guinée, Guinée Equatoriale, Mali, Niger, Sénégal, Tchad et Togo.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 13

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

2.1.4.1 Objectifs

Les Hautes Parties Contractantes instituent entre elles une organisation intégrée de l'industrie des assurances dans les Etats africains dénommée Conférence Interafricaine des Marchés d'Assurances, en abrégé CIMA, ci-après dénommée la Conférence, en vue de:

1) Prendre toutes mesures nécessaires pour le renforcement et la consolidation d'une coopération étroite dans le domaine de l'assurance, afin que leurs marchés soient à même de couvrir par des garanties mieux adaptées aux réalités africaines et tenant compte de leurs possibilités contributives, les risques du secteur agricole et rural ainsi que ceux liés au commerce extérieur dans la mesure où cela est techniquement faisable ;

2) Encourager, en vue d'accroître la rétention au plan national et régional, la mise en place de facilités permettant aux organismes d'assurances et/ou de réassurance opérant dans leur pays, d'effectuer des échanges d'affaires par des techniques adéquates, notamment par la souscription et la gestion des grands risques dépassant la capacité de conservation d'un marché ;

3) Prendre également des dispositions appropriées en vue de permettre l'investissement local, dans les conditions les meilleures au profit de l'économie de leur pays ou de la région, des provisions techniques et mathématiques générées par les opérations d'assurance et de réassurance, sous réserve des impératifs techniques relatifs aux risques assurés et au genre de couverture en réassurance fournie ainsi que des critères de sécurité, de liquidité, de rentabilité et de diversité;

4) Poursuivre la politique de formation de cadres et techniciens en assurance pour les besoins des entreprises et des administrations dans les États membres ;

5) Rationaliser la gestion des ressources humaines de ces entreprises et administrations par la mise en oeuvre de la spécialisation et de la formation permanente ;

6) Créer des structures communes, chargées de l'étude, de la définition et de la mise en oeuvre des orientations politiques et des décisions dans les domaines précités, en vue de :

a) faciliter les conditions d'un développement sain et équilibré des entreprises d'assurance ;

b) favoriser la constitution, sur l'ensemble de leurs pays, d'un marché élargi et intégré réunissant les conditions d'un équilibre satisfaisant au point de vue technique, économique et financier ;

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 14

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

c) mettre en place de nouveaux instruments financiers pour mieux rentabiliser les placements des compagnies d'assurances et de réassurance et autres investisseurs institutionnels, notamment par la création dans leurs zones monétaires respectives de marchés financiers ;

7) Poursuivre la politique d'harmonisation et d'unification des dispositions législatives et réglementaires relatives aux opérations techniques d'assurance et de réassurance, au contrôle applicable aux organismes d'assurances et de réassurance exerçant sur leur territoire, ainsi qu'à tous autres objectifs de nature à contribuer au plein essor de l'industrie des assurances, au développement des instruments de gestion et des moyens de prévention des risques dans les États membres ;

8) Pourvoir en ressources financières, matérielles et humaines les institutions communes qu'elles sont appelées à créer pour promouvoir la coopération ainsi définie en matière d'assurance et de réassurance.

(Source : http://www.cima-afrique.org/pg.php?mode=pg&caller=traite2)

2.1.4.2 Quelques articles du code CIMA LIVRE I : LE CONTRAT

TITRE I : RÈGLES COMMUNES AUX ASSURANCES DE DOMMAGES NON MARITIMES ET AUX ASSURANCES DE PERSONNES

CHAPITRE PREMIER : DISPOSITIONS GÉNÉRALES

Article 4

Réassurance - Coassurance

(Modifié par Décision du Conseil des Ministres du 20 avril 1995)

Réassurance : Dans tous les cas où l'assureur se réassure contre les risques qu'il a

assurés, il reste seul responsable vis-à-vis de l'assuré.

Multirisque : Plusieurs risques différents, notamment par leur nature ou par leur taux, peuvent être assurés par une police unique.

Coassurance : Plusieurs assureurs qui opèrent au sein d'un même État, peuvent également s'engager par une police unique. En cas de sinistre, il n'y a pas de solidarité entre les Coassureurs dans leurs rapports avec l'assuré.

Article 8

Mentions du contrat d'assurance

(Modifié par Décision du Conseil des Ministres du 11 avril 2011) Les polices d'assurance doivent indiquer :

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 15

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

o les noms et domiciles des parties contractantes ;

o la chose ou la personne assurée ;

o la nature des risques garantis ;

o le moment à partir duquel le risque est garanti et la durée de cette garantie ;

o le montant de cette garantie ;

o la prime ou la cotisation de l'assurance et ses conditions de paiement;

o les conditions de la tacite reconduction, si elle est stipulée ;

o les cas et conditions de prorogation ou de résiliation du contrat ou de cessation de ses effets ;

o les obligations de l'assuré, à la souscription du contrat et éventuellement en cours de contrat, en ce qui concerne la déclaration du risque et la déclaration des autres assurances couvrant les mêmes risques ;

o les conditions et modalités de la déclaration à faire en cas de sinistre ;

o le délai dans lequel les indemnités sont payées ;

o pour les assurances autres que les assurances contre les risques de responsabilité, la procédure et les principes relatifs à l'estimation des dommages en vue de la détermination du montant de l'indemnité ;

o la prescription des actions dérivant du contrat d'assurance ;

o les formes de résiliation ainsi que le délai de préavis.

Les clauses des polices édictant des nullités, des déchéances, des résiliations de plein droit ou des exclusions ne sont valables que si elles sont mentionnées en caractères très apparents.

Les polices des sociétés d'assurance mutuelles doivent constater la remise à l'adhérent du texte entier des statuts de la société.

CHAPITRE III : OBLIGATIONS DE L'ASSUREUR ET DE L'ASSURÉ Article 12

Obligations de l'assuré

L'assuré est obligé :

1) de payer la prime ou cotisation aux époques convenues ;

2) de répondre exactement aux questions posées par l'assureur, notamment dans le formulaire de déclaration du risque par lequel l'assureur l'interroge lors de la conclusion du contrat, sur les circonstances qui sont de nature à faire apprécier par l'assureur les risques qu'il prend en charge ;

3) de déclarer, en cours de contrat, les circonstances nouvelles qui ont pour conséquence, soit d'aggraver les risques, soit d'en créer de nouveaux et rendent de ce fait inexactes ou caduques les réponses faites à l'assureur, notamment dans le formulaire mentionné au 2°) ci-dessus.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 16

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

L'assuré doit, par lettre recommandée ou contresignée, déclarer ces circonstances à l'assureur dans un délai de quinze jours à partir du moment où il en a eu connaissance.

En cas de lettre contresignée, un récépissé servant de preuve doit être délivré à l'assuré ;

4) de donner avis à l'assureur, dès qu'il en a eu connaissance et au plus tard dans le délai fixé par le contrat, de tout sinistre de nature à entraîner la garantie de l'assureur. Ce délai ne peut être inférieur à cinq jours ouvrés.

En cas de vol ou en cas de sinistre mortalité de bétail, ce délai est fixé à 48 heures.

Les délais ci-dessus, peuvent être prolongés d'un commun accord entre les parties contractantes.

Les dispositions mentionnées aux 1°), 3°) et 4°) ci-dessus ne sont pas applicables aux assurances sur la vie.

Article 13

Paiement de la prime

Alinéa 2 : La prise d'effet du contrat est subordonnée au paiement de la prime par le souscripteur

Alinéa 4 : Par dérogation au principe énoncé aux alinéas précédents, un délai maximum de paiement de soixante (60) jours à compter de la date de prise d'effet ou de renouvellement du contrat peut être accordé au souscripteur, pour les risques dont la prime du contrat excède quatre-vingt (80) fois le SMIG annuel du pays de localisation à l'exception des contrats des branches automobile, maladie et marchandises transportées.

Alinéa 8: Les dispositions des alinéas 2 à 7 du présent article ne sont pas applicables aux assurances sur la vie.

(Source : code CIMA 2014)

2.2 Informatique décisionnelle (Business Intelligence)

Toutes les entreprises du monde disposent d'une masse de données plus ou moins considérable. Ces informations proviennent soit de sources internes (générées par leurs systèmes opérationnels au fil des activités journalières), ou bien de sources externes (web, partenaire, etc.).

Cette surabondance de données, et l'impossibilité des systèmes opérationnels de les exploiter à des fins d'analyse conduit, inévitablement, l'entreprise à se tourner vers une nouvelle informatique dite décisionnelle qui met l'accent sur la compréhension de l'environnement de l'entreprise et l'exploitation de ces données à bon escient.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 17

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

En effet, les décideurs de l'entreprise ont besoin d'avoir une meilleure vision de leur environnement et de son évolution, ainsi que des informations auxquelles ils peuvent se fier. Cela ne peut se faire qu'en mettant en place des indicateurs « business » clairs et pertinents permettant la sauvegarde, l'utilisation de la mémoire de l'entreprise et offrant à ses décideurs la possibilité de se reporter à ces indicateurs pour une bonne prise de décision.

Le « Data Warehouse », « Entrepôt de données » en français, constitue, dans ces conditions, une structure informatique et une fondation des plus incontournables pour la mise en place d'applications décisionnelles.

2.2.1 Entrepôt de données (Data Warehouse)

2.2.1.1 Définition

Le créateur du concept, Bill Inmon, le définit comme suit : « Un Data Warehouse est une collection de données orientées sujets, intégrées, non volatiles et historiées, organisées pour le support d'un processus d'aide à la décision».

Orienté sujet : le Data Warehouse est organisé autour des sujets majeurs de l'entreprise, contrairement à l'approche transactionnelle utilisée dans les systèmes opérationnels, qui sont conçus autour d'applications et de fonctions telles que : cartes bancaires, solvabilité client..., les Data Warehouse sont organisés autour de sujets majeurs de l'entreprise tels que : clientèle, ventes, produits.... Cette organisation affecte forcément la conception et l'implémentation des données contenues dans le Data Warehouse. Le contenu en données et en relations entre elles diffère aussi. Dans un système opérationnel, les données sont essentiellement destinées à satisfaire un processus fonctionnel et obéit à des règles de gestion, alors que celles d'un Data Warehouse sont destinées à un processus analytique.

Intégrée : le Data Warehouse va intégrer des données en provenance de différentes sources. Cela nécessite la gestion de toute incohérence.

Evolutives dans le temps : Dans un système décisionnel il est important de conserver les différentes valeurs d'une donnée, cela permet les comparaisons et le suivi de l'évolution des valeurs dans le temps, alors que dans un système opérationnel la valeur d'une donnée est simplement mise à jour. Dans un Data Warehouse chaque valeur est associée à un moment « Every key structure in the data warehouse contains - implicitly or explicitly -an element of time » [Inmon, 2000] .

Non volatiles : c'est ce qui est, en quelque sorte la conséquence de l'historisation décrite précédemment. Une donnée dans un environnement opérationnel peut être mise à jour ou supprimée, de telles opérations n'existent pas dans un environnement Data Warehouse.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 18

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Organisées pour le support d'un processus d'aide à la décision : Les données du Data Warehouse sont organisées de manière à permettre l'exécution des processus d'aide à la décision (Reporting, Data Mining...).

2.2.1.2 Bref aperçu

Le concept de Data Warehouse, tel que connu aujourd'hui, est apparu pour la première fois en 1980.

L'idée consistait alors à réaliser une base de données destinée exclusivement au processus décisionnel. Les nouveaux besoins de l'entreprise, les quantités importantes de données produites par les systèmes opérationnels et l'apparition des technologies aptes à sa mise en oeuvre ont contribué à l'apparition du concept« Data Warehouse » comme support aux systèmes décisionnels.

Un entrepôt de données, ou data Warehouse, est une vision centralisée et universelle de toutes les informations de l'entreprise. C'est une structure (comme une base de données) qui a pour but, contrairement aux bases de données, de regrouper les données de l'entreprise pour des fins analytiques et pour aider à la décision stratégique. La décision stratégique étant une action entreprise par les décideurs de l'entreprise et qui vise à améliorer, quantitativement ou qualitativement, la performance de l'entreprise. En gros, c'est un gigantesque tas d'informations épurées, organisées, historisées et provenant de plusieurs sources de données, servant aux analyses et à l'aide à la décision. L'entrepôt de données est l'élément central de l'informatique décisionnelle à l'heure actuelle. En effet, l'entrepôt de données est le meilleur moyen (jusqu'à nos jours) que les professionnels ont trouvé pour modéliser de l'information pour des fins d'analyse.

Le Data Warehouse peut être subdivisé en des sous-ensembles appelés data mart. Le data mart est un sous-ensemble d'un Data Warehouse destiné à fournir des données aux utilisateurs, et souvent spécialisé vers un groupe ou un type d'affaire. Techniquement, c'est une base de données relationnelle utilisée en informatique décisionnelle et exploitée en entreprise pour restituer des informations ciblées sur un métier spécifique, constituant pour ce dernier un ensemble d'indicateurs utilisés pour le pilotage de l'activité et l'aide à la décision. Un magasin de données peut constituer un extrait de l'entrepôt, où les données sont préparées de manière spécifique pour faciliter leur analyse et leur exploitation par un groupe d'utilisateurs, en fonction par exemple d'une orientation métier.

Les possibilités d'analyse des données sélectionnées sont très variées. Elles dépendent des besoins des utilisateurs et font appel à des techniques différentes :

le reporting avec la construction de tableaux de bord, d'indicateurs, de graphiques ;

la navigation multidimensionnelle dans les données avec la technologie OLAP ; la fouille dans les données à l'aide des méthodes de Data Mining.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 19

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

2.2.2 Notions de SIO et SID

Un Système d'Information Opérationnel(SIO) a pour objectif premier de servir de support à la réalisation des activités d'un ensemble de processus métier. Par exemple, un SIO dédié au processus de vente assistera les commerciaux dans l'enregistrement des commandes des clients et des expéditions des articles commandés alors qu'un SIO de gestion des ressources humaines permettra l'enregistrement d'informations sur les salariés, les contrats de travail, les salaires et les primes, les entretiens de carrière et permettra également la génération des fiches de paie. Chaque fois qu'une activité est réalisée dans un SIO, on dit que l'on a réalisé une transaction, c'est pourquoi les SIO sont également appelés systèmes transactionnels.

Au fur et à mesure de l'émergence des SIO, dans les années 1970 et 1980, force fut de constater que ces systèmes, s'ils étaient efficients pour produire et stocker des données, se révélaient particulièrement inaptes à restituer de l'information aux décideurs des entreprises et des organisations au sens large.

Le constat de l'inaptitude des SIO à restituer les données qu'ils stockent a amené les organisations à construire des systèmes à part, dédiés à la restitution d'informations, que l'on a appelé des Systèmes D'information Décisionnels (SID)

Par opposition à un SIO dont l'objectif est l'exécution d'un processus métier, un SID a pour but l'évaluation de la performance des processus. Il a pour vocation de faciliter la prise de décision en fournissant des réponses à des questions telles que : quelle fut l'évolution du chiffre d'affaires et de la marge brute pour chaque catégorie de produits entre le premier semestre de cette année et celui de l'année précédente ? Quelle est la rentabilité moyenne des clients du secteur des grandes entreprises par rapport à celui des PME? Quelle fut l'évolution annuelle des encours de crédit octroyés à la clientèle professionnelle par les différentes agences de mon réseau bancaire ?

Un SID est donc un système d'information dédié aux décideurs d'une organisation et permettant, au moyen d'une base de données et d'une interface d'accès aux données, aux utilisateurs d'obtenir des informations utiles à la prise de décision.

2.2.3 Différence entre SID et SIO

Plus haut nous nous sommes servis des deux concepts pour dégager le sens sans ambigüité de ce que c'est un SID. Dans cette partie, nous confrontons chacun des critères cités, dans un tableau comparatif afin de mieux percevoir les différences fondamentales entre un SID et un SIO.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 20

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Le tableau illustre les principales différences entre les SIO et les SID.

CRITERES SIO SID

Objectif	Exécution de processus métier	Évaluation de la performance des processus métier
Mode d'interaction entre les utilisateurs et la base de données	Insertion, mise à jour, suppression et sélection de données	Sélection de données
Périmètre d'interaction entre les utilisateurs et la base de données	Transactions unitaires	Sélection de données en masse
Type d'utilisation	Prédéfinie, prévisible	Non prédéfinie, imprévisible
Complexité des requêtes des utilisateurs	Faible	Elevée
Optimisé pour	La performance des transactions unitaires	La performance des requêtes de sélection des données en masse
Fréquence de mise à jour de la base de données	Mises à jour en temps réel, au fur et à mesure de l'exécution des processus métier	Mises à jour périodiques en mode « batch »
Historique des données Utilisées	Données courantes	Données courantes mais aussi et surtout historiques
Degré de normalisation des Données	Hautement normalisé (3e forme normale)	Dénormalisé

Tableau 1: Etude SIO vs SID

2.2.4 Technologies d'implantation des données (systèmes OLAP)

Le terme OLAP (On-Line Analytical Processing) désigne une classe de technologies conçue pour l'accès aux données et pour une analyse instantanée de ces dernières, dans le but de répondre aux besoins de Reporting et d'analyse.

R. Kimball définit le concept « OLAP » comme «Activité globale de requêtage et de présentation de données textuelles et numériques contenues dans l'entrepôt de données; Style d'interrogation spécifiquement dimensionnel » [Kimball, 2005].

C'est en continuant sur sa lancée, qui lui a permis de définir le model OLTP pour les bases de données relationnelles, que le concept OLAP fut introduit et défini en 1993 par E.F Codd, le père des bases de données relationnelles, dans un document technique portant

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 21

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

le titre de « Providing OLAP (On-Line Analytical Processing) to User-Analysts : An IT Mandate » [Codd, 1993].

2.2.4.1 Le système à architecture ROLAP

Les systèmes de type ROLAP utilisent un SGBD relationnel pour stocker les données de l'entrepôt. Ils représentent une interface multidimensionnelle pour le SGBD relationnel. Le moteur OLAP est un élément supplémentaire qui fournit une vision multidimensionnelle de l'entrepôt, des calculs de données dérivées et des agrégations à différents niveaux. Il est aussi responsable de la génération des requêtes SQL mieux adaptées au schéma relationnel, qui profitent des vues matérialisées existantes pour exécuter efficacement ces requêtes. Les mesures (par exemple les quantités vendues) sont stockées dans une table qu'on appelle la table des faits. Pour chaque dimension du modèle multidimensionnel, il existe une table qu'on appelle la table de dimension (comme Produit, Temps, Client) avec tous les niveaux d'agrégation et les propriétés de chaque niveau.

Ces systèmes peuvent stocker de grands volumes de données, mais ils peuvent présenter un temps de réponse élevé. Les principaux avantages de ces systèmes sont : une facilité d'intégration dans les SGBD relationnels existants, une bonne efficacité pour stocker les données multidimensionnelles.

Figure 1: Architecture de base ROLAP

2.2.4.2 Le système à architecture MOLAP

Les systèmes de type MOLAP stockent les données dans un SGBD multidimensionnel sous la forme d'un tableau multidimensionnel (multi-dimensional array). Chaque dimension de ce tableau est associée à une dimension du cube. Seules les valeurs de données correspondant aux données de chaque cellule sont stockées. Ces systèmes demandent un pré-calcul de toutes les agrégations possibles. En conséquence, ils sont plus performants que les systèmes traditionnels, mais difficiles à mettre à jour et à gérer.

Les systèmes MOLAP apparaissent comme une solution acceptable pour le stockage et l'analyse d'un entrepôt lorsque la quantité estimée des données d'un entrepôt ne dépasse pas quelques giga-octets et lorsque le modèle multidimensionnel évolue peu. Mais,

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 22

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

lorsque les données sont éparses, ces systèmes sont consommateurs d'espace et des techniques de compression doivent être utilisées.

Les produits de Hyperion Essbase OLAP Server ont adopté cette technique de stockage.

Figure 2: Architecture de base MOLAP

2.2.4.3 Le système à architecture HOLAP

Les systèmes HOLAP « Hybride On-line Analytical Processing » sont une sorte de compromis entre les différents systèmes précités. Cette combinaison donne à ce type de système les avantages du ROLAP et du MOLAP en utilisant tour à tour l'un ou l'autre selon le type de données.

2.2.4.4 Architecture ROLAP vs architecture MOLAP

Avantages Inconvénients

ROLAP	Technologie familière	Lent
	Scalable
	Ouvert
MOLAP	Modèle multidimensionnel	Technologie non prouvée
	Traitement de requête spécialisé	Non scalable
	Techniques d'indexation spécialisées

Tableau 2: ROLAP vs MOLAP

2.2.5 Schémas de modélisation ROLAP

Deux schémas principaux sont utilisés pour modéliser les systèmes ROLAP : le schéma en étoile, le schéma en flocon de neige.

2.2.5.1 Le schéma en étoile

Dans ce type de schéma, les mesures sont représentées par une table de faits et chaque dimension par une table de dimensions. La table des faits référence les tables de dimensions en utilisant une clé 'étrangère pour chacune d'elles et stocke les valeurs des

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 23

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

mesures pour chaque combinaison de clés. Autour de cette table des faits figurent les tables de dimensions qui regroupent les caractéristiques des dimensions. La table des faits est normalisée et peut atteindre une taille importante par rapport au nombre de n-uplets. Les tables de dimension sont généralement dénormalisées afin de minimiser le nombre de jointures nécessaires pour évaluer une requête. Ce schéma est largement utilisé dans les applications industrielles (les groupes Redbrik, ou encore Informix).

Cependant, un schéma en étoile est souvent un concept centré-requête, par opposition au schéma centré-mise-à-jour employé par les applications de type OLTP. Les requêtes typiques de ce schéma sont appelées les requêtes de jointure en étoile (star-join queries) qui ont les caractéristiques suivantes :

? Il y a des jointures multiples entre la table des faits et les tables de dimension. ? Il n'y a pas de jointure entre les tables de dimensions.

? Chaque table de dimension impliquée dans une opération de jointure a plusieurs prédicats de sélection sur ses attributs descriptifs.

La syntaxe générale de ces requêtes est la suivante :

SELECT <Liste de projection> <Liste d'agrégation>

FROM <Nom de la table des faits> <Liste de noms de tables de dimension>

Figure 3: Schéma en étoile

WHERE <Liste de prédicats de sélection & jointure> GROUP BY <Liste des attributs de tables de dimension>

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 24

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

2.2.5.2 Le schéma en flocon de neige

Le schéma en étoile ne reflète pas les hiérarchies associées à une dimension. Il exige que les informations complètes associées à une hiérarchie de dimension soient représentées dans une seule table, même lorsque les différents niveaux de la hiérarchie ont des propriétés différentes. Pour résoudre ce problème, le schéma en flocon de neige a été proposé.

Ce dernier est une extension du schéma en étoile. Il consiste à garder la même table des faits et à éclater les tables de dimensions afin de permettre une représentation plus explicite de la hiérarchie. Cet éclatement peut être vu comme une normalisation des tables de dimensions.

Contrairement au schéma en étoile, le schéma en flocon de neige capture les hiérarchies entre les attributs.

Ce schéma a été fortement déconseillé par Kimball qui disait : «ne structurez pas vos dimensions en flocons de neige même si elles sont trop grandes», mais en même temps, conseillé par des chercheurs (comme Jagadish et al.) et des industriels de AT & T Labs-Research.

Figure 4: Schéma en Flocon

2.2.5.3 Choix d'un schéma

Nous n'allons pas "floconiser" à tort et à travers. En effet, pour garder une structure simple, gérable et compréhensible, nous allons utiliser le plus possible la modélisation en étoile. La modélisation en flocon n'intervenant que lorsque des problèmes de performances apparaissent ou sont facilement prédictibles.

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Une règle informelle en BI préconise de floconner que si l'on a la relation (1-1000). C'est-à-dire que si l'on réussit à créer une hiérarchie de deux dimensions avec une ligne de la dimension père (catégorie produit par exemple) faisant référence à plus de 1000 lignes de la dimension fille (produit par exemple). Dans ce cas, il est peut-être temps de recourir aux flocons.

Remarque : cette règle fût émise en prenant en considération les technologies logicielles et matérielles actuelles. Il ne serait pas étonnant, à mon sens, de voir disparaître la modélisation en flocon avec les avancées technologiques (rapidité des disques durs, technologies OLAP, etc.).

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 25

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 26

Conclusion

Dans cette partie, il était question de présenter la structure d'accueil, le sujet et tous les éléments y rattachés mais aussi et surtout de parler des concepts liés aux domaines concernant notre sujet. Cette présentation nous a donc permis de poser les jalons d'un bon démarrage pour une étude et une conception lisible.

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

PARTIE 2 : ANALYSE ET CONCEPTION

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 27

Dans la deuxième partie de notre travail, nous présentons en chapitre premier les outils d'analyse et de conception, puis en deuxième chapitre, l'analyse et la conception de notre solution. Dans chacun des deux chapitres, nous exposons les outils, les analyses et conceptions du système d'information transactionnel d'une part, et ceux du système d'information décisionnel, d'autre part.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 28

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

CHAPITRE 1 : OUTILS D'ANALYSE ET DE CONCEPTION

1.1 Modélisation des données source

Le développement logiciel, pour répondre à de besoin de qualité, a besoin de se baser sur un ensemble de méthodes ou de principes qui guideront sa mise en oeuvre. Pour cette même raison, dans le cadre de la mise en oeuvre de notre projet, nous allons étudier quelques langages de conception et processus de développement logiciels pour en élire ceux jugés capables de répondre à nos attentes.

1.1.1 Méthodes d'analyse et de conception Une méthode d'informatisation est composée :

? de modèles : ce sont des spécimens de résultats intermédiaires pouvant être produit par une étape du processus;

? de langages : pour élaborer les spécifications, et faciliter leur communication;

? d'une démarche : processus pour effectuer les travaux préconisés, étape par étape.

Malgré la diversité des méthodes d'analyse et de conception, il est possible de les classer en quatre catégories : les méthodes cartésiennes ou fonctionnelles, les méthodes systémiques, les méthodes agiles, les méthodes objet.

1.1.2 Choix d'une méthode

Pour la mise en oeuvre de notre application opérationnelle, nous avons choisi le langage de modélisation UML (Unified Modeling Language) couplé au processus de développement logiciel à deux branches 2TUP. Ce dernier, comme tous les processus unifiés est construit sur UML.

1.2 Modélisation de l'entrepôt de données

1.2.1 Approches de conception

Nous avons présenté les approches de conception multidimensionnelle, mais comment regrouper des tables de fait pour mettre en oeuvre un entrepôt de données ? Trois méthodes s'offrent à nous :

1.2.1.1 L'approche Top-Down de Bill Inmon

Bill Inmon, l'un des premiers auteurs sur l'entreposage de données, a défini un entrepôt de données comme étant un référentiel centralisé pour toute l'entreprise. Il est l'un des principaux partisans de l'approche top-down. Dans cette approche, l'entrepôt de données est conçu pour un modèle d'entreprise normalisé.

Les données au niveau "atomiques", c'est-à-dire des données ayant un niveau de détail très élevé, sont stockées dans l'entrepôt de données. Les données dimensionnelles contenant les données nécessaires pour les processus métier spécifiques ou départements spécifiques sont créés à partir de l'entrepôt de données.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 29

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

La théorie et l'approche de Bill Inmon soutient le fait qu'un entrepôt de données est: Orientée vers le sujet :

Les données dans l'entrepôt de données sont organisées de telle sorte que tous les éléments de données relatifs au même monde, événement ou objet sont reliés entre eux. Non-volatile : Les données de l'entrepôt de données ne sont jamais écrasées ou supprimées - une fois engagées, les données sont statiques, lisibles uniquement, et conservé pour les futurs rapports.

Intégré : L'entrepôt de données contient des données en provenance de la plupart ou la totalité des systèmes opérationnels d'une organisation et ces données sont rendues compatibles.

Variant dans le temps : La méthodologie de conception top-down génère une vue dimensionnelles des données très cohérente à travers des data marts puisque tous les data marts sont chargés à partir du référentiel centralisé. La conception descendante s'est également avérée être résistante en ce qui concerne les changements à faire dans le temps. La création de nouveaux dépôts de données dimensionnelles par rapport aux données stockées dans l'entrepôt de données est une tâche relativement simple. Le principal inconvénient de la méthode top-down, c'est qu'elle se traduit la plupart du temps en un très gros projet avec un champ d'application très large. De plus, le coût et le temps nécessaire à la mise en oeuvre d'un entrepôt de données en utilisant la méthode top-down sont assez conséquents. En outre, la méthodologie top-down peut être inflexible et insensible à l'évolution des besoins des clients au cours des phases de mise en oeuvre.

C'est la méthode la plus lourde, la plus contraignante et la plus complète en même temps.

Imaginez le travail qu'une telle méthode implique : savoir à l'avance toutes les dimensions et tous les faits de l'entreprise, puis réaliser l'ensemble de l'entrepôt. Le seul avantage que cette méthode comporte est qu'elle offre une vision très claire et très conceptuelle des données de l'entreprise ainsi que du travail à faire.

Figure 5: Vision architecturale de l'approche de Bill Inmon

(Source : http://www.computerweekly.com/tip/Inmon-vs-Kimball-Which-approach-is-suitable-for-your-data-warehouse)

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 30

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

1.2.1.2 L'approche Bottom-Up de Ralph Kimball

C'est l'approche inverse, elle consiste à créer les étoiles une par une, puis les regrouper par des niveaux intermédiaires jusqu'à obtention d'un véritable entrepôt pyramidal avec une vision d'entreprise.

La conception décisionnelle ascendante de Ralph Kimball, auteur et expert reconnu dans le domaine de la BI, est une approche de la conception décisionnelle d'entrepôt de données du bas vers le haut. Cette méthode est aussi appelée "Bottom-Up". Dans l'approche ascendante, les magasins de données ou data marts sont donc créés pour fournir des rapports et une capacité d'analyse dédiés à certains processus métiers spécifiques, donc plus faciles à utiliser que des entrepôts de données complexes.

Dans la méthodologie de Ralph Kimball, le processus bottom-up est le résultat d'une première entreprise axée sur une analyse des processus d'affaires pertinents à modéliser.

Des magasins de données spécialisés :

Les magasins de données contiennent les dimensions, axes d'analyses, et les faits ou mesures. Les faits peuvent contenir soit des données atomiques c'est à dire à un niveau fin, soit des données agrégées. Ils modélisent souvent un domaine d'activité très spécifique comme les ventes ou la production. Ces magasins de données peuvent être intégrés à une solution décisionnelle afin de créer un entrepôt de données complet.

Cette intégration entre différents magasins de données est mise en oeuvre par ce que Kimball appelle une architecture d'entrepôt de données en bus. Elle est permise par une collection de dimensions conformes, qui sont des dimensions partagées (de manière spécifique) entre deux dépôts de données ou plus, permettant des analyses croisées sur plusieurs domaines métiers ou processus.

Le Drill Across de Raplh Kimball :

L'intégration des données transverses dans l'entrepôt de données est basée sur les dimensions conformes qui représentent des points d'entrée entre les data marts. L'intégration effective de deux ou plusieurs data marts se fait alors par un processus appelé "Drill Across", c'est un forage latéral qui regroupe des données métiers différentes mais à un même niveau de granularité et utilisant les mêmes dimensions. Les dimensions souvent utilisées car transverses à l'entreprise. Par exemple l'axe Temps, Clients ou Produits.

Maintenir une gestion précise de l'architecture de l'entrepôt de données est essentiel pour l'intégrité des données. La tâche de gestion la plus importante est de faire en sorte que les dimensions entre les data marts soient compatibles et donc mises à jour en parallèle.

Une vision en silo connectés favorable aux itérations :

Les données de l'entreprise peuvent être analysées dès la fin de la création des premiers magasins de données, la méthode permet une approche exploratoire et itérative pour la

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

construction de l'entrepôt. Par exemple, l'effort de chargement des données est développé pour les ventes, avec un entrepôt de données spécifique. La suite du projet décisionnel peut continuer pour la Production, une analyse conjointe peut mettre en exergue la corrélation entre la capacité de production et les ventes quotidiennes.

L'avantage de cette méthode est qu'elle est simple à réaliser (une étoile à la fois), l'inconvénient est le volume de travail d'intégration pour obtenir un entrepôt de données ainsi que la possibilité de redondances entre les étoiles (car elles sont faites indépendamment les unes des autres). Cette vision de Ralph Kimball du monde décisionnel est favorable aux itérations et permet de produire des projets décisionnels domaine par domaine.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 31

DT: Dimension Table, FT : Fact Table.

Figure 6: Vision architecturale de l'approche de Ralph Kimball

(Source : http://www.computerweekly.com/tip/Inmon-vs-Kimball-Which-approach-is-suitable-for-your-data-warehouse)

1.2.1.3 L'approche Middle-Out

C'est l'approche hybride, et conseillée par les professionnels du BI. Elle consiste en la conception totale de l'entrepôt de données (ie : concevoir toutes les dimensions, tous les faits, toutes les relations), puis créer des divisions plus petites et plus gérables et les mettre en oeuvre. Cela équivaut à découper notre conception par éléments en commun et réaliser les découpages un par un. Cette méthode tire le meilleur des deux précédentes sans avoir les contraintes. Il faut juste noter que cette méthode implique, quelques fois, des compromis de découpage (dupliquer des dimensions identiques pour des besoins pratiques par exemple).

1.2.2 Etat de lieu des techniques de conception dimensionnelle

Ralph KIMBALL et Bill Inmon, les principaux précurseurs de l'entreposage de données, ont introduit des notions « génériques » des techniques de conception multidimensionnelles sans fournir une démarche formelle pour aborder cette question pourtant délicate.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 32

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Dans [Kimball et Ross, 2002] différentes études de cas de schémas multidimensionnels sont proposées. Une méthode, appelée architecture en matrice de BUS, est proposée pour la construction d'un schéma multidimensionnel à partir de la définition des besoins des utilisateurs. Ces travaux ne proposent pas de méthode formelle de conception et de construction d'une base dimensionnelle.

La création du modèle dimensionnel se fait en 4 étapes, selon le cycle de vie décisionnel de Kimball que voici:

? Identifier le processus d'affaires,

? Identifier la granularité de la table de faits, ? Identifier les dimensions,

? Identifier les faits.

Ce qui est toutefois utile même si l'on constate qu'il ne fournit en effet aucun repère pour le choix des dimensions, des faits, des mesures ; en supposant que le choix du processus d'affaire et celui de quelques fais et mesures découlent des besoins exprimés par les utilisateurs.

Ces limites nous amènent à introduire de nouvelles approches qui guideront notre conception dimensionnelle en nous basant sur la description des processus métiers faisant partie de notre domaine analytique.

Il est vrai que la conception d'un entrepôt de données est motivé par l'expression de besoins exprimés par une entreprise ou, dans le cas de la démarche de Kimball, de l'expression de besoins d'une partie de l'entreprise (département ou processus métiers donc data mart). Etant donné que l'analyse et la conception informatiques ne sont pas des acquis du client qui pose le besoin d'une plateforme décisionnelle, nous croyons que le concepteur doit pouvoir mettre en avant l'idée qu'à côté des besoins exprimés l'on peut déduire plusieurs éléments utiles qui puissent se greffer aux besoins exprimés. Ces éléments qui, au préalable peuvent ne pas paraitre dans les expressions des besoins. C'est d'ailleurs à travers notre démarche que nous allons démontrer que la conception informatique doit non seulement suivre le besoin des utilisateurs mais quelques fois servir de canal pour en tirer une valeur ajoutée.

Dans le deuxième chapitre de cette partie, nous allons présenter les différentes étapes de la méthodologie par l'analyse des processus métiers puis au troisième chapitre, nous allons mettre en oeuvre notre technique d'identification et de choix des dimensions, faits et mesures, spécifiquement dans le sous-titre « Conception du modèle dimensionnel ».

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 33

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

CHAPITRE 2 : CONCEPTION BASEE SUR L'ANALYSE DES PROCESSUS METIERS

Un processus métier est un enchaînement d'actions réalisées par différents acteurs collaborant pour délivrer un résultat tangible et une valeur ajoutée métier pour l'entreprise. Dans le contexte précis, la représentation des processus métiers est basée sur la modélisation par le diagramme de processus métiers UML avec des conditions référençant le code CIMA, notre référentiel juridique pour la mise en oeuvre de l'environnement décisionnel et de production pour les compagnies d'assurance.

Le besoin de faire une conception basée sur une méthodologie qui consiste à analyser les processus métiers d'un domaine pour la mise en oeuvre d'un SID renferme d'énormes avantages parmi lesquels :

- La prise en compte non seulement des besoins des clients, mais aussi, à travers

eux, une vision concise de l'exécution des processus métiers dans leur structure ; - L'observation, après description des processus, de façon claire de l'ensemble des

acteurs participant à l'exécution du processus ;

- Etant donné la transversalité des processus métiers par rapport à l'entreprise, cette méthode permet en outre d'observer les services et/ou départements au sein desquels au moins une tâche du processus métier est exécutée ;

- La présence des branchements décisionnels permet de choisir des axes d'analyse du SID suivant leurs pertinences...

La méthodologie par l'analyse des processus métiers consiste donc à identifier les acteurs du domaine en premier lieu, identifier les processus métiers, identifier les interactions entre les deux précédents points, décrire le processus métier, annoter les processus métier et en fin, analyser le processus métier ainsi annoté pour en déduire les dimensions et mesures.

2.1 Identification des processus métier d'une compagnie d'assurance

L'ensemble des activités d'une compagnie d'assurance se résume en quelques points génériques. Autour de ces processus (ensemble d'activités en interaction pour l'atteinte d'un objectif), se déduisent beaucoup d'autres activités pas nécessairement au coeur du quotidien des compagnies d'assurance. Ici nous répertorions les processus de:

? Gestion des demandes de devis

? Gestion des polices d'assurance

? Gestion du recouvrement des primes

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 34

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

? Gestion des indemnités

2.2 Identification des acteurs d'une compagnie d'assurance

? Le « guichetier » : Il se trouve en première ligne et c'est lui qui vous accueille quand vous vous rendez dans une agence d'assurance. Ce guichetier n'est autre qu'un

conseiller clientèle qui sera votre interlocuteur privilégié. Sans être forcément au guichet mais dans un bureau, l'employé d'assurance pourra vous faire signer un contrat pour assurer ce dont vous avez besoin.

? L'actuaire : C'est un poste clé d'une agence d'assurance. L'actuaire est une sorte de statisticien qui étudie toutes les données en sa possession pour fixer le montant des primes d'assurance. Il a donc en charge la tarification générale d'une compagnie d'assurance. L'actuaire n'est pas vraiment la personne que vous pouvez rencontrer dans une agence d'assurance. Si vous souscrivez un contrat d'assurance assez spécifique, l'actuaire se penchera sur votre dossier pour fixer une prime d'assurance qu'il transmettra à un employé administratif. Ce dernier pourra alors élaborer un contrat pour une future signature.

? L'employée administratif : Il a le même statut que le guichetier sauf que ses

compétences ne sont pas les mêmes. Ce dernier, n'a pas besoin d'avoir des talents de négociateur ou de commercial puisqu'il s'occupe de la partie administrative. En tant qu'assuré vous ne rencontrez jamais ce type d'employé dont la mission principale est de rédiger des contrats d'assurances ou de mettre en forme la procédure pour régler

les sinistres.

? Le responsable d'action commerciale : Etre commercial dans une entreprise privée ou dans une agence d'assurance ne diffère pas vraiment. Dans les deux cas, il faut avant tout démarcher des éventuels clients et essayer de vendre le plus possible. A l'époque du lancement de l'assurance vie, les commerciaux faisaient du porte à porte pour essayer de faire signer des contrats d'assurances vies. Les temps changent et aujourd'hui, le responsable de l'action commerciale travaille plus en envoyant des courriels et c'est lui qui est responsable de la vente à distance.

? Les chefs de projets : Ce sont les spécialistes de la réduction des coûts de production. Quand il faut se serrer la ceinture vous pouvez compter sur un chef de projet pour trouver le moyen d'y arriver. Ils aiment aussi proposer des solutions efficaces pour

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 35

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

développer le portefeuille d'action d'un assureur. Un bon chef de projet doit toujours avoir des nouvelles idées et adapter les progrès technologiques pour rendre le fonctionnement d'une société d'assurance plus performante aussi bien en termes de service qu'en termes de profit.

? Les experts : L'expert a pour mission quand un sinistre survient d'en estimer les dommages et les responsabilités. L'expert doit donc chiffrer la valeur d'un sinistre et déterminer les montants d'indemnisation à verser. Les grandes compagnies d'assurances ont leurs propres experts. Dans certains cas, ils peuvent régler financièrement le sinistre en faisant un chèque sur place. Le jour où un assuré a un sinistre, il fera sans doute la rencontre d'un expert salarié ou mandaté par la compagnie d'assurance. C'est d'ailleurs une question à poser lors de la visite d'un expert : Etes-vous salarié ou mandaté par la compagnie d'assurance ?

? Le courtier : Ce n'est pas vraiment un acteur d'une compagnie d'assurance puisque le courtier en assurance est un travailleur libre avec le statut de commerçant et qui a ses propres locaux. Il représente le client vis à vis des compagnies avec lesquelles il travaille. Il est chargé par des assurés de leur trouver les contrats les mieux adaptés et aux meilleurs prix auprès des compagnies d'assurance. En tant qu'assuré, vous pouvez sélectionner votre assureur en passant par un courtier. Ce sont des commerçants inscrits au registre du commerce. Selon la loi, ils sont obligés de souscrire une garantie financière pour couvrir les fonds qui leur sont confiés. Bien entendu, ils doivent aussi être obligatoirement assurés en responsabilité civile professionnelle. A noter que ce sont souvent les coutiers qui gèrent le bon fonctionnement des sites comparatifs d'assurances sur internet. Ce système apporte une approche nouvelle dans la commercialisation de contrat d'assurance. L'internaute peut mettre en concurrence en quelques clics diverses compagnies d'assurance sur la mutuelle santé, l'assurance automobile, l'assurance habitation, l'assurance emprunteur, etc. Ces sites internet d'assurance disposent également d'offres et de propositions négociées auprès des compagnies d'assurances par nos fameux courtiers.

? Les trésoriers, comptables, et autres gestionnaires : Il est ici question de ceux qui ont en charge la fonction financière d'une compagnie d'assurance. Plus la compagnie d'assurance est grosse et plus elle a besoin de ces contrôleurs financiers pour fonctionner. Une grosse compagnie d'assurance dispose d'un capital souvent

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 36

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

conséquent et pour gérer au mieux ce capital, il faut des employés financiers. Le but étant d'optimiser la gestion de capital pour en tirer le plus de profit possible.

? L'Agent Général d'Assurance : C'est en quelque sorte le patron d'une compagnie d'assurance. Plus exactement, c'est le représentant ou le mandataire d'une compagnie d'assurance. C'est lui qui place ses contrats auprès de la clientèle. À ce titre, il engage la responsabilité de la compagnie d'assurance. Il doit donc garantir les engagements pris dans tous les contrats que la compagnie d'assurance, dont il est mandataire, a signé. L'agent général analyse les risques de ses clients, puis conseille ces derniers sur les opportunités d'assurance. Il place les risques auprès de sa ou ses compagnies d'assurance mandantes, suit la gestion des contrats au jour le jour, et assiste ses clients en cas de sinistre de la déclaration jusqu'à l'indemnisation.

Ils sont aussi appelés «assureurs conseils» et dans ce cas, ils sont mandatés par leurs clients pour les représenter face aux compagnies. C'est pourquoi ils sont aussi

responsables de leurs résultats auprès de leurs clients.
Les agents généraux d'assurance ont un statut particulier d'intermédiaire avec leur compagnie mandante, ils sont libéraux et chefs d'entreprises, statut qui régit leurs relations avec les sociétés d'assurance. Sachez aussi que l'agent général joue bien souvent le rôle de courtier.

(Source : http://www.assurances.info/metier-assureur/les-acteurs-compagnie-assurance/)

2.3 Identification des interactions entre acteurs et processus

Dans cette partie, il s'agit principalement de connaitre à quel moment tel ou tel autre acteur intervient dans une phase de l'exécution du processus en réalisant une tâche spécifique. Cette information sera utile pour la description du processus métier car, il va être décomposé en tâche, et chacune des tâches ayant un acteur bien indiqué pour son exécution.

Il s'agit notamment de décomposer le processus métier en tâches, et de pouvoir identifier pour chacune des tâches, l'acteur. C'est la première étape nécessaire à la description des processus métiers. Cette étape consiste en réalité à faire un « travail brouillon » visant à préparer les éléments nécessaires pour la description des processus métiers à l'aide.

2.4 Description des processus métiers

La phase de description des processus métiers prend donc en compte l'ensemble des données précédemment énumérées. Elle met en valeur les acteurs, les processus métiers et les interactions entre les deux éléments. Elle formalise en quelque sorte l'exécution des tâches en indiquant le responsable.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 37

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Cette description peut être réalisée sous plusieurs outils de modélisation de processus métiers tels que : BPM (Business Process Management), ABA (Aris Business Architect), CM (Corporate Modeler), MP(Mega Process), PE (Provision Enterprise), Win Design Business Process ou Power AMC...

2.4.1 Processus métier « Gestion des demandes de devis »

Le processus métier « Gestion des demandes de devis » intervient lorsqu'une tierce personne se rapproche d'une compagnie d'assurance pour obtenir un inventaire de la couverture d'un risque qu'il souhaite soumettre à l'assureur.

^{Modèle orienté objet}

^Modèle : ^Demande de devis ^Diagramme : ^DiagrammeActivites_1 ^Version: 0.1
^Demandeur ^Emission demande	^Package : ^Auteur : ^DJYAMO Azore Date: 04/01/2017 ^Guichetier Recevable	^Actuaire

^{Analyse de la demande}

^{[KO] [OK]}

^{Etablissement du devis}

^{Traitement des primes et garanties}

Figure 7: Processus métier « Gestion des demande de devis »

^{Reception du devis}

2.4.2 Processus métier « Gestion de police d'assurance »

Ici, le processus peut être enclenché par un autre processus « Demander un devis » ou démarrer spontanément dans le cas où il est à l'initiative de l'assureur (ici le guichetier). La demande de devis peut se conclure par une demande de couverture de risque (police d'assurance). La dernière possibilité existe dans le cas d'un processus de markéting en aval par exemple, donc à l'initiative de l'agent d'assurance.

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Art. 6, Art. 216 réf ANNEXE

Figure 8: Processus métier « Gestion des polices d'assurance »

2.4.3 Processus métier « Gestion des indemnisations »

Ce processus est enclenché par un événement unique : la survenance d'un sinistre. La première activité est en règle générale, la déclaration du sinistre mais dans les délais mentionnés dans la police d'assurance. Au cas contraire, l'assureur dispose du droit de décliner sa responsabilité dans l'indemnisation de ce sinistre.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 38

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 39

Art. 247, Art. 231, Art. 233, Art. 253, Art. 258, Art. 260, Art. 252 bis, Art. 239, Art. 216 réf ANNEXE

Figure 9: Processus métier « Gestion des indemnités »

2.4.4 Processus métier « Recouvrement des primes »

L'entrée en vigueur d'une police d'assurance est conditionnée par le versement de la première prime d'assurance (réf art 13, alinéa 2 du code CIMA). Ensuite, les conditions de paiement des primes suivantes est inscrit dans la police (réf art 8, alinéa 6 du code CIMA)

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 40

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

^{Modèle orienté objet}

^Modèle : ^PM_Primes

^Package :

^Diagramme : ^{DiagrammeActivites_1 Auteur} : ^{DJYAM'S Date: 31/12/2016}

^Version:

^Client

^Comptable

Art. 13-1, Art. 216 réf ANNEXE

^{Reception de l'attestation}

^{Reception de la lettre}

^{[Art. 13-1]}

^{[OK [Art. 216]]}

^{[Art. 216]}

^{[OK [Art. 216]]}

^{[Ok [Rupture de plein droit]]}

^{Emission d'une lettre}

^{[Assurance de dommage]}

^{Rupture de contrat?}

^{Reception de la prime}

^[KO]

^{[Reprise du contrat]}

^{Paiement réçu?}

^{Primes récus?}

^[KO]

^[KO]

Figure 10: Processus métier « Recouvrement des primes »

2.5 Annotation des processus métiers

Les branches décisionnelles après certaines tâches peuvent être des indicateurs pour une prise de décision au niveau de notre système d'information décisionnel. L'annotation permet donc de choisir quelles branches vous voulez observer plus tard dans votre environnement décisionnel pour vous aider à prendre de décisions. Nous reprenons la description des processus métiers faites ci-haut pour en rajouter des métriques significatifs.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 41

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

^Modèle : ^{Demande de dess}

2.5.1 Processus métier « Gestion des demandes de devis »

^{Vesion: 0.1}

^Demandeur	^Guichetier	^Actuaire
^Emission demande	^Analyse de la demande
		^demandes
	régnes satisfaites
	^[KO] [OK]
	Recevable	^Traitement des primes et garanties
^Nbre de demandes
^non satisfaites
	^Etablissement du devis
^Reception du devis	^Montant
	^Nbre de devis

^{Nbre de} demandes ^{Nbre de}

^{de la prime}

Figure 11: Processus métier « Gestion des demandes de devis » annoté 2.5.2 Processus métier « Gestion de police d'assurance »

Figure 12: Processus métier « Gestion de police d'assurance» annoté

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

2.5.3 Processus métier « Gestion des indemnisations »

Montant des indemnisations

Figure 13: Processus métier « Gestion des indemnisations » annoté

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 42

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 43

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

2.5.4 Processus métier « Recouvrement des primes »

^Version:

^Client

^Comptable

^Modèe : ^{PM_Primes k}

^{Nbre d'échéance de paiement}

^{[Assurance de dommage]}

^{Montant de primes payées à}

^l'échéance

^{Reception de l'attestation}

^{[OK [Art. 216]]}

^{Primes récus?}

^{Montant de primes impayées à}

^[KO]

^l'échéance

^{Emission d'une lettre}

^{Reception de la lettre}

^{[Art. 13-1]}

^{Montant de primes payées après reception de}

^lettre

^{[OK [Art. 216]]}

^{Paiement réçu?}

^[KO]

^Monta

^{nt de primes impayés après reception de}

^lettre

^{Rupture de contrat?}

^[KO]

^{[Ok [Rupture de plein droit]]}

^{Nbre de contrat rompus pour primes impayées}

^{[Art. 216]}

^{Reception de la prime}

^{[Reprise du contrat]}

Figure 14: Processus métier « Recouvrement des primes » annoté

2.6 Analyse des processus métiers

L'analyse des processus métiers ainsi obtenus permet de déterminer de façon quasi-systématique les dimensions des contextes (regroupement cohérent de faits et de dimensions) de notre entrepôt de données, ainsi que les mesures. La détermination du grain de l'activité est aussi l'un des éléments qui apparait sur le processus métier décrit et annoté. Lorsque vous choisissez une mesure, elle correspond évidemment à une unité de chacune de l'ensemble des axes d'analyse. Cette méthodologie de conception par

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 44

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

l'analyse des processus métiers, si elle est basée sur des interviews claires et concises avec le client, garantit une conception en totale adéquation avec les attentes des clients et répondant exactement à leurs problématiques.

Ralph Kimball définit les étapes suivantes pour le processus de conception dimensionnelle :

? Choisir le processus d'affaires:

- Se base sur la matrice en bus de données et le diagramme de priorisation; - Doit impliquer les cadres supérieurs.

? Définir le grain:

- Question: "à quoi correspond une ligne de la table de faits ?"; - Dépend des réalités physiques des sources de données.

? Identifier les dimensions:

- Découle directement de la définition du grain; - Colonnes servant à restreindre l'analyse.

? Identifier les faits:

- Colonnes représentant des valeurs numériques de mesure.

Pour nous, l'ensemble de ces étapes ne doivent intervenir qu'après avoir réuni toutes les données nécessaires à la description des processus métiers. Dans le but d'exploiter cette description au cours de l'analyse et de la conception, nous allons conserver la plupart des aspects de cette organisation du travail qui, à vrai dire, est méthodique même si nous trouvons qu'elle ne se contente que d'organiser le travail et non de fournir les éléments nécessaires à l'accomplissement de ce dernier. Puis, sur la base de nos processus métiers décrits, choisir tous les éléments évoqués par Ralph Kimball. Dans le troisième chapitre de cette partie, nous allons mettre en oeuvre la méthodologie que nous proposons pour concevoir le modèle dimensionnel de notre SID pour les compagnies d'assurance.

Cette démarche s'inspirera des règles que nous énonçons ci-après, lesquelles règles prennent appui sur la description des processus métiers effectuée ci-haut.

R00 : Décrire les processus métiers avant la modélisation dimensionnelle ;

R01 : Tout acteur présent dans la description du processus métier est une dimension potentielle ;

R02 : Les acteurs ayant dans leur colonne une branche décisionnelle ou un traitement générant une mesure sont les « candidats dimension » les plus pertinents;

R03 : Le choix des dimensions reste tributaire « des réalités » des sources de données ;

R04 : Les mesures présentes sur les processus métiers annotés peuvent faire l'objet d'une décomposition de l'activité et donner lieu à plusieurs contextes. Chaque décision est susceptible de générer plusieurs mesures ;

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 45

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

R05 : Le choix définitif des mesures et des dimensions est dicté en dernier ressort par les éléments issus de l'analyse des besoins du décideur (client).

Quelles mesures de performance, d'éclairage ou de risque serait-il pertinent de rattacher à ce processus clé ? Cette réponse doit être fournie à la fois par des représentants opérationnels expérimentés et des collaborateurs stratégiques (manager, stratège). Ici votre mantra doit être: « Not everything that can be counted counts, and not everything that counts can be counted. » [Albert Einstein]. Ce qui compte ne peut pas toujours être compté, et ce qui peut être compté ne compte pas forcément. En gardant cette phrase à l'esprit vous avez plus chance d'assurer la pérennité de votre système.

Ce qui compte ne peut pas toujours être compté : en effet, votre système décisionnel se limitera toujours à des faits tangibles. Vos collaborateurs les plus imaginatifs vous proposeront sans doute des techniques pour mesurer certain faits intangibles (exemple : la satisfaction client), si c'est le cas attention... Même s'il est possible de sonder ses clients via un questionnaire et calculer un ratio de satisfaction, ces données de type « exceptionnelles » n'ont rien à faire dans votre système décisionnel. Celui-ci doit d'abord reposer sur des faits tangibles issus d'activités tracées par votre système d'information (c'est-à-dire : pas de données disponibles de façon récurrente = pas de mesure). Dans ce cas précis, on préférera représenter la satisfaction client à travers un objectif qui encapsule des mesures tangibles en rapport avec votre activité, exemple : le nombre de réclamations traités, le nombre de retours de marchandises ou le nombre de connexions hebdomadaires, etc.

Ce qui peut être compté ne compte pas forcément : mesurez des faits qui ont un enjeu et un sens pour les décideurs ainsi que pour les opérationnels. Mesurez d'abord des indicateurs actés et connus. Rappelez-vous que rien n'est gratuit ! Le coût de votre système décisionnel sera proportionnel au nombre de mesures stockées. Plus il y a de mesures, plus il y a de volume de données, plus il y a de source de données différentes, plus il y a de maintenance lors de l'évolution des systèmes opérationnels, plus vous aurez besoin de personnel qualifié affecté à ces travaux de maintenances, etc. Avant d'intégrer une mesure, vous devez intégrer la notion « pertinence / coût ». Chaque mesure doit représenter un coût raisonnable proportionnel à la valeur ajoutée qu'elle apporte. Seuls les responsables techniques pourront réellement vous indiquer le coût de l'intégration : volume de données, coût de stockage, coût CPU, coût de maintenance, impact sur le système actuel, etc. Rappelez-vous que vous ne mesurez pas par plaisir mais par nécessité. Les personnes issues des activités opérationnelles avec une forte expérience du métier sont souvent pragmatiques et de très bon conseil.

Source :( https://businessintelligence.developpez.com/tutoriels/DWHmultidimensionnel/?page=theoriE)

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 46

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

CHAPITRE 3 : ANALYSE ET CONCEPTION

L'étude des méthodes de conception et d'autres outils nécessaires à la conception de notre solution étant effective, nous allons nous plonger dans le coeur de notre projet : l'analyse et la conception de notre solution. Il est important de noter ici qu'il va de soi que nous allons parallèlement mettre en oeuvre les modèles de la solution pour la relation client et les modèles du système décisionnel. Bien entendu, le dernier, axe principal de notre mission sera basé sur notre approche de conception par l'analyse des processus métiers.

3.1 Expression préliminaire des besoins fonctionnels

3.1.1 Besoins fonctionnels

Il s'agit des fonctionnalités que doit fournir le futur système. Ce sont les besoins spécifiant un comportement d'entrée/sortie du Système.

La solution (SID et SIO) que nous allons mettre en place doit contenir les fonctionnalités permettant de :

o créer, modifier, supprimer les clients d'une compagnie d'assurance ;

o délivrer, modifier, supprimer les garanties ;

o enregistrer, modifier, supprimer les primes ;

o consulter les demandes de couverture assurance ;

o enregistrer, modifier, supprimer les indemnités ;

o enregistrer, déclarer, modifier, supprimer les sinistres ;

o établir, modifier, supprimer les polices d'assurance ;

o créer les requêtes personnalisées ;

o extraire, transformer et charger les données source ;

o étudier en temps réel l'évolution de la relation client via des tableaux de bord ;

o éditer des statistiques personnalisées ;

o fournir des historiques des activités des clients et des finances relatives à la production ;

o avoir une vision centralisée et universelle de toutes les informations de l'entreprise.

3.1.2 Identification des acteurs

Un acteur est une entité externe qui interagit avec le système (opérateur, centre distant,

autre système...). En réponse à l'action d'un acteur, le système fournit un service qui

correspond à son besoin.

Nous avons donc identifié les acteurs suivants :

? Le client/demandeur : interagit avec le SID

? L'expert: chargé de produire les rapports de sinistre après constats ;

? L'administrateur : qui sera chargé de faire l'extraction des données, et de

gérer les profils des utilisateurs, d'aider à produire les requêtes personnalisées ;

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

? Le guichetier : représente tout agent de la compagnie qui participe à la gestion de la relation client ;

? Le manager : chargé de l'observation des tableaux de bords de l'ensemble du système décisionnel. Il produit également les requêtes personnalisées ;

? La source de données (PostgreSQL, MySQL, Oracle...) : qui sera chargée de transmettre les données statistiques nécessaires à l'établissement des états et des analyses ;

3.1.3 Diagramme de contexte statique

3.1.3.1 Contexte statique du SIO

^Expert

^Guichetier

			^OPERATIONNAL ^INSURANCE SYSTEM
					^Administrateur
^Client

Figure 15: Diagramme de contexte SIO

3.1.3.2 Contexte statique du SID

^OPERATIONNAL

^INSURANCE

^SYSTEM

^{Manager Guichetier}

^{BUSINESS INSURANCE}

^MANAGER

^{Administrateur}

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016

Page | 47

Figure 16: Diagramme de contexte SID

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 48

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.1.4 Identification des cas d'utilisation

Un cas d'utilisation est une séquence de transactions réalisées par le système et qui a un résultat significatif et mesurable pour un acteur particulier.

Le tableau ci-dessous présente les cas d'utilisation recensés et leurs descriptions pour chaque acteur.

Cas d'utilisation Acteurs Description du cas d'utilisation
Gérer police	Guichetier	Créer, modifier, supprimer police
Gérer garantie		Créer, modifier, supprimer garantie
Etablir attestation		Etablir une attestation d'assurance ou quittance
Gérer client		Créer, modifier, supprimer client
Gérer indemnisation		Créer, modifier, supprimer indemnisation
Consulter statistiques
Gérer primes	Client, Guichetier	Créer, modifier, supprimer primes
S'authentifier	Administrateur, Expert, Guichetier, Client, Manager
Gérer profils	Administrateur, Manager	Créer, modifier, supprimer profils
Faire une demande de devis	Client	Demander un devis pour une assurance
Gérer sinistres/Dommages	Client, Expert	Créer, modifier, supprimer sinistres
Extraire données	Administrateur, BDDS	Extraire des données source
Produire requêtes	Administrateur, Guichetier, Manager	Ecrire les requêtes personnalisées

Tableau 3: Cas d'utilisation

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.1.5 Diagramme des cas d'utilisation

3.1.5.1 Diagramme des cas d'utilisation du Système transactionnel

Figure 17: Diagramme de cas d'utilisation (SIO)

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 49

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 50

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.1.5.2 Diagramme des cas d'utilisation du Système décisionnel

Figure 18: Diagramme de cas d'utilisation (SID)

3.1.6 Classification des cas d'utilisation et découpage en itération

L'une des caractéristiques de la méthode de conception que nous avons adoptée est la possibilité d'effectuer des itérations lors de l'élaboration des différents modèles en l'occurrence celui des cas d'utilisation ; ceci garantit que le modèle soit affiné et amélioré après une itération. Puis, chaque itération prend en compte un certain nombre de cas d'utilisation et peut servir à ajouter de nouveaux incréments. Le nombre d'itérations est fortement déterminé par la priorité fonctionnelle du cas d'utilisation. Cette dernière sera haute en fonction du fait que le service rendu soit important pour l'exploitation de l'application ; moyenne si la fonctionnalité est secondaire et basse dans tous les autres cas. Les cas d'utilisation sont également classés en fonction du risque qu'ils font courir à la réalisation du projet dans son ensemble. Les risques peuvent être de diverses natures ; un cas d'utilisation constitue un service rendu à l'utilisateur du système. D'un point de vue technique, il consiste en la manipulation d'un certain nombre de données conceptuelles destinées à être stockées dans un système de données. Plus le nombre de concepts du domaine manipulé est élevé plus la réalisation du cas d'utilisation sera complexe.

Le tableau ci-dessous résume cette classification :

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 51

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

N0 Cas d'utilisation Priorité Risques Numéro Nom de l'itération
1	Gérer police	Haute	Haute	1	Relation client
2	Etablir attestation	Moyenne	Moyen	2	Relation client secondaire
3	Gérer client	Haute	Moyen	2	Relation client secondaire
4	Demander devis	Moyenne	Moyen	2	Relation client secondaire
5	Gérer indemnisation	Haute	Haut	1	Relation client
5	Consulter statistiques	Haute	Haut	1	Relation client
6	Gérer sinistres/Domma ges	Haute	Haut	1	Relation client
7	Gérer primes	Haute	Moyen	2	Relation client secondaire
8	Extraire données	Haute	Haut	1	Relation client
9	Produire requêtes	Haute	Haut	1	Relation client
10	S'authentifier	Moyenne	Moyen	3	Contrôle accès
11	Gérer profils	Moyenne	Moyen	3	Contrôle accès

Tableau 4: Classification des cas d'utilisation en itérations

Un des principes du Processus Unifié consiste à identifier et lever les risques majeurs au plus tôt. Nous devons donc prendre en compte de façon combinée la priorité du système et l'estimation du risque :

? si la priorité est haute et le risque également, il faut planifier le cas d'utilisation dans une des toutes premières itérations (exemple : gérer la police) ;

? si la priorité est basse et le risque également, on peut reporter le cas d'utilisation à une des toutes dernières itérations (exemple : gérer profils).

? lorsque les deux critères sont antagonistes nous pouvons être amenés à négocier avec le client.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 52

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Dans le tableau de planification, nous avons trois (3) itérations. En dehors de ces itérations, il existe une autre itération : la toute première itération dite préliminaire (itération 0). Cette itération est le résultat des travaux effectués à la phase de pré-étude.

Nous avons donc au total quatre (4) itérations. Le tableau suivant récapitule les itérations :

0	Itération préliminaire
1	Relation client
2	Relation client secondaire
3	Contrôle d'accès

N° Itération Nom Itération

Tableau 5: Nombre d'itérations

3.1.7 Description textuelle de quelques cas d'utilisation 3.1.7.1 Cas d'utilisation « s'authentifier »

Titre : S'authentifier

Acteur(s) : Administrateur, Client, Agent, Spécialiste

Résumé : Ce cas d'utilisation permet à un utilisateur de s'authentifier

Date : 04/11/2016 Date de mise à jour : 04/11/2016

Versions : 0.1 Responsable : DJYAMO Azore

Scénario nominal :

1. Le système demande à l'utilisateur de saisir son login et son mot de passe

2. L'utilisateur saisit son login et son mot de passe et valide (A1, E1)

3. Le système vérifie les informations saisies

4. Le système confirme l'identité de l'utilisateur et enregistre l'évènement

Post-condition :

1. L'utilisateur est authentifié

2. L'événement est enregistré dans le journal système

Scénario alternatif :

A1. Login ou mot de passe temporairement incorrect

1. Le système affiche un message à l'utilisateur l'informant de la situation

2. Retour au point 1 du scénario nominal

Scénario d'exception :

E1. Login ou mot de passe définitivement incorrect

1. Le système affiche un message à l'utilisateur l'informant de la situation avec option d'aide pour récupération de mot de passe ou login

2. L'utilisateur suit le lien de récupération de mot de passe ou login

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 53

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.1.7.2 Cas d'utilisation « demander devis »

Titre : demander devis

Acteur(s) : Client

Résumé : Ce cas d'utilisation permet à un client de demander un devis

Date : 08/11/2016 Date de mise à jour : 08/11/2016

Versions : 0.1 Responsable : DJYAMO Azore

Scénario nominal :

1. Le client choisit le lien de demande de devis

2. Le système lui pose une suite de questions

3. Le client répond aux questions

4. Le système affiche un message indiquant qu'il calcul le montant du devis (A1, E1)

5. Le système affiche le montant du devis

Post-condition :

1. Le devis est affiché

Scénario alternatif :

A1. Une donnée des réponses est fausse

a. Le système affiche un message à l'utilisateur l'informant de l'erreur

b. Retour au point 1 du scénario nominal

Scénario d'exception :

E1. La compagnie ne couvre pas le genre de risque demandé

2. Le système affiche un message portant absence de couverture du risque à couvrir Le cas d'utilisation se termine en échec.

3.1.7.3 Cas d'utilisation « gérer police d'assurance »

Titre : gérer police d'assurance

Acteur(s) : Guichetier

Résumé : Ce cas d'utilisation permet à un client de gérer police d'assurance

Date : 09/11/2016 Date de mise à jour : 09/11/2016

Versions : 0.1 Responsable : DJYAMO Azore

Précondition : Le manager s'est authentifié

Scénario nominal (N1):

N1.1- Le Guichetier demande le formulaire d'enregistrement de police d'assurance

N1.2- Le système affiche le formulaire

N1.3- Le Guichetier renseigne les champs (A1, E1)

N1.4- Le système confirme le succès de l'opération

Scénario nominal (N2):

N2.1- Le Guichetier sélectionne une police puis demande une mise à jour de champs

N2.2- Le système affiche les champs éditables

N2.3- Le Guichetier édite les champs ciblés (A2)

N2.4- Le système confirme le succès de la mise à jour

Scénario nominal (N3):

N3.1- Le Guichetier sélectionne la police à supprimer

N3.2- Le système demande une confirmation de l'action (A3, E3)

N3.3- Le Guichetier supprime la police

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

N3.4- Le système confirme le succès de l'opération

Post-condition :

3. Le devis est affiché

Scénario alternatif :

A1. Une donnée des champs est incorrecte

a. Le système affiche un message à l'utilisateur l'informant de l'erreur

b. Retour au point N1.2 du scénario nominal

A2. Une donnée des champs est incorrecte

a. Le système affiche un message à l'utilisateur l'informant de l'erreur

b. Retour au point N2.3 du scénario nominal

A3. La police sélectionnée n'est pas celle ciblée

a. Le Guichetier annule l'opération

b. Retour au point N3.1 du scénario nominal

Scénario d'exception :

E1. La police avait déjà été enregistrée

N1.4- Le système affiche un message indiquant que cette police existe déjà

Le cas d'utilisation se termine en échec.

E3. Le Guichetier renonce à la suppression

N3.4- Le Guichetier annule l'opération

Le cas d'utilisation se termine en échec.

3.2 Expression des besoins non fonctionnels

L'expression des besoins non fonctionnels a pour objet de formaliser et de détailler la partie « technique » de ce qui a été produit au cours de l'étude préliminaire. Il s'agit des besoins qui caractérisent le système. Ce sont des besoins en matière de performance, de type de matériel ou le type de conception. Ces besoins peuvent concerner les contraintes liées à l'implémentation (langage de programmation, de système d'Exploitation...) ou à l'interopérabilité générale. En effet, ces besoins peuvent être fixés par le client (fonctions optionnelles), ou par le développeur (contraintes d'implémentation). Dans cette optique, notre application devra satisfaire les spécifications suivantes :

Pour l'application web :

+ Pouvoir supporter un nombre élevé de requêtes client simultanées;

+ Utiliser une base de données relationnelle ;

+ Les informations sensibles comme les mots de passe seront chiffrés ;

+ Offrir des services de sécurité ;

+ Offrir une interface conviviale et optimisée ;

+ Fonctionner en architecture applicative 3-tiers;

Pour le système décisionnel :

> De disposer d'un SGBD robuste et open source ; > D'utiliser des outils ETL open source ;

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 54

+

+ ^supprimer ()

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016

Page | 55

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

> D'utiliser des outils de reporting open source ;

> D'être capable d'extraire, de traiter et de transférer des données de sources divers et de type varié ;

> De disposer d'une sécurité adaptée ;

> Être performant pour le calcul d'agrégats sur de gros volumes de données (exploration de données, reporting)

> Être appréhendable par un utilisateur final, en particulier pour formuler facilement des requêtes (exploration de données)

> Être suffisamment performant au chargement pour répondre aux sollicitations de mise à jour (ETL)

> Être évolutif en fonction des évolutions amont (sources transactionnels) et aval (besoins d'exploitation) (ETL, métadonnées) ;

3.3 Identification des classes conceptuelles

L'une des parties de la solution que nous allons mettre en place est une application cliente, ayant pour rôle de gérer la relation directe avec les clients. Elle constituera donc une des sources de données qui alimenterait notre entrepôt. Ainsi, le diagramme de classe, qui va nous permettre de mettre en oeuvre la base des données de l'application se présente comme suit :

^Expert

^0..*

^Assurer

^1..1

-

-

- - - - -

^idExpert : ^int

^nomExpert : ^String

^prenomExpert : ^String

^adressExpert : ^String

^proExpert : ^String

^posteExpert : ^String

^{dateNaissExpert} : ^Date

^telExpert : ^String

^statutExpert : ^char

-

-

^codeSini : ^int

^descripSini : ^String

^dateSini : ^Date

^adressSini : ^String

^heureSini : ^Date

^preuveSini : ^double

^{dateDeclaSini} : ^{Date sinistreReglé} : ^boolean

- - - - -

^codeRapport : ^int

^#idExpert : ^int

^#codeDommage : ^int

^descRapport : ^String

^dateRapport : ^Date

^lieuRapport : ^String

- - - -

^codeQuitt : ^int

^#idClient : ^int

^#idGuich : ^int

^{descriptionQuitt} : ^String

^dateQuitt : ^Date

^lieuQuitt : ^String

^{montantPrimes} : ^float

^1..1

^{Faire signer}

^0..*

^1..1

^Elaborer

^0..*

^AttestationAss
- ^codeAttest	: ^int
- ^descriptionAttest	: ^String
- ^dateAttest	: ^Date
- ^lieuAttest	: ^String

+ ^imprimer ()

^Employé

^PoliceAssurance
- ^dateDebutPolice : ^Date
- ^dateFinPolice : ^Date
- ^descriptionPolice : ^String
- ^condiTaciteRecond : ^String - ^montantPrime :^float
- ^conditionPaiementPrime : ^String
- ^codePolice : ^int - ^modaliteDeclarationSinistre : ^String
- ^conditionPaiementIndémnités : ^String
- ^montantGarantie :^float
	- - - ^1..* ^Porter sur				^1..1		^0..*
	+ +				^créer () ^Subir
								-
				+ ^ObjetAssuré
								-
								- -
								-
	^1..*							- ^1..1
				^..1
^1..1
^Souscrire à				- ^codeObj : ^int
+ + ^créer () ^Indemnisation
+ ^calculerDuree () - ^codeIndem		: ^int
- ^delaisPaiemtIndem		: ^int
- ^montantIndem		: ^int
- ^datePaiemtIndem		: ^Date
+ ^modifier ()

^Client

	-	: ^String : ^Date : ^String : ^String : ^String : ^String	+ ^créer () + ^modifier () + ^supprimer () ^1..1 ^Percevoir
^0..* ^Payer prime
	- - ^prenomClient - ^dateNaissClient + ^supprimer () + ^imprimer ()

^idClient

^nomClient

: ^int

: ^String

+ ^supprimer () + ^imprimer ()

^0..*

^TypeAssurance
- ^nomAssurance	: ^String
- ^descriptionAssurance	: ^String
- ^natureRisque	: ^String

^1..*

^Evaluer

^0..*

^créer ()

^{Sinistre/Dommage}

^Rapport

^supprimer ()

^Automobile

: ^int

^1..1

+ ^créer ()

+ ^modifier ()

+ ^supprimer ()

^1..1

^{Etre conclue par}

^{idEmp nomEmp prenomEmp posteEmp dateNaissEmp fonctionEmp}

+ ^créer ()

+ ^modifier () + ^supprimer ()

: ^int : ^String : ^String : ^String : ^Date : ^String

- - - - -

-

+

+

+

^créer ()

^modifier () ^

^supprimer

()

^Quittance

-

-

-

+ + + +

^créer ()

^imprimer ()

^modifier () ^supprimer ()

^1..*

^{immatVeh marqueVeh puissanceVeh carrosserie type}

^carburant

^nbPlaces

^modifier () ^supprimer ()

: ^int : ^String : ^int : ^String : ^String : ^String : ^int

-

-

+

+

+

^supprimer ()

^modifier ()

-

-

-

+

^{calculerDuree} ()

^modifier () ^supprimer ()

-

+

+

+

^créer ()

^modifier ()

^1..1

^{Faire objet}

+ ^{calculerDuree} ()

- ^proClient

- ^{adresseClient} - ^telClient - ^{situatMatriClient} + ^créer () + ^modifier ()

Figure 19: Diagramme de classe

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 56

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.4 Conception du modèle décisionnel

La modélisation par schéma en étoile, par opposition aux schémas normalisés en 3NF, permet de répondre à deux besoins caractéristiques des systèmes décisionnels : la performance et la simplicité des requêtes.

En effet, en tant que structures redondantes les schémas en étoiles permettent d'agréger la table des faits avec n'importe qu'elle dimension en une seule opération de jointure (deux ou trois pour les schémas en flocons).

Ce gain de performance est souvent critique puisque les volumes de données sont généralement d'un ordre de grandeur très supérieur à celui des systèmes transactionnels.

Cette redondance ne pose pas les mêmes problèmes que dans les systèmes transactionnels, en effet :

? les données étant statiques (importées), il n'y a pas de risque de divergence d'information lors de mises à jour

? l'usage du data warehouse étant essentiellement statistique (regroupement), la conséquence d'une éventuelle erreur n'est pas du même ordre que dans un système transactionnel.

La présentation en étoile des données, avec les faits au centre et les dimensions autour, est particulièrement adaptée à l'écriture rapide de requêtes simples pour agréger des données de la table des faits selon des regroupements sur les tables de dimensions.

L'enjeu est de pouvoir répondre simplement et rapidement à une question simple, tandis qu'un modèle transactionnel, qui répond à d'autres contraintes, nécessitera souvent un code SQL complexe et des opérations multiples pour répondre à la même question. Cela permet notamment aux utilisateurs finaux de construire facilement de nouvelles requêtes au fil de leur exploration des données.

On appelle donc « dimension » un axe d'analyse. Dans notre contexte il peut s'agir des clients ou des services d'une entreprise, d'une période de temps comme un exercice financier, des activités menées au sein d'une société, etc.

« Une table de dimension établit l'interface homme / entrepôt, elle comporte une clé primaire » [Kimball, 2002]

Une table de fait est une table qui contient les données observables (les faits) que l'on possède sur un sujet et que l'on veut analyser, selon divers axes d'analyse (les dimensions). Les « faits », dans un entrepôt de données, sont en principe numériques,

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 57

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

puisque d'ordre quantitatif. Il peut s'agir du montant en argent des primes couverts, du nombre de polices contractés dans une compagnie ou agence d'une compagnie, etc.

3.4.1 Matrice dite d'analyse des priorités [Kimball, 2004]

L'approche bottom-up de Kimball préconise l'élaboration du data warehouse data mart par data mart, le data warehouse étant le regroupement des data marts. Cette matrice de priorisation permet d'identifier les data marts qui doivent être construits en premier lieu.

Priorité = Intérêt x Faisabilité

Les activités retenues pour la mise en place de notre entrepôt des données sont :

? La gestion des demandes de devis ; ? Le suivi des polices d'assurance ; ? Le recouvrement des primes ; ? Le suivi des indemnités.

	^Activité "suivi police ^d'assurance"
^Intérêt			^Activité "recouvrement ^des primes"
		^Activité "suivi ^indemnités"
				^Activité "suivi des ^demandes de devis"

^Faisabilité

Figure 20: Matrice d'analyse des priorités de Kimball

3.4.2 Volet « Gestion des demandes de devis »

3.4.2.1 Activité « suivi des demandes de devis »

Cette activité précède souvent l'établissement d'une police d'assurance entre un assuré et son assureur. Son suivi peut être pertinent compte tenu du fait qu'elle détermine le comportement de la clientèle soit vis-à-vis des coûts, soit vis-à-vis de certaines catégories d'assurance.

3.4.2.2 Grain de l'activité « suivi des demandes de devis »

Le choix du grain le plus fin donne un maximum de flexibilité. Le grain le plus fin de l'activité « suivi des demandes de devis » est :

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 58

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Le nombre de demandes émises dans un délai T, par rapport à une assurance A, dans une zone géographique G.

3.4.2.3 Choix des dimensions participantes

La description du processus métier « Gestion des demandes de devis » constitue un guide capital pour le choix des axes d'analyse (dimensions). Reprenons ici cette description

annotée de métriques pour en tirer les bénéfices. 04/0

^Demandeur	^Guichetier	^Actuaire
^Emission demande	^Analyse de la demande
		^demandes
	réçues satisfaites
	^[KO] [OK]
	Recevable	^Traitement des primes et garanties
^Nbre de demandes
^non satisfaites
	^Etablissement du devis
^Reception du devis	^Montant
	^Nbre de demandes ^Nbre de ^Nbre de devis

Figure 21: Processus métier « Gestion de demandes de devis » avec métriques

^{de la prime}

La figure ci-haut nous indique alors que la première ligne constitue les dimensions fondamentales pour la conception de l'étoile relative à notre activité. Par ailleurs, nous constatons que seules ces dimensions ne sont pas suffisantes pour poser des diagnostics pertinents. La démarche que nous avons entreprise à travers la description des processus métier indique que, les dimensions manquantes ne sont essentiellement que celles issues des besoins d'analyse et non recommandées par les scénarii décrivant le processus métier. Nous recensons donc dans le cas de figure, les dimensions « Demandeur », « Guichetier » et « Actuaire ».

Comme tout processus décisionnel se situe éventuellement dans le temps et dans l'espace, nous allons rajouter à ces dimensions, les dimensions « Temps » et « Zone_geo ». Aussi, étant donné qu'une demande de devis ne peut intervenir sans le type d'assurance ou sans un risque à couvrir, nous allons compléter nos dimensions de la dimension « ObjetAssure ». Le type d'assurance (maladie, automobile...) en question va apparaitre comme dimension dégénérée compte tenu de ses attributs pauvres et de son lien étroit avec les mesures.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 59

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Dimension « Client » :

Le client est l'acteur au coeur de l'attention des responsables des compagnies d'assurance. Connaitre ses clients offre les meilleurs moyens en matière de relation client et d'amélioration de l'offre de service. L'observation du comportement des clients permet de consacrer une attention spéciale aux clients ayant de gros portefeuilles par exemple.

Voici comment se présente la dimension « Client » de notre data mart.

^Client
- ^idClient - ^nomClient - ^prenomClient - ^professionClient - ^dateNaissClient - ^adresseClient - ^telClient - ^satatutMatriClient	: ^int : ^String : ^String : ^String : ^Date : ^String : ^char : ^String

Figure 22: Dimension « Client »

Dimension « Actuaire » :

L'actuaire, comme définit plus haut est l'employé d'une compagnie d'assurance chargé de l'étude et de la fixation des primes et indemnités.

^Actuaire
- ^idActuaire -^nomActuaire - ^prenomActuaire	: ^int : ^String : ^String
- ^dateNaissActuaire ringt- ^posteActuaire - ^te adresseActuaire - te ^telActuaire	: ^Date : ^String : ^String
	: ^String

ng

te

- ^{situatMatriActuaire} : ^{String créer} ()

+ + ^modifier ()

+ ^supprimer ()

+ ^imprimer

()

Figure 23: Dimension « Actuaire »

Dimension « ZoneGéographique » :

La dimension zone géographique décrit la zone où le fait a lieu. Le grain le plus bas de cette dimension correspond à l'agence.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 60

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

^Zone_Geographique
- ^codeZoneGeo - ^Agence - ^département - ^Commune - ^Ville - ^Province	: ^int : ^String : ^String : ^String : ^String : ^String

Figure 24: Dimension « ZoneGeographique »

Dimension « Guichetier » :

Le « Guichetier » est la dimension qui correspond à l'agent interne responsable de la mise en marche de contrat avec les clients (pas son élaboration). L'importance de cette dimension réside dans le besoin d'évaluer les performances des agents responsables de la relation client.

Cette dimension est décrite dans la table ci-après :

^Guichetier
- ^idGuichetier - ^nomGuichetier - ^prenomGuichetier - ^adresseGuichetier - ^dateNaissGuichetier - ^telGuichetier	: ^int : ^String : ^String : ^String : ^Date : ^int

Figure 25: Dimension « Guichetier »

Dimension « ObjetAssure » :

Elle décrit l'objet pour lequel la couverture des risques a été engagée. Elle peut désigner un être humain, un engin, un habitat... Cette dimension est décrite dans la table ci-après :

^ObjetAssuré
- ^codeObjetAssure - ^nomObj - ^dateAcquisObj - ^adressObj	: ^char : ^String : ^Date : ^String
	^cod

- ^nom

Figure 26: Dimension « ObjetAssure »

^{a re}

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 61

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

- ^idClient : ^int

Dimension « Temps » :

La dimension temps est « la seule dimension qui figure systématiquement dans tout entrepôt de données, car en pratique tout entrepôt de données est une série temporelle. Le temps est le plus souvent la première dimension dans le classement sousjacent de la base de données » [Kimball, 2001].

Le niveau le plus détaillé de l'information dans cette dimension est le jour. Des analyses journalières sont en outre idéales pour déterminer les performances des équipes dans des activités de terrain telle la sensibilisation, le marketing...

La dimension temps de notre data mart se présente donc comme suit :

^Temps
- ^jour
- ^semaine
- ^mois
- ^codeTemps : ^int - ^trimestre
- ^semestre	: ^Date
- ^Année	: ^Date
	: ^Date

: ^String : ^String : ^Date

Figure 27: Dimension « Temps »

3.4.2.4 Choix des mesures

Tel qu'énoncé dans notre critique des techniques de conception dimensionnelle existantes, il est vrai que la conception est guidée par les besoins exprimés par l'utilisateur mais, nous allons à contrario nous rendre compte que la conception est aussi un canal pour éveiller les utilisateurs sur certains besoins non exprimés.

En effet la figure 19, est une représentation annotée de métriques qui servent à guider nos analyses. Alors, nous estimons dans le cas concret qu'à la vue du processus, au niveau des branches « décision », de besoins d'analyser le nombre de cas succès et le nombre de cas échec pourraient permettre de se renseigner sur les raisons des échecs par exemple. Il est évident que lorsqu'une compagnie sait pourquoi telle ou telle activité échoue, elle a entre les mains des informations très pertinentes pour la prise des décisions stratégiques.

^Contrat

^cdC

Reprenons la branche « décision » dans le graphe de notre processus pour démontrer en

- ^dateDebut : ^Date

quoi tout ceci est très utile pour le choix des mesures. ^Fi

^{ditin Stig}

^typePaiement : ^String

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

^{n du devis}

^{non satisfaites}

^{bre de demandes}

^réçues

^{[KO] [OK]}

^{Etablissement du devis}

^{Nbre de devis}

^Recevable

^satisfaites

^Traiteme

^{Nbre de demandes}

Figure 28: Branches « décision » du processus métier « Gestion de demandes de devis »

^{Nbre de demandes}

Cette figure est reprise uniquement à titre illustratif de l'objectif recherché à travers la démarche par la description des processus. De la branche entrante (en haut), nous avons automatiquement une mesure utile qui est le nombre de demandes de devis « nb_demandes ». Cette mesure pourrait permettre d'évaluer le nombre de devis qu'émet (tent) le(s) client(s) d'une zone donnée par rapport à chaque type d'assurance. Ensuite, la branche qui se termine en échec (à gauche) est d'autant plus pertinente qu'elle pourrait non seulement indiquer à un décideur le nombre de demandes de devis qui n'ont pas reçu des issues favorables mais surtout d'analyser, et le nombre, et les raisons pour lesquelles ces demandes n'ont pas reçues satisfaction. Dans ce cas-là, une des raisons courantes est par exemple l'absence de la couverture des risques demandés. Pourtant, ce type de demandes pourrait au fil du temps s'avérer important en nombre pour inciter ce décideur à se résoudre pour offrir ce genre de couverture de risque au sein de la compagnie d'assurance étant donné la croissance de la demande.

Finalement, pour le cas de notre conception, nous allons sélectionner les mesures : « nb_demandes », « nb_devis», « nb_demandes_insatisfaites ». Le reste est déductible sur requête.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 62

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.4.2.5 Schéma en étoile de l'activité « suivi de demandes de devis »

^Demandeur
- ^idDemandeur		: ^int
- ^nomDemandeur		: ^String
- ^prenomDemandeur		: ^String
- ^dateNaissDemandeur		: ^Date
- ^proDemandeur		: ^String
- ^adresseDemandeur		: ^String
- ^telDemandeur		: ^String
- ^situatMatriDemandeur		: ^String
^Guichetier
- ^idGuich	: ^int
- ^nomGuich	: ^String
- ^prenomGuich	: ^String
- ^proGuich	: ^String
- ^posteGuich	: ^String
- ^dateNaissGuich	: ^Date
^Actuaire
- ^idActuaire				: ^int
- ^nomActuaire				: ^String
- ^prenomActuaire				: ^String
- ^dateNaissActuaire				: ^Date
- ^posteActuaire				: ^String
- ^adresseActuaire				: ^String
- ^telActuaire				: ^String
- ^situatMatriActuaire				: ^String
^Fait Suivi_demande
- ^#idDemandeur					: ^int
- ^#codeTemps					: ^int
- ^#codeAssurance					: ^int
- ^#codeZoneGeo					: ^int
- ^#idGuichetier					: ^int
- ^#idActuaire					: ^int
- ^#codeObjetAssure					: ^int
- ^typeAssurance					: ^String
- ^nb_demandes					: ^int
- ^nb_demandes_insatisfaites					: ^int
- ^nb_devis					: ^int
^ObjetAssuré
- ^codeObjetAssure			: ^char
- ^nomObj			: ^String
- ^dateAcquisObj			: ^Date
- ^adressObj			: ^String

^Temps

^{codeTemps jour semaine mois trimestre semestre Année}

: ^int : ^Date : ^Date : ^Date : ^String : ^String : ^Date

-

-

-

-

-

-

^Zone_Geographique
- ^codeZoneGeo
- ^Agence	: ^String
- ^département	: ^String
- ^Commune	: ^String
- ^Ville	: ^String
- - ^Province	: ^String

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 63

Figure 29: Schéma en étoile du fait « suividemandes»

: ^int

3.4.3 Volet « Gestion des polices d'assurance »

3.4.3.1 Activité « suivi des polices d'assurance »

L'activité « suivi police d'assurance » tel qu'énoncée est celle qui caractérise l'ensemble des contrats d'assurance qui lient l'assureur et le souscripteur. Le chiffre d'affaire d'une compagnie d'assurance est fortement dépendante des contrats qu'elle souscrit avec ses clients. Cette activité, au coeur des finances des compagnies d'assurance est suivant notre analyse (matrice de priorité de Kimball), la première activité à mettre en oeuvre. Ainsi, un regard permanent sur une telle activité permettrait aux manager de prendre des décisions stratégiques dépendamment de la variation du nombre des contrats.

3.4.3.2 Grain de l'activité « suivi police d'assurance »

Le grain le plus fin dans le cadre du suivi de la police d'assurance est :

Le montant de la prime payée par les clients ayant souscrit une assurance (soit pour eux-mêmes, soit pour un objet à assurer) à une date donnée dans une zone géographique donnée (s'il y en a plus d'un).

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 64

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.4.3.3 Choix des dimensions participantes

Comme dans le cas de l'activité précédente, la description du concept métier « Gestion de police d'assurance » constitue le guide principal pour le choix des dimensions de notre futur schéma.

Figure 30: Processus métier « Gestion de police d'assurance » avec des métriques

Ici, nous allons avoir besoin de la dimension « Temps », de la dimension « Zone_géo » pour situer la position géographique de l'opération éventuellement. Aussi, pour de besoins d'analyse en nombre des polices d'assurance dans un délai données et dans une zone géographique donnée, nous rajoutons la table « PoliceAssurance » comme dimension.

En conclusion de notre analyse, nous retenons les dimensions participant à notre schéma qui sont : « Client », « Guichetier », « Actuaire » qui sont issus de l'analyse du processus métier et, « Temps » et « Zone_geo », issues du besoin de situé les résultats dans le temps et dans l'espace. Les dimensions « Police_assurance » et « ObjetAssure » sont d'une importance relative mais nous les retenons dans le cadre de notre travail afin d'élargir nos analyses.

Dimension « Policeassurance » :

Cette dimension, un peu spéciale compte tenu du fait qu'elle est en même temps une table de fait et une table de dimension. La conception des modèles dimensionnels requiert que la table de fait contienne essentiellement des informations chiffrées. Il s'avère que dans le même temps, nous avons besoin de renseigner les décideurs sur les délais des contrats et,

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 65

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

sur certains facteurs requis par le code des assurances CIMA. Ainsi, nous avons jugé nécessaires de représenter cette table tant en dimension qu'en fait.

^PoliceAssurance - ^codePolice - ^dateDebutPolice - ^dateFinPolice : ^Date	: ^int

- ^montantPrime

: ^Date : ^float

Figure 31: Dimension « Policeassurance »

Entre les deux faits, nous pouvons récapituler les dimensions communes sur le tableau suivant :

Dimensions communes	Fait suivi_demandes	Fait Suivi_Police
Client	X	X
Temps	X	X
Zone_géo	X	X
Guichetier	X	X
Police_assurance		X
Actuaire	X	X
ObjetAssure	X	X

Figure 32: Dimensions communes aux deux (2) premiers faits

3.4.3.4 Choix des mesures

La démarche précédente nous permet de trier sur le schéma du processus métier des mesures jugées pertinentes pour nos besoins d'analyse.

Figure 33: Etude des métriques

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Toutefois, nous allons, dans notre cas précis, préconiser une étude des polices d'assurance en termes de montant ou de variation dans le temps. C'est ainsi que nous avons choisi les mesures « montant_primes » et « nb_polices ». Cela uniquement dans le but d'avoir un oeil sur la croissance des activités de la compagnie d'assurance.

3.4.3.5 Schéma en étoile de l'activité « suivi police d'assurance »

- ^codeObjetAssure - ^nomObj - ^dateAcquisObj - ^adressObj
- ^prenomGuichetier - ^adresseGuichetier - ^dateNaissGuichetier

- ^idClient
- ^nomClient
- ^prenomClient

- ^{adresseClient}

- ^codeTemps

- ^jour

- ^semaine

- ^mois

- ^trimestre

- ^semestre

- ^Année

- ^{dateNaissClient}

- ^telClient

- ^{satatutMatriClient}

^Temps

^Client

- ^{professionClient}

: ^int

: ^Date : ^Date : ^Date : ^String : ^String : ^Date

	- ^idActuaire - ^nomActuaire - ^prenomActuaire - ^dateNaissActuaire - ^posteActuaire

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 66

^ObjetAssuré

: ^char

: ^String

: ^Date

: ^String

^{Fait Suivi_Police}

- ^#idClient

- ^{#idGuichetier}

- ^#codeTemps

- ^#idActuaire

- ^#codePolice

- ^{#codeObjetAssure}

- ^#codeZoneGeo

- ^{typeAssurance}

- ^nb_polices

- ^total_primes

: ^int

: ^int

: ^int

: ^int

: ^int

: ^int

: ^int

: ^String

: ^int

: ^float

- ^{telGuichetier}

^{Zone_Geographique}

Figure 34: Fait « SuiviPolice »

: ^int

: ^String

: ^String

: ^String

: ^Date

: ^String

: ^char

: ^String

^{PoliceAssurance}

- ^codePolice

- ^{dateDebutPolice}

- ^{dateFinPolice}

- ^montantPrime

: ^String

: ^Date

: ^Date

: ^float

^Guichetier

: ^int

: ^String

: ^String

: ^String

: ^Date

: ^int

^Actuaire

- ^{adresseActuaire}

- ^telActuaire

- ^{situatMatriActuaire}

: ^int

: ^String

: ^String

: ^Date

: ^String

: ^String

: ^String

: ^String

- ^codeZoneGeo

- ^Agence

- ^département

- ^Commune

- ^Ville

- ^Province

: ^int

: ^String

: ^String

: ^String

: ^String

: ^String

3.4.4 Volet « suivi des primes »

3.4.4.1 Activité « recouvrement des primes »

La prime d'assurance est le prix que le preneur d'assurance doit payer pour pouvoir bénéficier de la couverture d'assurance en cas de sinistre. Cette prime constitue la principale activité génératrice de revenu au sein des compagnies d'assurance.

3.4.4.2 Grain de l'activité « recouvrement des primes »

Le grain le plus fin de l'activité « recouvrement des primes » est :

Le montant de prime versée à une date donnée par un client, relativement à l'assurance d'un l'objet ou du client lui-même.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 67

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.4.4.3 Choix des dimensions participantes

Sur la base de la démonstration faite précédemment, nous allons appliquer les mêmes approches à l'activité en cours d'analyse.

^Modèle : ^PM_

^g

^Client

^Comptable

^{Nbre d'échéance de paiement}

^Diagramme : ^{DiagrammeActivtes1 A}

^{[Assurance de dommage]}

^{Montant de primes payées à}

^l'échéance

^{Reception de l'attestation}

^{[OK [Art. 216]]}

^{Primes récus?}

^{Montant de primes impayées à}

^[KO]

^l'échéance

^{Emission d'une lettre}

^{Reception de la lettre}

^{[Art. 13-1]}

^{Montant de primes payées après reception de}

^lettre

^{[OK [Art. 216]]}

^{Paiement réçu?}

^[KO]

^Mont

^{nt de primes impayés après reception de}

^lettre

^{Rupture de contrat?}

^[KO]

^{[Ok [Rupture de plein droit]]}

^{Nbre de contrat rompus pour primes impayées}

^{[Art. 216]}

^{Reception de la prime}

^{[Reprise du contrat]}

Figure 35: Processus métier « Gestion de primes » avec métriques

Les annotations en blancs constituent un guide pour le choix des mesures à intégrer dans la table de fait. Certes non exhaustive, elle permet d'élargir le champ de vision pour des choix brillants.

Ainsi, de la même manière, la première ligne nous indique déjà les dimensions en relation directe avec le processus. Nous avons donc comme dimensions le « Client »,

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 68

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

«Comptable », augmentées des dimensions « Temps », « Zone_géo » pour la situation dans le temps et dans l'espace de l'opération. La dimension « ObjetAssure » revient pour servir d'axe d'analyse en ce qui concerne les sujets assurés.

Dimension « Comptable » :

Le comptable est chargé entre autres du recouvrement des primes dans une compagnie d'assurance.

^Comptable
- ^idComptable	: ^int
- ^nomComptable	: ^String
- ^prenomComptable	: ^String
- ^adresseComptable	: ^String
- ^posteComptable	: ^String
- ^dateNaissComptable	: ^Date
- ^telComptable	: ^String

Figure 36: Dimension « Comptable »

Ainsi les dimensions communes aux trois étoiles sont :

Dimensions communes	Fait suivi_demandes	Fait Suivi_Police	Fait Recouvrement_Primes
Client	X	X	X
Temps	X	X	X
Zone_géo	X	X	X
Guichetier	X	X
PoliceAssurance		X
Actuaire	X	X
ObjetAssure	X	X	X
Comptable			X

Tableau 6: Dimensions communes aux trois (3) premiers faits

3.4.4.4 Choix des mesures

Le choix des mesures quant à lui se fait strictement par rapport aux besoins d'analyse pour des décisions stratégiques. C'est pourquoi, la lecture de notre description du processus métier annoté aide à opérer des choix judicieux. Cette étude, comme déjà soulignée, concerne les branches « décision » de notre processus métier.

En ce qui concerne les mesures, conformément à la figure 29, nous choisissons de nous intéresser aux mesures « montant_primes » qui nous aideraient à connaitre les primes

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

versées par un client à une date donnée et « primes_impayes » qui nous aideraient à connaitre les primes impayées par un client à une date données, éventuellement des cumuls. Nous ajouterons une mesure « montant_primes_total » qui pourrait par exemple fournir le montant de primes cumulé sur une durée donnée pour l'ensemble des clients.

3.4.4.5 Schéma en étoile de l'activité « suivi des primes »

-

^codeZoneGeo ^Agence ^département ^Commune ^Ville ^Province

: ^char

^ObjetAssuré
- ^codeObjetAssure	: ^String
- ^nomObj	: ^String : ^String
- ^dateAcquisObj	: ^String : ^Date
- ^adressObj	: ^String

- ^codeTemps

- ^jour

- ^semaine

- ^mois

- ^trimestre

- ^semestre

- ^Année

^Temps

: ^char : ^Date : ^Date : ^Date

: ^Date

- ^idClient

- ^nomClient

- ^prenomClient

- ^{professionClient}

- ^{dateNaissClient}

- ^{adresseClient}

- ^telClient

- ^{satatutMatriClient}

^{Fait Recouvrement_Primes}

- ^#idClient

- ^#codeTemps

- ^{#codeObjet_assuré}

- ^#idComptable

- ^#codeZoneGeo

- ^assurance

- ^{montant_primes}

- ^{primes_impayees}

- ^{montant_primes_total}

^Client

^Zone_geo : ^String : ^String : ^String : ^String

: ^int : ^String : ^String : ^String : ^Date : ^String : ^char : ^String

: ^int : ^int

: ^int : ^int : ^int

^Comptable
- ^idComptable
- ^nomComptable	: ^String
- ^prenomComptable	: ^String
- ^adresseComptable	: ^String
- ^posteComptable	: ^String
- ^dateNaissComptable	: ^Date
- ^telComptable	: ^String
+ ^créer ()
+ ^modifier ()

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 69

Figure 37: Fait « RecouvrementPrimes »

- - - - -

: ^String

: ^String

: ^String

: ^String

: ^String

+ ^supprimer ()

3.4.5 Volet « Gestion des indemnités »

3.4.5.1 Activité « suivi des indemnités »

L'indemnité est une somme versée par l'assurance à un assuré ou à une victime d'un préjudice. Le suivi d'une telle activité permet de résoudre la question de la satisfaction des clients et ouvre les portes de la fidélisation et de l'adhérence massive. Ainsi, un manager ayant l'assurance de la satisfaction de ses clients peut facilement observer une croissance du chiffre d'affaire.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 70

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.4.5.2 Grain de l'activité « suivi des indemnités »

Le plus petit grain d'information à tirer de cette étoile est :

Montant d'indemnité versée à un client X à une date T, relativement au sinistre/dommage G dans l'agence A.

3.4.5.3 Choix des dimensions participantes

Nous allons suivre la même logique pour choisir nos dimensions.

Montant des indemnisations

Figure 38: Processus métier « Gestion des indemnités» avec métriques

La figure ci-dessus indique que nous avons des acteurs issus des structures internes de l'entreprise (à gauche en bleu) et les deux autres à droite sont des dimensions issues de structures externes aux compagnies d'assurance. Ainsi, nous allons donc retenir l'ensemble des dimensions pour permettre de meilleures analyses. Nous retenons donc

les dimensions : « Client », « Expert », « Guichetier », « Comptable »,
« Expert_externe », « Autorite_judiciaire ». Nous rajoutons les dimensions « Police_assurance » car une indemnisation est relative à une police quelconque, « Sinistre/Dommage » pour de besoins d'analyse et bien évidemment les dimensions « Temps » et « Zone_géo » pour la situation dans le temps et dans l'espace.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 71

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Dimension « Expert » :

Cette dimension est présente pour souligner l'expert qui a constaté le sinistre ou le dommage à assurer. Elle est aussi un facteur d'évaluation des compétences (ou de la responsabilité) des agents internes.

^Expert
- ^idExpert - ^nomExpert - ^prenomExpert - ^adresseExpert - ^dateNaissExpert - ^telExpert	: ^int : ^String : ^String : ^String : ^Date : ^int

Figure 39: Dimension « Expert »

Dimension « Expertexterne » :

La dimension « Expertexterne » représente tout expert choisi par consensus entre l'expert de la compagnie et l'expert du client pour constater des dommages, ou réévaluer une proposition d'assurance.

^{dObeté i}

^nomObjet : ^String

^{ExpertExterne}

^{idExpertE nomExpertE prenomExpertE adressExpertE proExpertE posteExpertE dateNaissExpertE telExpertE}

: ^int

: ^String : ^String : ^String : ^String : ^String : ^Date : ^String

-

-

-

-

-

-

-

-

Figure 40: Dimension « Expertexterne »

^t

Dimension « Autoritejudiciaire» :

La dimension « Autoritejudiciaire» représente la personne morale qui ranche les différends entre la compagnie d'assurance et son client.

- ^{contenuRappot} : ^String

^Autorite_judiciaire
- ^idAJ	: ^int
- ^nomAJ	: ^String
- ^descriptionAJ	: ^String
	: ^String
- ^adresseAJ - ^telAJ	: ^int

Figure 41: Dimension « Autoritejudiciaire»

^ille : ^Strng

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Dimension « Sinistre/Dommage » :

La dimension « Sinistre/Dommage » représente le sinistre ou le dommage à l'origine de la demande d'indemnisation.

^{Sinsitre/Dommage}

- ^codeSinistre

- ^{descriptionSinistre}

- ^dateSinistre

- ^{adresseSinistre}

: ^int

: ^String : ^Date : ^String : ^Date : ^String : ^Date

Figure 42: Dimension « Sinistre/Dommage»

- ^{heureSinistre}

- ^{preuveSinistre}

- ^{dateDeclarationSinistre}

3.4.5.4 Choix des mesures

La description annotée du processus nous offre plusieurs mesures possibles. Mais nous allons nous intéresser au nombre de sinistre/dommages déclarés (une donnée qui permettra de réévaluer les risque couverts selon qu'ils sont fréquents ou pas), au montant des indemnités versées (donnée qui indiquerait les dépenses par période et par zone géographique par exemple), au nombre de dossiers défavorables après contre-expertise (donnée qui permettrait d'évaluer les compétences des experts internes) et au nombre de dossier ayant fait l'objet d'un recours judiciaire.

Donc nous avons les mesures : « sinistres_declares », « indemnites_versees », « nb_contre-expertise », « nb_recours_judiciaire ».

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 72

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.4.5.5 Schéma en étoile de l'activité « suivi des indemnités »

^Client
- ^idClient						: ^int
- ^nomClient						: ^String
- ^prenomClient						: ^String
- ^professionClient						: ^String
- ^dateNaissClient						: ^Date
- ^adresseClient						: ^String
- ^telClient						: ^char
- ^satatutMatriClient						: ^String
^Comptable
- ^idComptable			: ^int
- ^nomComptable			: ^String
- ^prenomComptable			: ^String
- ^adresseComptable			: ^String
- ^posteComptable			: ^String
- ^dateNaissComptable			: ^Date
- ^telComptable			: ^String
+ ^créer ()
+ ^modifier ()
^Expert
- ^idExpert	: ^int
- ^nomExpert	: ^String
- ^prenomExpert	: ^String
- ^adresseExpert	: ^String
- ^dateNaissExpert	: ^Date
- ^telExpert	: ^int
^ExpertExterne
- ^idExpertE		: ^int
- ^nomExpertE		: ^String
- ^prenomExpertE		: ^String
- ^adressExpertE		: ^String
- ^proExpertE		: ^String
- ^posteExpertE		: ^String
- ^dateNaissExpertE		: ^Date
- ^telExpertE		: ^String

^Temps

^{codeTemps jour semaine mois trimestre semestre Année}

: ^int : ^Date : ^Date : ^Date : ^String : ^String : ^Date

- - - - - - -

^Guichetier
- ^idGuich		: ^int
- ^nomGuich		: ^String
- ^prenomGuich		: ^String
- ^proGuich		: ^String
- ^posteGuich		: ^String
- ^dateNaissGuich		: ^Date
^Zone_Geographique
- ^codeZoneGeo	: ^int
- ^Agence	: ^String
- ^département	: ^String
- ^Commune	: ^String
- ^Ville	: ^String
- ^Province	: ^String
^Fait Suivi_indemnites
^#idClient -				^int
- ^#idExpert				: : ^int
- ^#codeTemps				: ^int
- ^#codeObjet_assuré				: ^int
- ^#codeZoneGeo				: ^int
- ^#codeSinistre				: ^int
- ^#codeRapport				: ^int
- ^sinistres_declares				: ^int
- ^indemnites_versees				: ^int
- - ^nb_contre_expertise				: ^int
- ^nb_recours_judiciaire				: ^int
-
^PoliceAssurance
- ^codePolice			: ^int
- ^dateDebutPolice			: ^Date
- ^dateFinPolice			: ^Date
- ^montantPrime			: ^float

^Sinsitre/Dommage
- ^codeSinistre	: ^int
- ^descriptionSinistre	: ^String
- ^dateSinistre	: ^Date
- ^adresseSinistre	: ^String
- ^heureSinistre	: ^Date
- ^preuveSinistre	: ^String
- ^dateDeclarationSinistre	: ^Date

-

-

-

^idAJ : ^int

^nomAJ : ^String

^{descriptionAJ} : ^String

^adresseAJ : ^String

^telAJ : ^int

^{Autorite_judiciaire}

+ ^supprimer ()

Figure 43: Fait « SuiviIndemnités »

Les dimensions communes aux étoiles sont représentées dans le tableau ci-dessous :

Dimensions Fait Fait Fait Fait

communes suivi_demandes Suivi_Police Recouvrement_Primes Suivi_Indemnit

és

Client

Temps Zone_geo Guichetier Police_assuran ce

Expert Actuaire ObjetAssure Comptable Expert_externe Autorite_judici aire Sinnistre/Dom mage

X	X	X	X
X	X	X	X
X	X	X	X
X	X		X
	X		X
	X		X
X	X
X	X	X
		X	X
			X
			X
			X

Tableau 7: Dimensions communes aux faits

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 73

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 74

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.5 Modèles dynamiques

3.5.1 Diagrammes de séquence

Les diagrammes de séquences sont la représentation graphique des interactions entre les acteurs et le système selon un ordre chronologique dans la formulation Unified Modeling Language.

3.5.1.1 Diagramme de séquence du cas d'utilisation « S'authentifier»

^{DS "s'authentifier"}

^alt

^[else]

^ACTEUR

^{[if (login and mot de passe= true]}

^loop

^{[login and/or mot de passe= false]}

^{lien de récupération de mot de passe}

^{Notification d'erreur} + ^{login page}

^{affichage de la page d'accueil}

^{demande de formulaire}

^{affichage du formulaire}

^login + ^{mot de passe}

^{vérification des paramètres}

^"Système"

Figure 44: DS du CU « S'authentifier

3.5.1.2 Diagramme de séquence du cas d'utilisation « demander devis»

^{DS "demander devis"}

^alt

^[else]

^{[if (saisie correcte]}

^Client

ref ^{DS "s'authentifier"()}

^loop

^{[saisie incorrecte]}

^{reponse aux questionnaires}

^{affichage de questionnaires}

^{action demande de dévis}

^{affichage du montant}

^{reprise de procédure}

^{Notification d'erreur}

^{vérification des paramètres}

^"Système"

Figure 45: Diagramme de séquence « demander devis »

.

t

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016

'111

Page | 75

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.5.1.3 Diagramme de séquence du cas d'utilisation « consulter reporting»

Figure 46: Diagramme de séquence « consulter reporting »

3.5.1.4 Diagramme de séquence du cas d'utilisation « Gérer police d'assurance »

^{DS "Gérer police d'assurance"}

^alt

^Guichetier

^[Choix = ^{ModifierPolice]}

^[Choix = ^{Supprimer Police]}

^ref

^loop

^[Choix = ^{EnregistrerPolice]}

^{[saisie incorrecte]}

^{Demande d'action portant gestion de}

^{Affichage de l'interface demandée}

^{Choix d'opération [Enregistrer, Modifier,}

^{Supprimer, Consulter]}

^police

^{Rapport de succés de la suppression}

^{Message fichier ou saisie incorrecte}

^{Message fichier ou saisie incorrecte}

^{Affichage suivant le choix}

^{EnregistrerPolice()}

^{Choix de la police}

^{ModifierPolice} ()

^{ChoisirPolice()}

^{DS S'authentifier()}

^{Choix police}

^"SYSTEME"

Figure 47: Diagramme de séquence « Gérer police d'assurance»

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.5.2 Diagrammes d'activités

Le diagramme d'activités est une représentation proche de l'organigramme. La description d'un cas d'utilisation par un diagramme d'activité correspond à sa traduction algorithmique. Une activité est l'exécution d'une partie du cas d'utilisation, elle est représentée par un rectangle aux bords arrondis. Nous présentons ici des diagrammes d'activités de quelques cas d'utilisations détaillés.

3.5.2.1 Diagramme d'activité « demander devis »

Figure 48: Diagramme d'activité « demander devis »

3.5.2.2 Diagramme d'activité « Consulter reporting»

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016

Page | 76

Figure 49: Diagramme d'activité « consulter reporting »

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 77

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.5.2.3 Diagramme d'activité « Gérer police d'assurance »

Figure 50: Diagramme d'activité « gérer police d'assurance »

3.6 Diagramme de déploiement

En UML, un diagramme de déploiement est une vue statique qui sert à représenter l'utilisation de l'infrastructure physique par le système et la manière dont les composants du système sont repartis ainsi que les relations entre eux. Les éléments utilisés par un diagramme de déploiement sont principalement les noeuds, les composants, les associations et les artefacts. Dans le cas précis de notre projet, leurs rôles sont :

? Le serveur d'application est responsable de la gestion des sessions utilisateurs,

la gestion des polices d'assurance, la gestion des sinistres, gestion des primes, etc. ; ? Le serveur de données (MySQL) représente la partie centrale du SIO qui gère la

base de données et ses accès ;

? Le serveur web transmet à l'utilisateur le résultat de la requête envoyée ;

Ensuite, nous avons pour le compte du SID :

? La machine Talend Open Studio qui est la machine qui extrait, charge et transforme les données sources pour les stocker dans l'entrepôt ;

? Le serveur de données PostgréSQL, représente le SGBD que nous avons choisi pour servir d'entrepôt de données ;

? Plus haut, nous avons une machine qui sert à représenter toute autre source de données qui alimenterait notre DW ;

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

? Enfin, nous avons les navigateurs web, sur lequel s'exécute le serveur apache pour permettre exécution du logiciel de reporting open source « SpagoBI » avec quelques modules de reporting représentés.

Le déploiement de notre solution se présente comme dans le schéma ci-après :

« ^Artefact »

« ^Artefact »

^{Architecture SIO}

^{Serveur de données}

^{Serveur web}

^HTTP

^Apache

^{Utilisateur SIO}

^SQL

^MySQL

« ^Artefact »

^Users

^Manager

^{Autres sources de données}

« ^Artefact »

^{Talend Open Studio}

« ^Artefact »

^{Oracle, MySql, Postgres}

...

« ^Artefact »

^{Machine ETL}

« ^Artefact »

^JasperRepo

^srtingEngin

^{Serveur apache} « ^Artefact » ^Tomecat

^{Architecture SID}

« ^Artefact »

^MobileRepo

^rtEngine

^{Utilisateur SID}

^{Navigateur web}

« ^Artefact »

^{BDD Data Warehouse}

« ^Artefact »

^{TalendEngine Administration}

^PostgréSQL

^SpagoBI

« ^Artefact »

Figure 51: Diagramme de déploiement

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 78

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

3.7 Architecture technique

L'architecture technique décrit des composants logiciels déployés sur les composants matériels. Ces composants logiciels sont : des systèmes d'exploitation, des middlewares, des SGBD, des composants liés à l'exploitation (ordonnanceur, supervision système et réseau, logiciel de sauvegarde...), des serveurs web, des serveurs d'applications, d'autres serveurs (DNS, SMTP, NTP...), les composants logiciels spécifiques à l'application.

Figure 52: Architecture technique

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 79

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 80

Conclusion

Dans la deuxième partie de ce travail, il était question de déterminer les méthodes d'analyse et de conception, de déterminer les techniques d'analyse et de conception... Il était aussi question de concevoir les modèles nécessaires à la mise en oeuvre de nos solutions. Les différentes architectures ont également été proposées pour le déploiement de nos solutions.

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

PARTIE 3 : MISE EN OEUVRE ET

CONDUITE DE PROJET

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 81

La troisième et dernière partie de notre travail se penche sur la mise en oeuvre et de la conduite de projet. Ici, nous parlons précisément dans le premier chapitre (Mise en oeuvre), des outils utilisés pour la mise en oeuvre du projet et des technologies impliquées dans cette étape. Nous y présentons en outre quelques captures d'écran des solutions mise en oeuvre. Dans le deuxième chapitre (La conduite de projet), nous exposons l'organisation humaine, organisationnelle...qui ont permis le succès de ce projet.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 82

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

CHAPITRE 1 : MISE EN OEUVRE

1.1 Choix et mise en place des outils décisionnels libres

1.1.1 Choix de l'outil BI

SpagoBI et Pentaho, les deux principales suites décisionnelles open source, sont composés de plusieurs briques logiciels qui répondent à toutes les étapes et besoins d'un projet décisionnel. Les deux suites comprennent le même outil de conception et d'analyse : Mondrian qui, associé à JPivot, constitue l'élément central pour du décisionnel open source. Ce partage du composant central implique d'ailleurs que les deux produits vont pourvoir partager sur les mêmes données et les mêmes cubes sans avoir à les adapter pour l'un ou l'autre outil. Ce partage implique aussi que les performances de calcul sont les mêmes pour les deux suites, car elles dépendent uniquement de la base des données et du requêteur OLAP.

Les deux suites comprennent un ETL:

? Pentaho : Kettle ? SpagoBI: Talend

Voici des axes de comparaison utiles pour le choix d'une solution :

Critères Pentaho SpagoBI

Etats	Eclipse BIRT, JasperReports, JFreeReport	JasperReports, BIRT
Graphiques	FreeChart	BIRT
Analyses	JPivot, Mondrian	Mondrian, JPivot, Palo (version2.0)
Portail	JBoss Portal, Liferay	eXo platform, Liferay
Planificateur	Quartz	Quartz
Workflow	Enhydra Shark
ETL	Kettle (Pentaho DataIntegration)	Talend Open Studio (génération de code Java et Perl)
Data mining	Weka	Weka
Serveur	TOMCAT, JBoss	TOMCAT, JBoss, JOnAS
Licence	Open source (gratuit) avec des modules payants	Full open source et gratuit
Communauté	Forte	Assez forte
Autre		Création de requête SQL - indicateur dynamique : Open Laszlo

Tableau 8: Pentaho vs SpagoBI

(Source : http://blog.smile.fr/Pentaho-ou-spagobi)

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 83

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

SpagoBI est une solution Open Source pour le développement de projets de type Business Intelligence, proposé par la société italienne Engineering Ingegneria Informatica.

Il n'y a donc pas de fonctionnalités volontairement absentes et réservées pour une version commerciale comme c'est le cas pour Pentaho.

SpagoBI est une plateforme décisionnelle complète, qui se veut agrégatrice de composants décisionnels tiers : Mondrian/JPivot, BIRT, JasperReport, Weka, Microsoft SSRS ... Il existe même un connecteur pour Business Object.

SpagoBI a su profiter de la puissance du portail d'intégration eXo, en utilisant les fonctionnalités d'ECM (Enterprise Content Management) intégrées, comme le versionnement, le worlkflow, l'ajout de commentaires aux documents décisionnels, la gestion des utilisateurs et des droits ... ce qui en fait un outil très intéressant et très pratique en production.

Cette solution offre donc une couche logicielle complète comprenant toutes les étapes de l'intelligence décisionnelle comme les fonctions de Reporting, OLAP, de data mining, dashboards, QBE (Query By Example), collecte des données (ETL)...

SpagoBI permet un développement très flexible permettant de « mixer » l'open source avec des solutions propriétaires.

Son grand avantage est donc sa capacité d'intégration, ce qui permet de travailler indépendamment par briques séparées et une meilleure répartition du travail.

Son inconvénient principal est que c'est une solution jeune dans un secteur en pleine évolution, il faut donc se tenir régulièrement au courant quant à l'ajout de nouveaux composants et de fonctionnalités.

1.1.1.1 Installation et configuration de SpagoBI

SpagoBI est disponible en version compressée (.zip) à l'adresse du lien : https://www.spagoworld.org/xwiki/bin/view/SpagoWorl/Download

Prérequis : Java (JAVA_HOME), Apache Tomecat (ou JBoss ou JOnAS), Driver des SGBD

sources.

Guide d'installation : https://www.spagoworld.org/xwiki/bin/view/SpagoBI/Support

1.1.1.2 Lancement de SpagoBI

Une fois SpagoBI installé, le serveur peut être lancé à partir du fichier startup.bat situé dans le répertoire .../tomecat/bin/startup.bat. Le portail est accessible à l'adresse http://localhost:8080/SpagoBI selon votre configuration. La page d'authentification de cet outil décisionnel se présente comme suit :

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 84

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Figure 53: Page d'authentification de SpagoBI

Trois profils sont alors disponibles : biadmin, bidemo et biuser. Voici une capture de la page d'accueil de l'utilisateur biadmin :

Figure 54: Page d'accueil « biadmin » de SpagoBI

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 85

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

1.1.2 Choix de l'ETL

Un ETL (Extract Transform and Load) est un outil qui permet d'extraire des données à partir de différentes sources, de les transformer légèrement (format, dénomination, dénormalisation...), et de les charger dans une nouvelle base (le Data warehouse). Les sources de données peuvent être : SGBD relationnels, flux XML, fichier CSV.

Il existe plusieurs outils ETL open source. Seulement deux ETL Open Source les plus connus : Kettle (Pentaho Data Integration) et Talend Open Studio (TOS).

En raison du fait que nous avons porté notre choix sur SpagoBI, et que ce dernier intègre l'ETL TOS, nous sommes donc amenés à choisir sans hésitation TOS comme ETL pour notre projet.

Talend Open Studio est un ETL open source apparu en 2005, développé par la société Talend. C'est un ETL (Extract Transform and Load) de type « générateur de code », c'est-à-dire qu'il permet de créer graphiquement des processus de manipulation et de transformation de données, puis de générer l'exécutable correspondant sous forme de programme java ou Perl.

Talend offre deux outils d'intégration de données : Talend Open Studio for Data Integration, outil de développement gratuit et open source, et Talend Enterprise Data Integration qui intègre des fonctionnalités avancées de déploiement et de gestion distribué sous licence commerciale.

(Source : n.open-source-guide.com/Solutions/Developpment-et-couches-intermediaires/Etl/Talend)

1.1.2.1 Installation de Talend Open Studio (TOS) Prérequis :

? RAM : 3GB minimum mais 4GB recommandé ? Espace disque dur : 3GB et plus

? Java (JAVA_HOMA)

TOS est téléchargeable sur : http://www.talend.com/download/. Il est disponible en version .zip. Après l'avoir extrait, lancez l'exécutable et suivez les instructions d'installation. Si vous voulez configurer l'allocation de mémoire, éditez le fichier TOS_DI/DQ/BD-win32-x86.ini.

Accédez à l'application Talend Open Studio dans son répertoire d'installation. Double-cliquez sur l'exécutable Talend Open Studio pour lancer l'application.

Afin de pouvoir accéder aux SGBD pour réaliser un ETL, il peut être nécessaire d'installer des librairies supplémentaires et de réaliser de configurations java à plusieurs niveaux (dans le répertoire du disque C ainsi que dans le répertoire de TOS).

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Figure 55: Page après lancement de l'exécutable TOS

Figure 56: Licence TOS

Lisez et acceptez les termes de la licence GPL v2 pour continuer

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 86

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 87

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Figure 57: Configuration de TOS

Le formulaire d'enregistrement Talend Open Studio est accessible via le bouton « Manage Connections ». Remplissez votre adresse électronique et votre lieu de résidence pour recevoir des informations sur Talend Open Studio. Cette étape est facultative, cliquez sur Finish si vous ne souhaitez pas la renseigner.

Figure 58: Configuration de TOS (suite)

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016

Page | 88

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Vous pouvez renseigner ou modifier ces informations d'enregistrement à tout moment, en cliquant sur Window > Preference > Talend > Install/Update.

Remarque : Soyez assuré que toutes les informations personnelles que vous fournissez à Talend, ne sont pas transmises à des tiers et ne sont pas utilisées à d'autres fins que celles de vous informer sur Talend et les produits Talend. Aucun mot de passe (Password) n'est requis.

Validez puis cliquez « Finish ». Vous obtenez le chargement suivant à votre écran.

Figure 59: Chargement des bibliothèques TOS

Figure 60: Guide de prise en main de TOS

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 89

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Cliquez sur le bouton NEXT pour apprendre sur les éléments à l'interface de l'application.

Si vous avez déjà créé des projets avec une version précédente de Talend Open Studio, vous pouvez les importer dans votre espace de travail à l'aide du bouton Import projects.

Si vous créez un projet pour la première fois, cliquez sur New project pour lancer l'assistant de création de projet.

Pour faciliter votre prise en main de Talend Open Studio, des exemples de job sont à votre disposition via Import Demos. Le dossier de projets Demos est automatiquement installé dans votre espace de travail. Et ce projet est accessible directement dans la fenêtre de connexion, dans le champ Projects.

La création d'un projet met automatiquement en place une arborescence de fichiers sur le serveur de votre référentiel. Celle-ci correspond en tout point à l'arborescence de répertoires qui sera affiché dans le Repository de votre projet Talend Open Studio.

1.1.2.2 Lancement de Talend Open Studio(TOS)

Talend Open Studio s'ouvre sur une fenêtre à zones multiples.

Figure 61: Page d'accueil TOS

1.1.3 Politique et opérations d'entreposage des données

Notre entrepôt de données étant situé dans PostgreSQL, nous effectuons l'extraction depuis la source MySQL, qui est alimentée par notre SIO.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016

Page | 90

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Dans cette partie, nous allons nous servir du schéma conceptuel créé dans le chapitre précédent, nous allons nous intéresser aux étapes d'alimentations du Data warehouse. Le schéma conceptuel de l'entrepôt de données que nous avons créé précédemment nous oblige à adapter la structure des données source à fin de réaliser notre entreposage. C'est pour cette raison que l'ETL est la phase la plus importante dans un projet Data warehouse. Selon Yazid Grim[5] : « Il est important de savoir que la réalisation de l'ETL constitue 70% d'un projet décisionnel en moyenne. Et ce n'est pas pour rien, ce système est complexe et ne doit rien laisser s'échapper, sous peine d'avoir une mauvaise information dans l'entrepôt, donc des données fausses, donc inutilisables ».

Mais avant de faire un ETL, il est conseillé d'étudier tout d'abord les sources de données. En effet, c'est d'après les sources que les stratégies de chargement vont être définies. Par la suite, il faut poser des questions fondamentales qui dessineront les caractéristiques des sources des données comme la disponibilité, comment accéder à ces données, comment assurer les chargements incrémentiels de données etc.

L'opération d'extraction, de transformation et de chargement peut alors être possible et méthodique après cette étude.

1.1.3.1 L'extraction des données

Cette opération se réalise sous Talend Open Studio (TOS) après avoir mis à jour les pilotes de connexion aux bases de données concernées. Cette étape passée, le test de la connexion est visible via la création de la connexion à la source comme indiqué dans la figure ci-dessous.

Figure 62: Configuration de la connexion à la source

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 91

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

L'opération d'extraction des tables s'effectue ensuite grâce à un clic droit sur la connexion et en choisissant « Récupérer le schéma ». La figure suivante (figure 64) nous montre comment la base source se présente lors de cette opération.

Figure 63: Extraction des tables

1.1.3.2 La transformation et le chargement des données

Dans la dernière phase, les données qui proviennent des bases de production sont souvent brutes et nécessitent des transformations afin de devenir significatives pour l'utilisateur final et prêtes à être chargées dans la nouvelle base (l'entrepôt de données). A l'aide de la fonctionnalité « Drag and drop » dans un espace de travail appelé « job » sous TOS, nous déposons les tables à extraire, les composants nécessaires à la transformation (ici tMap, tRowLog...) et le composant de sortie (ici tPostgresqlOutput) pour la Dimension ou le Fait. Voici un schéma illustratif relatif à l'ETL des dimensions « PoliceAssurance » et « Temps » de « job » sous TOS.

Figure 64: Préparation de la transformation des données

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 92

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Les composants dénommés « Datawarehouse » représentent la connexion à notre entrepôt de données (PostgreSQL). Une fois la connexion déposée dans le « job » comme dans la figure (figure 65), une configuration de cet élément permet d'indiquer le nom de la dimension (ou du Fait) et de définir certaines politiques de chargement telles que l'action à exécuter lors du chargement (suppression de le table existante ou mise à jour, ou encore simple création) ainsi que de renseigner les paramètres de connexion à l'entrepôt de données.

La transformation des données en question se passe sous le composant de mappage « tMap » situé au centre du « job » préalablement présenté. A cette étape, il s'agit notamment d'adapter le schéma des tables sources par rapport au schéma des dimensions conçues plus haut. Sous TOS, il est possible, à l'aide de bout de code java, d'ajouter des fonctions (somme, moyenne, concaténation, . . .) lors de la transformation. Voici un exemple illustratif de transformation de données sous TOS toujours pour les mêmes dimensions.

Figure 65: Transformation des données

L'opération de chargement ne consiste qu'en l'exécution du « job » une fois la transformation effectuée.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 93

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

1.2 Choix des autres outils

1.2.1 Outils de modélisation

PowerAMC est un logiciel de conception créé par la société SDP, qui permet de modéliser les traitements informatiques et leurs bases de données associées. Créé par SDP sous le nom AMC Designor, racheté par Powersoft, ce logiciel est produit par Sybase depuis le rachat par cet éditeur en 1995. Hors de France, la version internationale est commercialisée par Sybase sous la

marque PowerDesigner. PowerAMC permet de réaliser tous les types de modèles

informatiques.

Edraw Max : c'est un logiciel de création de diagrammes techniques d'affaires 2D qui aide à créer des organigrammes, diagrammes de réseau, etc.

1.2.2 Outils d'implémentation

1.2.2.1 Plateformes de développement et IDE pour SIO

WampServer est une plate-forme de développement Web sous Windows pour des applications Web dynamiques à l'aide du serveur Apache2, du langage de scripts PHP et d'une base de données MySQL. Il possède également

PHPMyAdmin pour gérer plus facilement les bases de données.

Le plus populaire et le rapide des plateformes de développement web, WampServer a vite retenu notre attention pour la réalisation de ce projet.

(Site officiel: http://www.wampserver.com)

PHPStorm est un éditeur pour Php, Html et JavaScript, édité par JetBrains. Il contient une correction automatique des erreurs.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 94

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

1.2.2.2 Langages de programmation

PHP (HyperText Preprocessor) est interprété du coté serveur, c'est un langage de scripts principalement utilisé pour produire des pages HTML dynamiques via un serveur HTTP, mais pouvant également fonctionner comme n'importe quel langage de façon locale, en exécutant les programmes en ligne de commande. PHP est un langage disposant depuis la version 5 de

fonctionnalités de modèle objet complètes. En raison de la richesse de sa bibliothèque,

on désigne parfois PHP comme une plate-forme plus qu'un simple langage.

(Site officiel : http://www.php.net)

JavaScript est un langage de programmation de scripts principalement employé dans les pages web interactives mais aussi pour les serveurs. C'est un langage orienté objet à prototype, c'est-à-dire que les bases du langage et ses principales interfaces sont fournies par des objets qui ne sont pas des instances de classes, mais qui sont chacun équipés de constructeurs permettant de créer

leurs propriétés, et notamment une propriété de prototypage qui permet d'en créer des

objets héritiers personnalisés. En outre, les fonctions sont des objets de première classe.

JavaScript est un langage événementiel : le développeur a un contrôle limité sur le flux d'exécution du code, qui est déterminé principalement par les interactions avec l'environnement (activation d'un lien, mouvement de la souris, chargement du contenu du document, ...).

Dans le cadre de notre projet, nous avons choisi JavaScript pour la gestion des évènements dans les interfaces de notre application, le Framework jQuery ne répondant pas entièrement aux besoins appropriés dans leurs détails.

1.2.2.3 Bibliothèques et Framework ? Bibliothèques

Bootstrap est une bibliothèque web qui facilite la création de sites internet et d'applications web. Il contient des modèles HTML et CSS qui permettent de créer rapidement des formulaires, des boutons, des outils de navigation et d'autres éléments dynamiques. Bootstrap est une compilation de plusieurs éléments et fonctions web-design

personnalisables, le tout emballé dans un seul et même outil. Les développeurs qui

utilisent Bootstrap pour la création de leur site web choisissent les éléments qu'ils veulent

utiliser avec la certitude qu'ils ne seront pas incompatibles entre eux. Les éléments

personnalisables compilés dans Bootstrap sont une combinaison de HTML, CSS et

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 95

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

JavaScript. Et grâce à la magie de l'open-source, Bootstrap s'améliore en permanence : de nouvelles fonctions absolument géniales ont été ajoutées comme le 100% mobile responsive ou la très large sélection de plugins jQuery.

Pour des raisons de convivialité, de simplicité et surtout du responsive design qu'il offre, cette bibliothèque a particulièrement retenu notre attention.

(Site officiel Bootstrap : http://www.boostrap.com)

jQuery est une bibliothèque JavaScript libre et multiplateforme créée pour faciliter l'écriture de scripts côté client dans le code HTML des pages web. Il excelle aussi pour des pages web et des éléments dynamiques. JQuery permet aux développeurs de

créer des plugins qui seront compatible avec JavaScript. De ce fait, on peut facilement

réaliser des Widgets très complexes.

En concert avec Bootstrap, JQuery offre un rendu simplement gigantesque en peu de code. En outre, il facilite l'implémentation de code JavaScript. Pour ces raisons nous l'avons intégré dans les outils de développement retenus.

(Site officiel : http://www.jqueryui.com)

	Font Awesome est une police d'écriture qui intègre une bibliothèque rassemblant plus de trois-cents icônes pour le web. Celle-ci vous permettront d'illustrer votre contenu éditorial mais aussi de designer vos pages internet. (Site officiel : https://fortawesome.github.io/Font-Awesome/)
? Framework
		«Symfony est un ensemble de composants PHP, un Framework pour application web, une philosophie, ainsi qu'une communauté -- le tout fonctionnant en harmonie. » d'après la définition fournie sur le site
officiel.

Symfony est un Framework PHP leader pour la création de sites web et d'applications web. Comme tout autre Framework, il nous permet d'adopter un design pattern conventionnel et nous fournit une organisation structurelle de notre code-source. Il fournit en outre quelques méthodes prédéfinies que nous allons directement adapter.

Avec les composants nommés bundles (briques de base), Symfony offre un coup de pousse important dans la programmation avec PHP et simplifie la programmation orienté

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 96

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

objet. Le pattern design permettra une maintenabilité presque parfaite de l'application car il est basé sur le l'architecture MVC. Enfin, la sécurité de l'application est considérablement améliorée lorsque vous la développez avec Symfony.

Séduit par ces avantages énormes, nous avons donc intégré Symfony dans la liste des outils choisis.

(Site officiel : http://www.symfony.com)

1.2.3 Plateformes de développement et IDE pour SID

Eclipse est un IDE (Integrated Developpement Environment ou Environnement de développement intégré en français) libre. Eclipse permet le développement des applications JAVA principalement, mais aussi d'autres langages grâce à l'utilisation des plugins.

Eclipse est une plateforme de développement écrite en java et s'exécute sur la plupart des systèmes d'exploitation. Il est le fruit du travail d'un consortium de grandes entreprises (IBM, Borland, Rational Rose, HP...). Sa performance fait de lui l'un des IDE java les plus populaires. Eclipse intègre pour cela la prise en charge des outils comme Ant, SVN, JUnit...

(Source : general.developpez.com/edi/#eclipse)

Apache Tomecat est un conteneur web libre de servelets et JSP Java EE. Issu du projet Jakarta, c'est un des nombreux projets de l'Apache Software Foundation. Il implémente les spécifications des servelets et JSP du Java Community Process, est paramétrable par des fichiers xml et des propriétés, et inclus des outils pour la configuration et la gestion. Il comporte également un serveur http.

(Source : https://fr.wikipedia.org/wiki/ApacheTomecat)

PostgréSQL est un Système de Gestion de Base de Données Relationnel et Objet (SGBDRO). C'est un outil libre disponible sous les termes d'une licence BSD (Berkeley Software Distribution License). Créé en 1985 par Michael Stonebraker à Berkeley, PostgréSQL est écrit en langage C.

(Source : https://fr.wikipedia.org/wiki/PostgreSQL)

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 97

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

1.2.3.1 Langage de programmation

Pour Java Enterprise Edition (anciennement J2EE), est une spécification pour la technique Java d'Oracle plus particulièrement destinée aux applications d'entreprise. Ces applications sont considérées dans une approche multi-niveaux. Dans ce but, toutes les implémentations de cette spécification contiennent un ensemble d'extension au framework Java standard (JSE, Java Standard Edition) afin de faciliter notamment la création d'applications reparties.

(Source : https://fr.wikipedia.org/wiki/javaEE)

1.2.3.2 Bibliothèques et Frameworks

est un pilote présent dans JSE (Java Standard Edition)

permettant aux applications Java d'interagir avec les bases de données contenues dans le SGBD PostgréSQL.

est un intergiciel permettant aux langages de programmation supportant la technologie ODBC de manipuler les bases de données qui sont mises à disposition par des MySQL. MySQL Connector/ODBC a été créé par MySQL AB.

1.3 Captures d'écran des solutions

Les solutions que nous avons conçues suite à la mise en place de la conception basée sur l'analyse des processus métier sont donc séparées en trois (3) différentes parties : l'application web pour les compagnies d'assurance, l'ETL TOS, et la suite de reporting SpagoBI.

1.3.1 Présentation de l'application opérationnelle

L'application web est constituée d'un portail qui a pour rôle de présenter les offres de services des compagnies d'assurance et des autres ressources liées à la production. En background se trouve la partie d'administration avec un petit tableau de bord et quelques fonctionnalités dont la production des contrats d'assurance.

Le menu principal au portail se présente comme suit :

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Figure 66: Entête de page d'accueil du SIO

La page d'authentification :

Figure 67: Page de connexion du SIO

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 98

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

La page d'accueil de l'administrateur (après connexion) du système est ainsi conçue :

Figure 68: Page d'accuei de l'adminstrateur du SIO

La liste des polices d'assurances est représentée dans la page qui suit avec des boutons pour l'ajout et l'impression de la liste. Aussi on peut cliquer sur le symbole de l'oeil pour ouvrir la police en format .pdf.

Figure 69: Liste des polices d'assurance

Le formulaire d'enregistrement d'une police d'assurance est ainsi conçu :

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 99

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 100

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Figure 70: Formulaire d'enregistrement des polices d'assurance

1.3.2 Présentation des reporting sous SpagoBI 5.0

SpagoBI requiert une authentification après le démarrage du serveur, cette page se présente comme sur la figure suivante:

Figure 71: Page de connexion de SpagoBI

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 101

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Ici se trouvent les jeux de données nécessaires à la création des tableaux, des graphs...

Figure 72: Jeux de données

Nous pouvons alors explorer le menu, ici nous présentons uniquement un tableau de bord sur les données de la dimension client.

Figure 73: Tableau de bord pour observer le comportement des clients

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Un tableau de bord sur le volet « suivi_PoliceAssurance ».

Figure 74: Tableau de bord du fait « suiviPoliceAssurance »

1.3.3 Présentation de la partie mobile (SpagoBIMobileEngine)

A l'aide du moteur de SpagoBI (SpagoBIMobileEngine), nous pouvons visualiser les tableaux de bords sur des plateformes mobiles (smartphones ou tablettes). Ci-dessous se trouvent quelques captures d'écran.

Figure 75: Page de connexion et liste des rapports

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 102

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Figure 76: Histogramme et tableau dans SpagoBIMobileEngine

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 103

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

CHAPITRE 2 : CONDUITE DE PROJET

2.1 Gestion de projet

2.1.1 Diagramme de Gantt prévisionnel

Figure 77: Diagramme de Gantt prévisionnel

2.1.2 Diagramme de Gantt réel

Figure 78: Diagramme de Gantt réel

2.1.3 Intervenants au projet

Ce projet a bénéficié de la contribution de personnes ressource. Le tableau ci-dessous en cite les noms et les responsabilités dans ledit projet.

Noms et prénoms Rôles

Pr. Souleymane KOUSSOUBE

DJYAMO Azore Superviseur

Stagiaire

Tableau 9: Intervenants au projet

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 104

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 105

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

2.1.4 Estimation des charges du projet

Les coûts estimatifs de l'ensemble des composantes du projet, y compris les charges techniques sont estimés à 9 268 891,24 FCFA. Ce montant inclus la rémunération du stagiaire.

Matériels/Logiciels Quantité/Nombre Coût (FCFA)

Ordinateur portable ACER Inspirons 15 Intel® Pentium® CPU 2127U@ 1.90GHz, 8 Go de RAM, 500 GO DD,	1	400 000
Serveur web/application HPE ProLiant BL460c Gen9 Base - Xeon E5 - 2640V3 2. 6 GHz - 32 Go - 0 Go	1	4 144 355,3
Serveur de base de données HPE ProLiant DL380 Gen9 Base - Xeon E5-2620V4 2.1 GHz - 16Go - 0Go	1	2 658 999, 5
Système d'exploitation Windows 10 Professionnel	1	182 745
Connexion Internet	4 mois	100 000
PHP Storm 9.0 (IDE)	1	97 562,4
Power AMC 15.1 (Outils de modélisation)	1	24 482,64
EdrawMax 7.9 (version professionnelle)	1	60 746,4
MySQL 5.6	1	gratuit
SpagoBI	1	gratuit
Talend open studio	1	gratuit
PostgréSQL 9.0	1	gratuit
Tomecat 8.0	1	gratuit
Eclipse Java EE Helios	1	gratuit
Rémunération du stagiaire	4 mois	1 600 000
TOTAL		9 268 891,24

Tableau 10: Charges du projet

(Sources:

https://www.microsoftstore.com/store/msfr/frFR/pdp/productID.320443800?vid=320444900&gclid= CjwKEAiAwfzDBRCRmJe7z7h8yQSJAC4corOfWFtfuaJ9YPFm9FlFBk8gXHzjdst7drLS6NvqHgizRoCm17w wcB&tduid=(7ff122a427e6aa282c4ca2c9955b8783)(213961)(2157774)(1-5254--PCwtZ285bnZ1NzIjI251bj4/)(1c15581939331700276285kwd-102955757109;

https://www.jetbrains.com/phpstorm/buy/;

http://impulsoexterior.net/store/Sybase-PowerAMC-15-1-French.html; https://www.edrawsoft.com/fr/EDrawMax.php; https://rapportsalzman.blogspot.com/2015/03/estimer-correctement-le-cout-des.html ; http://www.cherchons.com/dossier/serveur-de-base-de-donnees.html)

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 106

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

2.2 Evaluations et perspectives

Au terme de nos recherches, nous allons retracer les apports, les difficultés et indiquer les tâches qui pourront être nos prochains défis.

2.2.1 Apports

Le décisionnel en général est un domaine de l'informatique prometteur. Aussi, nous avons été confrontés à des défis intéressants tels nous plonger dans un contexte juridique (l'assurance), mettre en oeuvre des technologies complexes et surtout mettre en place une méthodologie de conception décisionnelle réaliste, basée sur l'analyse des processus métiers... Ces défis ont contribué à renforcer nos capacités, ils ont apporté un bénéfice d'expérience.

2.2.2 Difficultés

Les difficultés que nous avons relevées de cette expérience sont :

? Un accès à internet qui n'a pas favorisé l'avancée des recherches ;

? L'étude et l'interprétation du code CIMA ;

? La communauté des concepteurs des outils open source que nous avons mis en oeuvre n'est pas encore vaste ;

? Nous avons en outre cruellement manqué de ressource experte dans le domaine des assurances pour la validation de nos processus métiers, ce qui a fortement limité nos interview à quelques personnes ayant une connaissance générale de la chose mais qui exercent toutefois dans le domaine des assurances. L'interprétation du code CIMA elle aussi, a constitué un problème important compte tenu de la même difficulté.

2.2.3 Perspectives

La réalisation du présent projet s'est attaché à la mise en oeuvre véritable de la démarche basée sur l'analyse des processus métiers. A court terme, nous projetons de creuser dans le sens de l'analyse sur chaque branche décisionnelle de la description des processus métiers à fin de fournir d'avantage des éléments d'analyse aux décideurs. Sur le moyen et le long terme, nous souhaitons que l'étude et la mise en place effective de cette démarche d'analyse et de conception décisionnelle soit approfondie et qu'elle se détache de toute dépendance des canevas énumérés par les anciennes méthodes (Bottom-up, Top-down,...) et que, en conclusion, elle soit nommée et éventuellement publiée comme étant une démarche proposée par le LAIMA. Pour ce faire, l'étude doit être reprise en basant les recherches sur la théorie sans vouloir fournir de preuve en concevant un système décisionnel à l'appui. Le document final doit pouvoir servir de livre de conception décisionnelle basée sur l'analyse des processus métiers. Ceci étant, le présent document doit être considéré comme la preuve de la valeur de cette démarche et de document d'étude de faisabilité en quelque sorte.

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Conclusion

La dernière partie de notre travail nous a permis d'effectuer les choix techniques nécessaires à l'implémentation de nos solutions. Principalement, le choix des outils décisionnels, le choix des IDE, SGBD.... Nous avons aussi, en deuxième chapitre de cette partie évoqué de la planification du projet, des acteurs du projet et des charges liées à la mise en place de telles solutions. En dernier lieu, nous n'avons pas manqué de parler des difficultés rencontrées, des profits tirés du projet et des perspectives.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 107

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 108

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

CONCLUSION GENERALE

L'introduction d'un complément de démarche conceptuelle des systèmes d'information décisionnels était notre premier challenge tout au long de ce projet. Notre méthodologie était ainsi basée sur l'analyse des processus métiers. Mettre en place un environnement Décisionnel, était une mission visant à pratiquer et à valoriser la méthodologie que nous avons présentée dans ce mémoire. Nous avons toutefois pris en compte beaucoup d'éléments des méthodologies de conception dimensionnelle existantes pour mener à bien notre étude. Les atouts de notre démarche conceptuelle sont précisément la visibilité sur les éléments rentrant dans le cadre d'une conception dimensionnelle. Elle renferme aussi l'avantage d'élargir le champ d'analyse sur des éléments qui peuvent ne pas paraitre dans l'expression des besoins par les utilisateurs.

Nous avons en outre présenté de façon méthodique les démarches de mise en oeuvre de nos solutions. Un SID construit à partir de notre méthodologie et un SIO servant de source de notre entrepôt de données. Pour réussir à accomplir cette tâche, nous avons, pour le SIO fait recours au langage de modélisation UML et au processus de développement logiciel 2TUP. Notre méthodologie de conception basée sur l'analyse des processus métiers accompagnée de certaines démarches existantes nous ont servi à réaliser notre SID. De la conception à la mise en oeuvre, nous avons présenté l'ensemble des architectures de nos solutions, les outils et technologies de mise en oeuvre, la mise en oeuvre elle-même et la conduite de projet. Nous avons également dans la mise en oeuvre, fait une présentation de nos solutions à travers des captures d'écran.

Par ailleurs, à la fin de ce travail de longue haleine, nous sommes sorti muris par la plupart des challenges qui ont, de façon répétitive, constitué des freins à l'avancement du projet. Savoir mettre en oeuvre un SID implique savoir concevoir un Data Warehouse et d'y rattacher des outils de reporting. Ceci est définitivement pour nous un gain de connaissance immense.

Enfin, ne dit-on pas souvent qu'aucune entreprise de la main et de l'esprit de l'Homme n'est jamais parfaitement accomplie ? Pour cette raison, le contenu de ce mémoire reste ouvert à toutes critiques et tous apports.

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

BIBLIOGRAPHIE

Ouvrages

[1] Kimball R., « The data warehouse toolkit: practical techniques for building dimensional data warehouses », John Wiley & Sons, Inc., New York, NY, USA, 1996

[2] Kimball, R., Margy R., « The Data Warehouse Toolkit » Second Edition, The Complete Guide to Dimensional Modeling, Wiley Computer Publishing, John Wiley & Sons, Inc, 2002.

[3] Ralph Kimball, Laura Reeves, « Concevoir et déployer un data warehouse Guide de conduite de projet », Ed Eyrolles 2005.

[4] William H. Inmon, « Building the Data Warehouse » Fourth Edition, Wiley Publishing & Inc 2005.

[5] Pascal Roques, Franck Vallée, « UML 2 en action », 4è^me édition (Eyrolles), ISBN: 9782-21212104-9, parution 2007.

[6] Pascal Roques, « UML 2 par la pratique », 5è^me édition, ÉDITIONS EYROLLES 61, bd Saint-Germain 75240 Paris Cedex 05, parution 2006.

[7] Equipe Conseil Softeam, « Le Guide Pratique des Processus Métiers », Version : 1.0.

[8] Lexique des termes juridiques 2012.

Mémoires et thèses

[9] « Conception et réalisation d'un Data Warehouse pour la mise en place d'un système décisionnel » par FILALI ABDERRAHMANE et KEDJNANE SOFIAN, Ecole Nationale Supérieure d'Informatique, Algérie, promo 2009/2010.

[10] Estella ANNONI, « Eléments méthodologiques pour le développement des systèmes décisionnels dans un contexte de réutilisation », thèse de doctorat à l'université de Toulouse 1, 16 juillet 2007.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 109

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 110

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

WEBOGRAPHIE

[1] Inmon, B. (1997). The data warehouse budget.

http://www.dmreview.com/articlesub.cfm?articleId=1315, DM Review Magazine Publisher.

[2] IDC (2004e). Les clés d'une politique décisionnelle réussies. deuxième édition du décisionnel, idc, paris, 28 septembre 2004.

http://www.artesi.artesi-idf.com/public/article.tpl?id=7717

[3] IDG (2005). Entreprises et d'décisionnel : Etat des lieux, objectifs et perspectives. http://www.decisio.info/Entreprises-et-decisionnel.html,

Les résultats de l'enquête sont indiqués dans le document http://www.decisio.info/IMG/pdf/EnqueteCIOSAS230605.pdf

[4] www.cima-afrique.net: Code CIMA

[5] http://grim.developpez.com/cours/businessintelligence/concepts/conception-datawarehouse/: Conception d'un entrepôt de données (Data Warehouse) par Yazid Grim(Business Intelligen(ce))

[6] https://fr.wikipedia.org/wiki/SpagoBI: Présentation de SpagoBI

[7] www.cima-afrique.net: Code CIMA

[8] http://www.wikifin.be/fr/thematiques/assurer/questions-cle/calcul-de-lindemnite

[9] http://www.actuassur.com/dossiers/assurances.php

[10] http://projetspagobi.free.fr/docs/rapportsem2.pdf: SpagoBI

[11] [e-mail]: architecture technique

[12] [e-mail] , Rémi LEBLOND : architecture technique

[13] http://www.info.univ-angers.fr/~gh/internet/ntiers.pdf architecture technique

[14] http://www.assurance-site.fr/ : Site web d'assurance en France

[15] https://business-

intelligence.developpez.com/tutoriels/DWHmultidimensionnel/?page=theorieE

[16] Yazid Grim, http://grim.developpez.com/articles/concepts/etl/, « ETL, les questions à se poser ». (consulté le 12/05/2017).

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 111

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

ANNEXES

QUELQUES DISPOSITIONS DU CODE CIMA UTILES A LA MODELISATION LIVRE I : LE CONTRAT

TITRE I : RÈGLES COMMUNES AUX ASSURANCES DE DOMMAGES NON MARITIMES ET AUX ASSURANCES DE PERSONNES

CHAPITRE PREMIER : DISPOSITIONS GÉNÉRALES

Article 5

Mandat - Assurance pour compte

L'assurance peut être contractée en vertu d'un mandat général ou spécial ou même sans mandat, pour le compte d'une personne déterminée. Dans ce dernier cas, l'assurance profite à la personne pour le compte de laquelle elle a été conclue, alors même que la ratification n'aurait lieu qu'après le sinistre.

L'assurance peut aussi être contractée pour le compte de qui il appartiendra.

La clause vaut tant comme assurance au profit du souscripteur du contrat, que comme stipulation pour autrui au profit du bénéficiaire connu ou éventuel de ladite clause.

Le souscripteur d'une assurance contractée pour le compte de qui il appartiendra est seul tenu au paiement de la prime envers l'assureur ; les exceptions que l'assureur pourrait lui opposer sont également opposables au bénéficiaire du contrat, quel qu'il soit.

Article 6

Proposition d'assurance - Modification du contrat

(Modifié par Décision du Conseil des Ministres du 22 avril 1999)

La proposition d'assurance n'engage ni l'assuré, ni l'assureur ; seule la police ou la note de couverture constate leur engagement réciproque.

L'assureur est tenu avant la conclusion du contrat de fournir une fiche d'information sur le prix, les garanties et les exclusions.

Est considérée comme acceptée la proposition faite par lettre recommandée avec accusé de réception, par lettre contresignée ou par tout autre moyen faisant foi de la date de réception, de prolonger ou de modifier un contrat, ou de remettre en vigueur un contrat suspendu, si l'assureur ne refuse pas dans les quinze jours après qu'elle lui soit parvenue.

Les dispositions de l'alinéa précédent ne sont pas applicables aux assurances sur la vie.

Article 9

Transmission de la police d'assurance

La police d'assurance peut être à personne dénommée, à ordre ou au porteur. Les polices à ordre se transmettent par voie d'endossement, même en blanc. La police d'assurance sur la vie peut être à ordre. Elle ne peut être au porteur.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 112

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

L'endossement d'une police d'assurance sur la vie à ordre doit, à peine de nullité, être daté, indiquer le nom du bénéficiaire de l'endossement et être signé de l'endosseur.

CHAPITRE III : OBLIGATIONS DE L'ASSUREUR ET DE L'ASSURÉ

Article 13-1

Chèques et effets impayés

(Ajouté par Décision du Conseil des Ministres du 11 avril 2011)

Lorsqu'un chèque ou un effet remis en paiement de la prime revient impayé, l'assuré est mis en demeure de régulariser le paiement dans un délai de huit (8) jours ouvrés à compter de la réception de l'acte ou de la lettre de mise en demeure. A l'expiration de ce délai, si la régularisation n'est pas effectuée, le contrat est résilié de plein droit.

La portion de prime courue reste acquise à l'assureur, sans préjudice des éventuels frais de poursuite et de recouvrement.

Article 13-2

Coassurance

Dans le cas de coassurance à quittance unique, l'apériteur doit reverser les parts de prime dues aux autres coassureurs dans un délai de quinze (15) jours à compter de la réception du paiement de la prime ou portion de prime.

Les primes dues par l'apériteur et non reversées aux autres coassureurs produisent intérêt de plein droit au double du taux d'escompte dans la limite du taux de l'usure à compter de l'expiration du délai de reversement stipulé à l'alinéa précédent.

Article 14 : Avis d'échéance

(Modifié par Décision du Conseil des Ministres du 11 avril 2011)

Pour les contrats à tacite reconduction, à chaque échéance de prime, l'assureur est tenu d'aviser à la dernière adresse connue, au moins quarante-cinq (45) jours à l'avance, l'assuré, ou la personne chargée du paiement des primes, de la date d'échéance et du montant dont il est redevable.

Cet avis matérialisé par une lettre avec accusé de réception ou décharge devra rappeler que le contrat sera résilié de plein droit si la prime de renouvellement n'est pas payée dans les délais prévus à l'article 13.

Article 21 : Résiliation

Alinéa 2 : Toutefois, l'assuré a le droit de résilier le contrat à l'expiration d'un délai d'un an, en envoyant une lettre recommandée à l'assureur au moins deux (2) mois avant la date d'échéance. Ce droit appartient, dans les mêmes conditions, à l'assureur.

Les dispositions du présent article ne sont pas applicables aux assurances sur la vie.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 113

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Article 24 : Durée du contrat

La durée du contrat doit être mentionnée en caractères très apparents dans la police. La police doit également mentionner que la durée de la tacite reconduction ne peut en aucun cas être supérieure à une année.

A défaut de cette mention, l'une des parties peut, nonobstant toute clause contraire, résilier le contrat sans indemnité, chaque année, à la date anniversaire de sa prise d'effet moyennant un préavis d'un mois au moins.

Article 25 : Résiliation pour modification ou cessation du risque En cas de survenance d'un des événements suivants :

? changement de domicile ;

? changement de profession ;

? retraite professionnelle ou cessation définitive d'activité professionnelle ; ? changement de situation ou de régime matrimonial ;

Le contrat d'assurance peut être résilié par chacune des parties lorsqu'il a pour objet la garantie de risques en relation directe avec la situation antérieure et qui ne se retrouvent pas dans la situation nouvelle.

La résiliation du contrat ne peut intervenir que dans les trois mois suivant la date de l'événement.

Elle prend effet un mois après que l'autre partie au contrat en a reçu notification.

L'assureur doit rembourser à l'assuré la portion de prime ou de cotisation correspondant à la période pendant laquelle le risque n'a pas couru, période calculée à compter de la date d'effet de la résiliation.

Il ne peut être prévu le paiement d'une indemnité à l'assureur dans les cas de résiliation susmentionnés.

Les dispositions du présent article ne sont pas applicables aux assurances sur la vie. TITRE II : RÈGLES RELATIVES AUX ASSURANCES DE DOMMAGES NON MARITIMES CHAPITRE PREMIER

DISPOSITIONS GÉNÉRALES

Article 31 : Principe indemnitaire

L'assurance relative aux biens est un contrat d'indemnité ; l'indemnité due par l'assureur à l'assuré ne peut pas dépasser le montant de la valeur de la chose assurée au moment du sinistre.

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 114

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Il peut être stipulé que l'assuré reste obligatoirement son propre assureur pour une somme, ou une quotité déterminée, ou qu'il supporte une déduction fixée d'avance sur l'indemnité du sinistre.

Article 34 : Assurances cumulatives

Alinéa 1 : Celui qui est assuré auprès de plusieurs assureurs par plusieurs polices, pour un même intérêt, contre un même risque, doit donner immédiatement à chaque assureur connaissance des autres assureurs.

Alinéa 5 : Dans les rapports entre assureurs, la contribution de chacun d'eux est déterminée en appliquant au montant du dommage le rapport existant entre l'indemnité qu'il aurait versée s'il avait été seul et le montant cumulé des indemnités qui auraient été à la charge de chaque assureur s'il avait été seul.

Article 40 : Décès de l'assuré et aliénation de la chose assurée

En cas de décès de l'assuré ou d'aliénation de la chose assurée, l'assurance continue de plein droit au profit de l'héritier ou de l'acquéreur, à charge pour celui-ci d'exécuter toutes les obligations dont l'assuré était tenu vis-à-vis de l'assureur en vertu du contrat.

Il est loisible, toutefois, soit à l'assureur, soit à l'héritier ou à l'acquéreur de résilier le contrat.

L'assureur peut résilier le contrat dans un délai de trois mois à partir du jour où l'attributaire définitif des objets assurés a demandé le transfert de la police à son nom.

En cas d'aliénation de la chose assurée, celui qui aliène reste tenu vis-à-vis de l'assureur au paiement des primes échues, mais il est libéré, même comme garant des primes à échoir, à partir du moment où il a informé l'assureur de l'aliénation par lettre recommandée.

Lorsqu'il y a plusieurs héritiers ou plusieurs acquéreurs, si l'assurance continue, ils sont tenus solidairement du paiement des primes.

Il ne peut être prévu le paiement d'une indemnité à l'assureur dans les cas de résiliation susmentionnés.

Les dispositions du présent article ne sont pas applicables au cas d'aliénation d'un véhicule terrestre à moteur ou de navires et bateaux de plaisance.

Article 41 : Aliénation des véhicules terrestres à moteur (Modifié par Décision du Conseil des Ministres du 20 avril 1995)

En cas d'aliénation d'un véhicule terrestre à moteur ou de ses remorques ou semi-remorques, et seulement en ce qui concerne le véhicule aliéné, le contrat d'assurance est

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 115

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

suspendu de plein droit à partir du cinquième jour de l'aliénation à vingt-quatre heures. Il peut être résilié par chacune des parties moyennant préavis de 10 jours.

A défaut de remise en vigueur du contrat par accord des parties ou de résiliation par l'une d'elles, la résiliation intervient de plein droit à l'expiration d'un délai de six mois à compter de l'aliénation.

L'assureur est tenu au remboursement du prorata de prime correspondant à la période allant de la date de cette résiliation à la date d'échéance.

L'assuré doit informer l'assureur, par lettre recommandée ou par tout autre moyen prévu dans la police, de la date d'aliénation.

Il ne peut être prévu le paiement d'une indemnité à l'assureur dans les cas de résiliation susmentionnés.

L'ensemble des dispositions du présent article est applicable en cas d'aliénation de navires ou de bateaux de plaisance quel que soit le mode de déplacement ou de propulsion utilisé.

Article 64 : Mentions du titre de capitalisation ou du contrat d'assurance vie (Modifié par Décision du Conseil des Ministres du 16 avril 2009).

Le contrat d'assurance sur la vie doit indiquer, outre les énonciations mentionnées à l'article 8 :

1) les noms, prénoms et dates de naissance du ou des assuré(s) ;

2) l'événement ou le terme duquel dépend l'exigibilité du capital ou de la rente garantis ;

3) les délais et les modalités de règlement du capital ou de la rente garantis ;

4) la liste des documents à réclamer au bénéficiaire par l'assureur pour le paiement des prestations.

Le contrat ou titre de capitalisation doit indiquer :

1) le montant du capital remboursable à l'échéance et le montant à toute époque du capital remboursable par anticipation ;

2) le montant et la date d'exigibilité des versements ;

3) la date de prise d'effet ainsi que la date d'échéance du contrat ;

4) la valeur de rachat garantie du contrat d'année en année pendant au moins 8 ans ;

5) les conditions dans lesquelles l'entreprise peut consentir des avances ;

6) les conditions de déchéance opposables aux souscripteurs pour retard dans les versements, sans que ces déchéances puissent avoir effet avant un délai d'un mois à dater du jour de l'échéance ; ce délai ne court, si le contrat est nominatif, qu'à partir d'une mise en demeure par lettre recommandée ;

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 116

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

7) la substitution de plein droit de tous les héritiers des titulaires de contrats nominatifs auxdits titulaires, ainsi que l'interdiction pour l'entreprise de stipuler à leur décès aucun versement supplémentaire ou aucune retenue spéciale ;

8) la limitation des sommes à prélever pour frais de gestion en proportion des versements ;

9) le numéro ou la combinaison de lettres dont la désignation par le sort peut entraîner le remboursement anticipé à la suite de tirages ;

10) le nombre des tirages par an, ainsi que leurs dates ;

11) le mécanisme des tirages et des conditions de publicité dans lesquelles ils s'effectuent ;

12) les ressources qui alimentent les tirages lorsqu'ils ne sont pas garantis, la proportion des titres remboursés par anticipation avec la spécification de la méthode employée pour la désignation des titres par le sort ;

13) la liste des documents à réclamer au bénéficiaire par l'assureur pour le paiement des prestations.

Article 73 : Action en paiement des primes afférentes aux contrats d'assurance vie ou de capitalisation

(Modifié par Décision du Conseil des Ministres du 16 avril 2009)

L'assureur n'a pas d'action pour exiger le paiement des primes afférentes aux contrats d'assurance vie ou de capitalisation.

Lorsqu'une prime ou une fraction de prime n'est pas payée dans les dix (10) jours de son échéance, l'assureur adresse au contractant une lettre recommandée, par laquelle il l'informe qu'à l'expiration d'un délai de quarante (40) jours à dater de l'envoi de cette lettre, le défaut de paiement entraîne soit la résiliation du contrat en cas d'inexistence ou d'insuffisance de la valeur de rachat, soit la réduction du contrat.

L'envoi de la lettre recommandée par l'assureur rend la prime portable dans tous les cas. La procédure édictée au deuxième alinéa peut se faire également par lettre contresignée. Article 75 : Information de l'assuré

TITRE I : L'ASSURANCE DES VEHICULES TERRESTRES A MOTEUR ET DE LEURS REMORQUES ET SEMI-REMORQUES

CHAPITRE IV - Indemnité des victimes

LIVRE II LES ASSURANCES OBLIGATOIRES

TITRE I L'ASSURANCE DES VÉHICULES TERRESTRES À MOTEUR ET DE LEURS REMORQUES ET SEMI-REMORQUES

Article 205 Événements garantis

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 117

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

L'obligation d'assurance s'applique à la réparation des dommages corporels ou matériels résultant :

1°) des accidents, incendies ou explosions causés par le véhicule, les accessoires et produits servant à son utilisation, les objets et substances qu'il transporte ;

2°) de la chute de ces accessoires, objets, substances ou produits.

CHAPITRE III CONTRÔLE DE L'OBLIGATION D'ASSURANCE Article 213 Attestation d'assurance avec certificat détachable

Tout conducteur d'un véhicule mentionné à l'article 200 doit, dans les conditions prévues aux articles de la présente section, être en mesure de présenter un document faisant présumer que l'obligation d'assurance a été satisfaite.

Cette présomption résulte de la production, aux fonctionnaires ou agents chargés de constater les infractions à la police de la circulation, d'un des documents dont les conditions d'établissement et de validité sont fixées par le présent Code.

Ces documents se composent d'une attestation d'assurance conservée par le propriétaire du véhicule et, détachable de cette attestation, d'un certificat d'assurance obligatoirement apposé sur le véhicule automoteur.

A défaut de ces documents, la justification est fournie aux autorités judiciaires par tous moyens. Les documents prévus au présent article n'impliquent pas une obligation de garantie de la part de l'assureur.

Article 216

Délivrance des documents justificatifs : attestation provisoire

Le document justificatif mentionné à l'article 214 est délivré dans un délai maximal de quinze jours à compter de la souscription du contrat et renouvelé lors du paiement des primes ou portions de primes subséquentes.

Faute d'établissement immédiat de ce document, l'entreprise d'assurance délivre sans frais, à la souscription du contrat ou en cours de contrat, une attestation provisoire qui établit la présomption d'assurance pendant la période qu'elle détermine, dont la durée ne peut excéder un mois.

Cette attestation, qui est éventuellement établie en autant d'exemplaires que le document justificatif correspondant, doit mentionner :

- la dénomination et l'adresse de l'entreprise d'assurance ; - les noms, prénoms et adresse du souscripteur du contrat ;

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 118

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

- la nature et le type du véhicule ou, en ce qui concerne les contrats d'assurance mentionnés à l'article 201, la profession du souscripteur ;

- la période pendant laquelle elle est valable.

Article 231

Délai de présentation de l'offre

(Modifié par Décision du Conseil des Ministres du 24 avril 1999)

Indépendamment de la réclamation que peut faire la victime, l'assureur qui garantit la responsabilité civile du fait d'un véhicule terrestre à moteur est tenu de présenter dans un délai maximum de douze mois à compter de l'accident une offre d'indemnité à la victime qui a subi une atteinte à sa personne. En cas de décès de la victime, l'offre est faite à ses ayants droit tels qu'ils sont définis aux articles 265 et 266 dans les huit mois du décès.

L'offre comprend tous les éléments indemnisables du préjudice, y compris les éléments relatifs aux dommages aux biens lorsqu'ils n'ont pas fait l'objet d'un règlement préalable.

Elle peut avoir un caractère provisionnel lorsque l'assureur n'a pas, dans les six mois de l'accident, été informé de la consolidation de l'état de la victime. L'offre définitive d'indemnisation doit alors être faite dans un délai de six mois suivant la date à laquelle l'assureur a été informé de cette consolidation.

En cas de pluralité de véhicules, et s'il y a plusieurs assureurs, l'offre est faite par l'assureur désigné dans la convention d'indemnisation pour compte d'autrui visée aux articles 267 et suivants.

Les dispositions qui précèdent ne sont pas applicables aux victimes à qui l'accident n'a occasionné que des dommages aux biens (véhicules et objets transportés).

Article 233

Offre tardive : pénalité

Lorsque l'offre n'a pas été faite dans les délais impartis à l'article 231, le montant de l'indemnité produit intérêt de plein droit au double du taux de l'escompte dans la limite du taux de l'usure à compter de l'expiration du délai et jusqu'au jour de l'offre devenue définitive. Cette pénalité est réduite, ou annulée, en raison de circonstances non imputables à l'assureur et notamment lorsqu'il ne dispose pas de l'adresse de la victime.

Article 239

Règlement contentieux : délais et modalités

(Modifié par Décision du Conseil des Ministres du 24 avril 1999)

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 119

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

Lorsque l'assureur qui garantit la responsabilité civile et la victime ne sont pas parvenus à un accord dans le délai prévu à l'article 231, l'indemnité due par l'assureur est calculée suivant les modalités fixées aux articles 258 et suivants.

Le litige entre l'assureur et la victime ne peut être porté devant l'autorité judiciaire qu'à l'expiration du délai de l'article 231.

Le juge fixe l'indemnité suivant les modalités fixées aux articles 258 et suivants. Article 247

Retard dans la déclaration de l'accident à l'assureur

Lorsque l'assureur qui garantit la responsabilité civile du fait d'un véhicule à moteur n'a pas été avisé de l'accident de la circulation dans le mois de l'accident, le délai prévu au premier alinéa de l'article 231 pour présenter une offre d'indemnité est suspendu à l'expiration du délai d'un mois jusqu'à la réception par l'assureur de cet avis.

Article 252 bis

Divergences sur les conclusions de l'expertise

S'il y a divergence sur les conclusions de l'examen médical, l'expert de l'assureur et l'expert désigné par la victime désignent un tiers expert d'un commun accord. L'avis de ce dernier s'impose. Le délai imparti à l'assureur pour présenter l'offre d'indemnité est prorogé d'un mois.

Article 253

Délais supplémentaires en cas de résidence à l'étranger

Lorsque la victime réside à l'étranger, les délais qui lui sont impartis en vertu des articles 249 et 250 ci-dessus sont augmentés d'un mois. Le délai imparti à l'assureur pour présenter l'offre d'indemnité est prorogé de la même durée.

Article 258

Frais

(Modifié par Décision du Conseil des Ministres du 24 avril 1999)

Les frais de toute nature peuvent être, soit remboursés à la victime sur présentation des pièces justificatives, soit pris en charge directement par l'assureur du véhicule ayant causé l'accident.

Toutefois, leurs coûts ne sauraient excéder deux fois le tarif le plus élevé des hôpitaux publics du pays de l'accident et en cas d'évacuation sanitaire justifiée par expertise, une fois le tarif le plus élevé des hôpitaux publics du pays d'accueil.

Conception des systèmes décisionnels basée sur l'analyse des processus métiers

À la demande de la victime, l'assureur du véhicule ayant causé l'accident ou du véhicule dans lequel la victime était transportée est tenu de délivrer, dans la limite des tarifs prévus ci-dessus, une lettre de garantie pour la prise en charge des frais médicaux.

Les frais futurs raisonnables et indispensables au maintien de l'état de santé de la victime postérieurement à la consolidation font l'objet d'une évaluation forfaitaire après avoir recueilli l'avis d'un expert.

(Réf code CIMA)

DJYAMO Azore - Mémoire de fin de cycle Master CSI/IAI-siège/2015-2016 Page | 120