Université de Tunis
Institut Supérieur de Gestion de Tunis
Projet de Fin d’Etudes En vue de l’obtention du Diplôme de : Licence Appliquée en Informatique Décisionnelle
CONCEPTION ET MISE EN PLACE D’UNE SOLUTION DÉCISIONNELLE POUR LE SUIVI DE L’ACTIVITÉ DE LA STAR
Organisme d’accueil :
Société Tunisienne d’Assurances et de Réassurances
Élaboré par : Souhir KASRAOUI Jihene RIAHI
Encadrants : Dr. Lilia REJEB Mr. Brahim BEN HADJ ABDALLAH
ANNÉE UNIVERSITAIRE : 2017-2018
Dédicace
A ma mère , ma raison d’être, la prunelle de mes yeux et qui éclaire mon chemin.
A mon père, en signe d’amour, de reconnaissance et de gratitude pour tous les soutiens et les
sacrifices dont il a fait preuve à mon égard.
Un spécial dédicace à mes chères soeurs avec tous mes sentiments de respect et d’amour pour
leurs encouragements et leurs soutiens.
A mon binôme Souhir Kasraoui. Merci pour ton soutien. En témoignage de l’amitié sincère
qui nous a unit.
A tous mes amis, en témoignage de l’amitié sincère qui nous a liées et des bons moments
passés ensemble.
A tous les gens qui ont cru en moi et qui me donnent l’envie d’aller en avant. Je vous remercie
tous, votre soutien et vos encouragements me donnent la force de continuer.
Que dieu vous garde.
ii
Dédicace
À ma chère famille qui n’a manqué aucun moment difficile pour me montrer son amour et son soutien.
À mon binôme Jihene Riahi pour la patience et l’encouragement qu’elle m’a accordé.
À tous ceux qui m’ont soutenu, encouragé, aidé et apprécié mon effort.
À tous ceux qui comptent pour moi et je compte pour eux.
Je vous dédie ce modeste travail dans l’espoir d’être à la hauteur de la confiance que vous m’avez accordé.
iii
Remerciements
Nous tenons à exprimer notre remerciement et notre gratitude à Mme. Lilia Rejeb pour son encadrement, ses conseils efficaces, les nouvelles méthodes de travail qu’elle nous a appris et
qui nous ont été bien bénéfiques et pour le temps qu’elle nous a consacré.
Nous exprimons également notre reconnaissance et notre appréciation à M. Brahim Ben Hadj Abdallah pour son accompagnement, son encouragement et pour tout l’effort et le temps
qu’il nous a fourni afin de mener à bien ce projet.
Nous adressons notre gratitude à toute l’équipe de la direction informatique de nous avoir, aidés à acquérir une meilleure compréhension du mode de fonctionnement de l’organisme ainsi pour la belle ambiance et la bonne humeur qu’elle nous a offert pendant toute la durée
du stage.
Nous remercions toute personne, qui par son aide précieuse, nous a permis à bien réaliser ce
travail.
Nos remerciements vont aussi à tous les enseignants et administrateurs de l’Institut Supérieur
de Gestion pour avoir contribué à nous assurer une formation de qualité.
Enfin,nous avons l’honneur d’exprimer notre remerciement aux membres de jury de bien
vouloir évaluer notre travail.
iv
Table des matières
Introduction
2
.
.
.
.
1 Cadre générale du projet .
Introduction .
1.3 Analyse de l’existant
1.1 . 1.2 Présentation de l’organisme d’accueil Présentation . .
1.2.1 1.2.2 Organigramme . . 1.3.1 Étude de l’existant 1.3.2 Critique de l’existant
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Présentation de la solution proposée . . . . . . . . . . . . . . . . . . . . . . . 1.5 Méthode de gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Choix de la méthode . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 1.5.3
4 4 4 4 5 5 5 6 7 8 8 Principe de scrum BI . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Scrum appliquée à un projet informatique . . . . . . . . . . . . . . . . 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 Conclusion . .
. .
.
.
.
.
.
.
.
.
.
.
Introduction .
2 Sprint 0 : Analyse et spécification des besoins . .
12 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2 Spécification des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.1 Exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . 12 . . . . . . . . . . . . . . . . . . . . . . 13 2.2.2 Exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 . . . . . . . . . . . . . . 15 . . . . . . . . . . . . . . . . . . 15 . . . . . . . . . . . . . . . . . . . . . . . 15 Schéma global de la conception . . . . . . . . . . . . . . . . . . . . . 17 2.6 Choix des outils Business Intelligence . . . . . . . . . . . . . . . . . . . . . . 18 2.6.1 Étude comparative des outils ETL . . . . . . . . . . . . . . . . . . . . 18 2.6.2 Étude comparative des outils de Reporting . . . . . . . . . . . . . . . . 19 . . . . . . . . . . . . . . . . . . . . . . . . 20 2.6.3 Architecture de Power BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Backlog de produit . 2.4 Étude approximative des indicateurs de performance 2.5 Conception globale de l’entrepôt de données 2.5.1 Étude du modèle conceptuel 2.5.2
2.7 Conclusion . .
. .
.
.
.
v
.
.
.
Publicité
.
.
Introduction .
3 Sprint 1 : Création data mart "Production" .
22 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2 Backlog de sprint du Data mart Production . . . . . . . . . . . . . . . . . . . . 22 3.3 Conception détaillée du Data mart "Production" . . . . . . . . . . . . . . . . . 23 3.3.1 Table de fait Production . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3.2 Dimensions dégagées . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Schéma conceptuel du data mart "Production" . . . . . . . . . . . . . . 24 3.3.3 3.4 Définition des indicateurs de performance . . . . . . . . . . . . . . . . . . . . 24 3.5 Phase d’intégration de données : ETL . . . . . . . . . . . . . . . . . . . . . . 25 3.5.1 Extraction des données . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.5.2 Transformation des données . . . . . . . . . . . . . . . . . . . . . . . 31 3.5.3 Chargement des données . . . . . . . . . . . . . . . . . . . . . . . . . 32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.6.1 Choix des graphiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 . . . . . . . . . . . . . . . . . . . . 40 3.6.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Présentation de quelques rapports .
3.6 Phase de Reporting .
3.7 Conclusion . .
. .
.
.
.
.
4 Sprint 2 : Création data mart "Sinistre"
.
.
.
.
.
.
Introduction .
Schéma conceptuel du data mart "Sinistre"
42 4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.2 Backlog de sprint du Data mart "Sinistre" . . . . . . . . . . . . . . . . . . . . 42 4.3 Conception détaillée data mart "Sinistre" . . . . . . . . . . . . . . . . . . . . . 43 4.3.1 Table de fait Sinistre . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3.2 Dimensions dégagées . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 . . . . . . . . . . . . . . . 44 4.3.3 4.4 Définition des indicateurs de performance . . . . . . . . . . . . . . . . . . . . 45 4.5 Phase d’intégration de données : ETL . . . . . . . . . . . . . . . . . . . . . . 45 4.5.1 Extraction des données . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.5.2 Transformation des données . . . . . . . . . . . . . . . . . . . . . . . 47 4.5.3 Chargement des données . . . . . . . . . . . . . . . . . . . . . . . . . 48 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.6.1 Choix de graphiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 . . . . . . . . . . . . . . . . . . . . 55 4.6.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Présentation de quelques rapports .
4.6 La phase de reporting .
4.7 Conclusion . .
. .
.
.
.
.
. .
. .
. .
5.1 . Introduction . 5.2 Backlog de sprint 5.3 Publication des rapports sur power BI
5 Sprint 3 : Publication et Actualisation des données . .
58 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 . . . . . . . . . . . . . . . . . . . . . . 59 5.3.1 Affichage web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.3.2 Affichage mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.4 Actualisation des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.4.1 La préparation de l’espace de travail . . . . . . . . . . . . . . . . . . . 61 5.4.2 La planification de l’actualisation . . . . . . . . . . . . . . . . . . . . 64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5 Conclusion . .
. .
.
.
.
vi
.
.
. .
. .
6.1 . Introduction . 6.2 Conception détaillée
6 Amélioration : Création site web de consultation .
66 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 . 6.2.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 66 6.2.2 Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 6.3.1 Outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . 69 Publication des rapports sur le site web . . . . . . . . . . . . . . . . . 70 6.3.2 6.4 Visualisation du site web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.5 Conclusion . .
6.3 Réalisation du site web .
. .
.
.
.
.
Conclusion
75
vii
Table des figures
1.1 Organigramme de la société STAR . . . . . . . . . . . . . . . . . . . . . . . . 5 8 1.2 Représentation graphique de la solution proposée . . . . . . . . . . . . . . . . 1.3 Cycle de vie de la méthode scrum BI [1] . . . . . . . . . . . . . . . . . . . . . 10
.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 . 2.1 Backlog de produit 2.2 Étude approximative des indicateurs de performance . . . . . . . . . . . . . . 15 2.3 Conception globale de l’entrepôt de données . . . . . . . . . . . . . . . . . . . 17 2.4 Architecture des services Power BI [2] . . . . . . . . . . . . . . . . . . . . . . 21
.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.1 Backlog de sprint 1 . 3.2 Fait Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 . 3.3 Conception détaillée du Data mart "Production" . . . . . . . . . . . . . . . . . 24 3.4 Schéma relationnel approximatif de la source de données pour le volet produc-
. .
. .
.
.
.
.
.
.
.
.
.
.
.
tion .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.5 Schéma d’extraction de données relatives à la dimension acte comptable . . . . 27 . . . . . . . . 27 3.6 Schéma d’extraction de données relatives à la dimension contrat 3.7 Schéma d’extraction de données relatives à la table de fait "Production" . . . . 28 Icône du composant tOracleInput . . . . . . . . . . . . . . . . . . . . . . . . 28 3.8 3.9 Réglage du composant tOracleInput et le composant de jointure entre les com-
.
.
posants Main Row .
Publicité
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.10 Icône de composant tMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.11 Le map éditeur du composant tMap . . . . . . . . . . . . . . . . . . . . . . . 30 3.12 Icône du composant tFileInputExcel . . . . . . . . . . . . . . . . . . . . . . 30 3.13 Icône du composant tMSSqlSCD . . . . . . . . . . . . . . . . . . . . . . . . 30 3.14 Editeur du composant SCD tMSSqlSCD . . . . . . . . . . . . . . . . . . . . 31 3.15 Schéma de job d’alimentation de la dimension Contrat . . . . . . . . . . . . . 32 3.16 Schéma de job d’alimentation de la dimension garantie . . . . . . . . . . . . . 32 3.17 Schéma de job d’alimentation de la table de fait production . . . . . . . . . . . 33 3.18 Construction des jobs pour les tâches planifiées . . . . . . . . . . . . . . . . . 34 3.19 Création d’un dossier des tâches planifiées . . . . . . . . . . . . . . . . . . . . 34 3.20 Tâche planifiée de la table de fait production . . . . . . . . . . . . . . . . . . . 35 . . . . . . . . . . . . . . 35 3.21 Liste des tâches planifiées du data mart "Production"
viii
. . . . . . . . . . . . . . . . . . . 36 3.22 Connexion à la base de donnée SQL Server 3.23 Importation de table des faits ainsi les dimensions associées . . . . . . . . . . . 37 3.24 Chargement des données dans power BI . . . . . . . . . . . . . . . . . . . . . 37 3.25 Détails des affaires nouvelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.26 Situation globale des affaires nouvelles . . . . . . . . . . . . . . . . . . . . . . 40 3.27 Nombre des affaires nouvelles par produit et par risque . . . . . . . . . . . . . 41
. .
. . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.1 Backlog de sprint 2 . 4.2 Fait Sinistre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 . . 4.3 Schéma conceptuel du data mart "Sinistre" . . . . . . . . . . . . . . . . . . . . 44 46 4.4 Schéma relationnel approximatif de la source de données pour le volet sinistre 4.5 Requête d’extraction relative à la table de fait sinistre . . . . . . . . . . . . . . 47 4.6 Exemple de schéma de transformation de données . . . . . . . . . . . . . . . . 47 4.7 Exemple d’application du composant tMSSqlSCD . . . . . . . . . . . . . . . . 48 4.8 Schéma général d’un job Talend . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.9 Job d’alimentation de la dimension sinistre . . . . . . . . . . . . . . . . . . . . 49 4.10 Script de création de dimension Date . . . . . . . . . . . . . . . . . . . . . . . 50 4.11 Script de chargement de dimension Date . . . . . . . . . . . . . . . . . . . . . 51 4.12 Chargement table de fait "Sinistre" . . . . . . . . . . . . . . . . . . . . . . . . 52 4.13 Tâche planifié du fait sinistre . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.14 Liste des tâches planifiées du data mart "Sinistre" . . . . . . . . . . . . . . . . 53 4.15 Importation des données dans Power BI . . . . . . . . . . . . . . . . . . . . . 54 4.16 Exemple de création de mesure . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.17 Rapport des règlements en 2018 . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.18 Rapport sur la situation globale 2017/2018 . . . . . . . . . . . . . . . . . . . . 56 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.19 Rapport Boni Mali
. .
.
. .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.1 Backlog de sprint 3 . 5.2 Procédure de publication de rapport . . . . . . . . . . . . . . . . . . . . . . . 59 5.3 Affichage d’un rapport dans Power BI Web . . . . . . . . . . . . . . . . . . . 60 5.4 Espace de travail dans Power BI Mobile . . . . . . . . . . . . . . . . . . . . . 60 5.5 Affichage d’un rapport dans Power BI Mobile . . . . . . . . . . . . . . . . . . 61 5.6 Connexion à la passerelle de données . . . . . . . . . . . . . . . . . . . . . . 62 5.7 Connexion de la source de données . . . . . . . . . . . . . . . . . . . . . . . . 63 5.8 Planification de l’actualisation . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.9 Statut des données lors de l’actualisation . . . . . . . . . . . . . . . . . . . . . 65
. . . . . . . . . . . . . . . . . 67 6.1 Diagramme de cas d’utilisation des utilisateurs 6.2 Diagramme de cas d’utilisation de l’administrateur . . . . . . . . . . . . . . . 68 6.3 Diagramme d’activité-Authentification . . . . . . . . . . . . . . . . . . . . . . 69 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 . 6.4 Liste des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.5 Publication d’un rapport 6.6 Code incorporé d’un rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Intégration du code incorporé dans une page web . . . . . . . . . . . . . . . . 72 6.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 6.8 Page Authentification .
ix
. . 6.9 Page d’accueil . . 6.10 Affichage du menu . 6.11 Affichage du rapport
. . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
x
Table des tables
1.1 Étude comparative entre SCRUM BI et GIMSI
. . . . . . . . . . . . . . . . .
9
2.1 Avantages et Inconvénients de Talend Open Studio, SSIS et Pentaho Data Inte-
gration .
. 2.2 Avantages et Inconvénients de BIRT, Pentaho et Power BI
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 . . . . . . . . . . . 20
.
.
.
.
.
.
.
.
3.1 Liste des indicateurs spécifiques au data mart "Production" . . . . . . . . . . . 25 . . . . . . . . . . . . 38 3.2 Liste des mesures spécifiques au data mart "Production"
4.1 Liste des indicateurs spécifiques au fait sinistre . . . . . . . . . . . . . . . . . 45
xi
Introduction
L’apparition de l’informatique a facilité tant la gestion des entreprises. Ces dernières ont commencé à s’épanouir, et ont cumulé une quantité énorme de données. Néanmoins, cette informatique traditionnelle se trouve inefficace vis-à-vis du gigantesque volume de données à traiter. Avec l’accumulation continue de données, les entreprises se sont rendues compte qu’elles doivent exploiter cette richesse de manière efficace afin de pouvoir dégager de l’in- formation pertinente ce qui permettra d’améliorer leurs activités. Aller chercher de nouvelles technologies est devenu donc un besoin critique. Dès lors, l’informatique décisionnelle s’est bien positionnée sur le marché.
En effet, le décisionnel permet aux analystes de disposer des outils nécessaires pour pou- voir exploiter les données accumulées d’une manière efficace. Il offre des solutions facilitant aux dirigeants l’accès aux informations pertinentes, ce qui assure une bonne compréhension et analyse de l’état actuel de l’entreprise pour un meilleur pilotage et une bonne prise de décision.
La Société Tunisienne d’Assurance et de Réassurance (STAR), comme toute autre entre- prise, gère une quantité énorme de données. En l’absence du décisionnel, elle se confronte à certaines limites qui affaiblissent son rendement. C’est dans ce cadre que s’inscrit notre pro- jet de fin d’études. L’idée est de concevoir une solution décisionnelle qui facilite le traitement de données relatives à la production et au sinistre et leurs analyses. Ce projet a pour finalité la génération des rapports, dans le but d’offrir une vision globale et détaillée sur l’activité de l’entreprise.
Notre projet sera réalisé suivant la méthode scrum BI. Il se décompose en cinq chapitres : Dans le premier chapitre intitulé "Cadre général du projet", nous allons présenter l’organisme d’accueil, puis faire une analyse de l’existant, pour dégager une solution adéquate. Nous défi- nirons aussi la méthode de travail suivie.
Le deuxième chapitre nommé "Analyse et spécification des besoins" représente le sprint 0. Il sera consacré à l’analyse des exigences fonctionnelles et non fonctionnelles du projet. Nous présenterons ensuite la conception globale de l’entrepôt de données ainsi que les outils utilisés pour l’aboutissement du projet.
Le troisième chapitre intitulé "Création data mart Production" est le sprint 1 du projet. Il consiste en l’application des étapes de construction d’un projet BI pour arriver à concevoir un data mart concernant l’activité production, puis générer les rapports relatifs à cette activité.
2
Le quatrième chapitre intitulé "Création data mart Sinitre" représente le sprint 2 du projet. Tout comme le sprint 1, l’idée est de réaliser les différentes étapes d’un projet décisionnel pour aboutir à la génération des rapports relatifs à l’activité sinistre.
Le cinquième chapitre qui représente le sprint 3 consiste à présenter la fonctionnalité d’af- fichage des rapports dans Power BI, le cheminement de publication de ces derniers ainsi que la méthode suivie pour l’actualisation des données.
Le dernier chapitre constitue la phase de clôture du projet. Il sera consacré à la création
d’un site web dans lequel seront affichés les rapports générés par Power BI.
Finalement, nous terminons par une conclusion générale qui récapitulera tout le travail que
nous avons réalisé tout au long de ce stage.
3
Chapitre 1
Cadre générale du projet
1.1
Introduction
Le but de ce chapitre est de mettre le projet dans son contexte général. Nous commençons en premier temps par présenter la Société Tunisienne d’Assurance et de Réassurance (STAR) au sein de laquelle s’est effectué notre stage de fin d’études. En second temps, nous présentons le contexte de notre projet et la méthode suivie pour aboutir aux résultats attendus.
1.2 Présentation de l’organisme d’accueil
1.2.1 Présentation
C’est en Décembre 1958 que la Société Tunisienne d’Assurances et de Réassurances STAR a été fondée. C’est une société tunisienne semi-étatique, spécialisée dans le domaine d’assu- rances et de réassurances. Elle est en partenariat avec la société d’assurances mutuelle française "Groupama" depuis 2008. La STAR est considérée comme un leader sur le marché tunisien d’assurances.
La société a pour objet l’assurance et la réassurance de tous les risques pouvant entraîner tout dommage, tant corporel que matériel ou immatériel ainsi que tous les risques de responsa- bilité civile, professionnelle ou autre. [3]
En effet, la STAR distingue différents types d’assurances :
— L’assurance des dommages qui gère l’assurance « non vie » et les assurances IRDST (In- cendie, Risques Divers, Spéciaux, Transport). Elles regroupent les assurances des biens , les assurances de responsabilité...
— L’assurance des personnes et l’assurance « vie » regroupent les assurances santé et les
assurances vie (vie, décès, épargne, retraite. . . ).
Cette distinction entre ces deux différents types d’assurances se base sur le mode de gestion de primes. Par contre la réassurance est peu connue sur le plan public . C’est un mécanisme qui permet de transférer tout ou une partie de risque accepté par un assureur vers un ré-assureur afin de limiter ses engagements. Elle est pratiquement utilisée dans le cas où vous souscrivez
4
une assurance de bien de grande valeur. L’assureur peut souscrire une réassurance d’assurance afin de couvrir le montant des biens assurés. L’assureur estime que les coûts de risque sont très élevés pour lui seul, donc il cherche à couvrir une partie de ce risque auprès d’un autre assureur.
1.2.2 Organigramme
L’organigramme de la STAR est présenté par la figure 1.1.
FIGURE 1.1 – Organigramme de la société STAR
1.3 Analyse de l’existant
Avant d’entamer tout projet, il faut avoir une idée claire et précise sur l’existant. Nous allons
présenter en premier lieu l’étude de l’existant et nous allons faire sa critique par la suite.
1.3.1 Étude de l’existant
Actuellement, la STAR est en phase de stabilisation de son système d’information. Les don- nées sont éparpillées sur deux systèmes d’information (ancien et nouveau) répartis sur plusieurs serveurs tels que : Oracle, sql server, . . . .
Jusqu’à présent, elle a pu migrer la branche Automobile (qui représente 60 % des données de la STAR) vers une base de données centralisée gérée par un seul Système de Gestion de Bases de Données (SGBD) stocké dans sa totalité sur le serveur Oracle. Cette base de données est accessible par toutes les agences et succursales ce qui a permis d’alléger un peu l’ancien processus de travail. D’autre part, les branches IRDST sont encore sur l’ancien système, dispersées sur divers sources de données. Ce qui permet de dire que les agences et les succursales n’accèdent pas directe- ment à la base de données centrale. Ils collectent les données liées aux affaires effectuées tout au long de la journée et à la fin de cette dernière le personnel de la direction Système et Réseau
5
du siège accèdent aux bases de données des agences pour récupérer toutes les données et les intégrer à la base de données centrale. Pour le suivi mensuel de l’activité de la STAR, les différentes directions (contrôle de gestion, commerciale, comptabilité..) demandent des extractions et des tables d’aggrégations de la part de la structure de Reporting. A partir de ces données envoyées, chaque direction prend en charge la génération des rapports et les tableaux de bord à l’aide du logiciel Excel pour arriver à la fin d’en déduire des analyses . Ceux-ci sont partagés par la suite avec la direction générale et les autres structures. L’activité de la STAR se subdivise en deux volets : Production et Sinistre. Le volet de production englobe tout ce qui concerne les primes émises qui représentent la somme des primes encaissées et arriérées (le revenu de la STAR). Le volet de sinistre se focalise sur la gestion des dossiers sinistres, les réserves et les règlements.
1.3.2 Critique de l’existant
La STAR est considérée comme leader sur le marché tunisien des assurances. Mais, cette dernière confronte dans sa démarche de travail actuelle certaines limites. Dans un pareil contexte la plus simple des opérations d’analyse de données devient une tâche lourde. En effet, le per- sonnel qui est concerné par certaines tâches d’analyse de données se trouve dans l’incapacité de faire des analyses fiables et efficaces pendant une certaine période vu la charge du travail et l’absence des moyens considérable. Les principaux problèmes rencontrés peuvent être résumés comme suit :
-Absence d’outil BI : A l’heure actuelle, la STAR ne possède pas un outil BI qui permet la génération des rapports et tableau de bord. Ces derniers sont effectués d’une manière fastidieuse avec des requêtes SQL complexes. Les rapports et les tableaux de bord sont générés à l’aide de EXCEL par les différentes directions.
-Difficulté dans l’élaboration des rapports d’activité : L’élaboration des rapports d’activité fait intervenir plusieurs intermédiaires. C’est à dire qu’à chaque fois qu’il est nécessaire d’établir les rapports d’activité, il faudra procéder à l’extraction des données à partir de plusieurs sources de données qui sont réparties sur plusieurs serveurs pour les diriger vers une structure centralisée.
-Lenteur de la procédure de Reporting : Le processus de Reporting actuel confronte cer- taines difficultés. Les décideurs ont besoin des rapports dans les brefs délais. Vu la charge du travail et la lourdeur de la procédure, ce processus prend plus du temps qu’il le faut.
-Difficulté dans l’accès aux données : Comme mentionné dans 1.3.1, la STAR est en phase de refonte de son système d’information. De ce fait, il existe encore des agences et des succursales qui n’ont pas un accès direct sur la base principale(pour le cas de l’IRDST). Chaque transaction effectuée est stockée sur une base de test spécifique à chaque agence. A la fin de chaque journée toute ces bases sont recueillîtes dans le siège où se produit leur intégration dans la base centrale. Ce qui rend cette tâche lourde.
Publicité
6
1.4 Présentation de la solution proposée
Dans le cadre de l’amélioration du processus de Reporting, la STAR tend vers la mise en place d’une application intégrée aidant à bien gérer ses données. Le projet consiste à faire la construction d’un système centralisé qui offre une vision globale sur l’ensemble des données d’où la facilité de génération de rapports.
En effet, l’objectif de ce projet est de remédier aux lacunes de la procédure actuelle de la STAR et de mettre en avant les informations clés qui vont servir à l’amélioration de l’activité de l’entreprise. Le travail consiste à concevoir un entrepôt de données rassemblant toutes les données relatives à toutes les branches d’assurances. L’idée est d’arriver, à la fin du processus, de générer des rapports de qualité ainsi que la construction d’un tableau de bord destiné aux décideurs pour avoir une vision profonde sur l’activité de l’entreprise.
Le but est de faciliter l’accès à l’information qui mène à des décisions innovantes et qui servent à bien améliorer le domaine d’activité. Ce dernier va permettre à mieux connaître et comprendre l’état de l’entreprise.
La solution décrite ci dessus doit permettre de : (cid:51) Avoir un entrepôt de données centralisé, intégré, non volatile et historisé. (cid:51) Automatiser la mise à jour de l’entrepôt de données avec lequel vont réagir les rapports. (cid:51) Avoir une vision globale sur toutes les informations de l’activité pour la facilité de géné- ration de rapports par n’importe quel utilisateur mis à part ses connaissances en informa- tique.
(cid:51) Avoir un portail web pour la facilité de consultation des rapports.
7
La solution proposée est schématisée dans la figure 1.2 .
FIGURE 1.2 – Représentation graphique de la solution proposée
1.5 Méthode de gestion de projet
La gestion de projet a pour objectif d’assurer la coordination des acteurs et des tâches. Avant de commencer la réalisation de notre projet, nous allons traiter et évaluer d’abord le choix de la méthode de gestion de projet à suivre pour une meilleure gestion du projet.
1.5.1 Choix de la méthode
Pour réussir un projet décisionnel dans les délais définis en répondant exactement aux exi- gences du client, nous devons suivre une bonne méthode de gestion de projet . Il existe plusieurs méthodes de gestion de projet répandus de nos jours. Nous allons nous focaliser principalement sur les deux méthodes GIMSI et SCRUM BI. Nous étudierons chacune de ces méthodes pour pouvoir en dégager une fiche comparative nous aidant à choisir la méthode la plus appropriée pour notre projet.
8
La méthode classique GIMSI
La méthode GIMSI est parmi les méthodes les plus utilisées en gestion de projet. Elle est basée sur des notions classiques comme le cahier de charge. Cette méthode demande une liste qui englobe la totalité des exigences fonctionnelles détaillées souhaitées pour la réalisation du projet. Tout doit être prévu. Tout changement ou modification imprévus ne seront pas pris en considération.
La méthode agile SCRUM BI
SCRUM BI est une méthode agile dédiée à la gestion des projets BI. Elle est basée sur la notion d’itérations(sous forme de sprints quotidiens) pour permettre la livraison des projets BI dans les brefs délais avec le moindre coût. SCRUM est fondée sur 3 piliers : la transparence, l’inspection ainsi que l’adaptation qui permettent de répondre exactement aux exigences du client.
Scrum BI VS GIMSI
La table 1.1 présente une étude comparative entre les deux méthodes.
Critère de comparaison Processus du travail Implication de l’équipe
Contrôle du Produit
SCRUM BI Processus itératif Intervention tout le long du projet Contrôle régulier
Livraison du produit
Livraison tôt
GIMSI phases séquentielles Intervention au cours du dé- veloppement Contrôle à la fin de la réalisa- tion du produit Livraison à la fin de la réali- sation
TABLE 1.1 – Étude comparative entre SCRUM BI et GIMSI
Selon l’étude comparative établie dans le tableau 1.1, nous avons opté pour la méthode agile
scrum BI, puisqu’elle répond parfaitement aux besoins de notre projet décisionnel.
9
1.5.2 Principe de scrum BI
FIGURE 1.3 – Cycle de vie de la méthode scrum BI [1]
La figure 1.3 nous montre le schéma global de la méthode scrum BI. Cette méthode est basée sur la notion de sprints qui dure de 7 à 30 jours chacun. Le Product Owner se réunit avec l’équipe de travail pour planifier les tâches générales à faire ce qu’on appelle le Backlog du produit(liste des exigences fonctionnelles du projet) . Ainsi, pour avoir un bon résultat, il faut détailler le processus du développement dans le Backlog de sprints qui est évalué tous les jours (sprint quotidien) par l’équipe de travail. A la fin de chaque sprint, toutes les parties prenantes de la méthode se réunissent pour évaluer le travail effectué et planifier pour le prochain sprint et ainsi de suite, un ensemble d’itérations jusqu’à arriver au produit final qui répond aux besoins du client. Tout au long de la période, le scrum master suit la méthode de travail afin de détecter, s’il y’en a, les obstacles rencontrés.
Scrum BI fait intervenir trois rôles principaux :
Le propriétaire du produit (Product Owner) : représente le client, à qui le produit sera li-
vré.
Le maitre Scrum (Scrum master) : représente le coach de la méthode. Il permet de faciliter
et veiller au bon déroulement du travail.
Equipe de développement (Development Team) : est constituée des personnes impliquées dans le projet. Ces dernières sont chargées de transformer les besoins définis par le pro- duct owner en fonctionnalités utilisables.
1.5.3 Scrum appliquée à un projet informatique
Scrum est dédiée généralement au développement des projets informatiques. Suite à sa performance, Scrum est classée parmi les méthodes agiles les plus adopté dans les projets dé-
10
cisionnels. Cette méthode est utilisée suivant différentes approches applicables sur des projets pour réussir leur répartition. Les approches les plus utilisées sont : — L’approche TOP DOWN — L’approche BOTTOM UP
SCRUM avec l’approche TOP DOWN (Inmon)
Bill Inmon déclare dans son approche "Le Data Warehouse est un référentiel centralisé d’entreprise stockant l’information au niveau le plus détaillé. Des Data marts modélisés sous forme de schémas en étoile sont ensuite crées à partir de ce Data Warehouse " [4]. C’est-à-dire que la conception de data warehouse est une étape primordiale dans un projet décisionnel. La réalisation de ce projet suit les étapes suivantes : Dès le premier sprint, on commence par extraire les données nécessaires pour la conception de data warehouse. Suite à cette conception, nous pouvons identifier les domaines sur lesquels va se baser la création des data mart pour des fins d’analyses et de reporting dans les sprint suivants. Durant tout le temps de la réalisation, l’équipe présente au product owner un exemplaire fonctionnel en utilisant des données réelles pour avoir une idée sur son feedback. Cette approche paraît la plus facile à adapter. Mais elle est un peu coûteuse de point de vue temps et compétence.
SCRUM avec l’approche BOTTOM UP (Kimball)
L’informaticien Ralph Kimball énonce dans son approche " Le data warehouse peut être vu comme l’union des data marts cohérents entre eux grâce aux dimensions conformes" [4]. C’est a dire que cette approche est applicable avec la méthode scrum, dont nous allons focaliser pour chaque sprint un processus métier. Nous traiterons tout le processus d’un projet décisionnel (commençant par l’ETL jusqu’au génération des rapports). Cette approche met en sûreté une succession des sprints, avec lesquels nous trouvons le même processus et presque la même complexité tout dépend du sujet traité, ce qui permet de donner de bons résultats aux utilisateurs finaux.
Choix de l’approche adapté avec Scrum
Après avoir défini les différentes approches que nous pouvons les adapter avec la méthode scrum, nous nous sommes orientés vers l’approche BOTTOM UP. L’idée est de créer des data marts en premier lieu pour avoir un résultat livrable sans attendre la conception globale de l’entrepôt de données.
1.6 Conclusion
Durant ce chapitre, nous avons présenté le cadre général du projet. Nous avons commencé par présenter l’entreprise d’accueil. Ensuite, nous avons étudié l’existant, la solution proposée avec la méthode suivie pour l’aboutissement aux objectifs du projet ainsi que l’approche que nous allons appliquer avec cette méthode. Dans le chapitre suivant, nous allons spécifier les exigences de notre projet.
11
Chapitre 2
Sprint 0 : Analyse et spécification des besoins
2.1
Introduction
Ce chapitre représente le sprint 0 selon la méthode suivie. Durant ce sprint, nous allons spécifier les besoins fonctionnels et non fonctionnels de notre système décisionnel. Cette phase est fondamentale dans tout projet pour permettre une conception claire. Nous définissons par la suite les outils d’informatique décisionnelle que nous avons choisi pour l’élaboration du projet.
2.2 Spécification des exigences
Nous présentons ci dessous les exigences fonctionnelles et non fonctionnelles
2.2.1 Exigences fonctionnelles
Investir dans une solution de business intelligence, c’est satisfaire les décideurs afin de guider l’entreprise vers le bon chemin. Les décideurs exigent certaines fonctionnalités qui ré- pondent à leurs besoins :
(cid:51) Générer des rapports dynamiques qui peuvent être exportés ou imprimés sous formats
PDF.
(cid:51) Avoir la possibilité de consulter des rapports dynamique sur un portail mobile. (cid:51) Générer des rapports dynamiques enrichis par plusieurs filtres que l’utilisateur peut les
utiliser selon son besoin.
(cid:51) Assurer le partage des rapports générés par toutes les directions de la STAR en respectant
les droits d’accès.
12
(cid:51) Offrir la possibilité de consultation des rapports dynamiques sur un portail web qui sera
hébergé sur l’intranet.
2.2.2 Exigences non fonctionnelles
Mis à part les exigences fonctionnelles, notre système doit répondre aux exigences non
fonctionnelles suivantes :
(cid:51) Intégrité des données : Les data marts conçus doivent englober toutes les données ve- nant de plusieurs sources. Ces données doivent être de qualité, homogènes et fiables pour bien répondre aux besoins des utilisateurs.
(cid:51) Simplicité : Avoir des rapports simples et faciles à interpréter fait partie des finalités d’un
projet décisionnel.
(cid:51) Maintenabilité : Les données du data mart doivent être mises à jour chaque fin du mois
pour pouvoir générer des rapports fiables et en temps réel.
(cid:51) Ergonomie : Il faut avoir des interfaces simples et faciles à gérer.
(cid:51) Sécurité : Assurer la confidentialité des données de la société grâce aux authentifications
requises dans la consultation des rapports sur la page web.
2.3 Backlog de produit
Publicité
Nous commençons par définir le backlog de produit, qui servira à piloter l’équipe du dé- veloppement. Il se présente sous forme d’une liste de fonctionnalités. Ces fonctionnalités sont exprimées sous forme des besoins selon la priorité fixée par le product o