PFE UP Pfe Siwar Et Anis

République Tunisienne
*****
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
*****
Université de Monastir
*****
Département informatique
Projet de Fin d’Etude

Présenté en vue de l’obtention du
Diplôme national de Licence Fondamentale en sciences

Informatique
Spécialité :
Sciences informatique
Par
Mejri Siwar et Chennaoui Anis
Gestion des assurances en ligne
Soutenu le 23-06-2021 devant le jury composé de :
M. Imed Abbassi Président

Mme. Hanen Abbess Membre
M. Sami Bhiri Encadrant ISIMM
M. Firas Boukhriss Encadrant Professionnel
Année universitaire : 2020 – 2021

Résumé
Ce travail s’inscrit dans le cadre de l’accomplissement de notre Projet de Fin d’Études à

l’Institut Supérieur d'Informatique et de Mathématiques de Monastir pour l’année
universitaire 2020-2021 en vue de l'obtention du Diplôme national de Licence Fondamentale
en Sciences Informatique. Ce projet a été effectué au sein de la société « Make It Happen »
ayant comme objectif la conception et le développement d’une application web de gestion des
assurances en ligne. Pour réaliser ce projet, nous avons utilisé les frameworks Laravel et
ReactJs et Mysql pour gérer la base de données. Nous avons suivi la méthodologie 2TUP pour
gérer notre projet. En se basant sur ce document, nous décrivons en détail les différentes
étapes de réalisation de ce projet.
Mots clés : Laravel8, ReactJs,Artisan,npm,DOM.
Abstract
This work is part of the accomplishment of our End of Studies Project at the Higher Institute
of Computer Science and Mathematics of Monastir for the 2020-2021 academic year in order
to obtain the National Diploma of Fundamental License in Computer Sciences. This project
was carried out within the company « Make It Happen », It aims to set up a Web Application
that manage online insurances . To achieve this project, we used the Laravel and ReactJs and
Mysql frameworks to manage the database. We followed the 2TUP methodology to manage
our project. Through this document, we describe in detail the different stages of the realization
of this project.
Keywords : Laravel8, ReactJs, Artisan,npm,DOM.

Dédicaces
A mes parents Latifa et Chams Eddine

Dont le mérite, les sacrifices et les qualités humaines m’ont permis de vivre ce jour, qu’ils trouvent
en moi la source de leur fierté.
A mon frère Achraf et ma sœur Amira
À vous que je souhaite un avenir radieux plein de réussite.
A tous mes amis et ceux qui m'aiment
Haroun, Mohamed, Ghada, Siwar, Hamza, Bilel……
A spécialement tante Jamila
Pour son âme pure et sa générosité
Anis CHENNAOUI
Dédicaces
Du profond de mon cœur, je dédie ce travail

À ma chère maman pour tous les inestimables sacrifices que tu as consentis pour moi, pour ton
précieux soutien que tu m’as offert tout au long de mes études et surtout pour ton amour qui m'a
toujours renforcé
À mon cher papa pour ses encouragements et surtout pour son soutien financier et moral
À mes sœurs Hind, Amina et Yossr et mon Frère Naim qui ont été toujours présents pour m’aider
et m’encourager et qui n’ont jamais cessé de croire en moi
À Tous mes amis que j’aime et qui m’aiment et à Moez Sidhom et Akram Thabet en
particulièrement qui m'ont aidée dans les moments difficiles.
À toutes les personnes que j'ai rencontrées pendant mon parcours à l’ISIMM pour les traces qui
vont marquer la femme que je suis aujourd’hui, à tout jamais.
Siwar MEJRI
Remerciements
Avec beaucoup de plaisir, Nous tenons, tout d’abord, à exprimer notre profonde gratitude, notre
reconnaissance, notre respect et nos remerciements, les plus sincères à, Mr Sami BHIRI, notre
encadrant à l’Institut Supérieur d’Informatique et de Mathématique de Monastir pour sa
disponibilité, ses directives, ses conseils si enrichissants et qui s'est toujours montré à l'écoute
tout au long de ce travail.
Nos vifs remerciements sont adressés à, Mr Firas Boukhriss, notre encadrant à l’entreprise
d’accueil « Make It Happen » pour son accueil et sa précieuse collaboration.
Nous adressons l’expression de toute notre gratitude également à tous les enseignants de
L’ISIMM pour leurs qualités scientifiques et pédagogiques.
Nous tenons à remercier les respectueux membres du jury qui nous ont honorés d’avoir accepté
d’évaluer ce travail.
TABLE DES MATIÈRES
Chapitre I. Contexte et objectifs du projet ...................................................................................................1

Introduction .................................................................................................................................................................. 1
1. Contexte général du projet ........................................................................................................................... 1
1.1. Cadre du projet .......................................................................................................................................... 1
1.2. Présentation de la société d’accueil................................................................................................. 1
1.3. Objectifs du projet.................................................................................................................................... 2
2. Etude de l’existant ............................................................................................................................................. 2
2.1. Solutions existantes ................................................................................................................................ 2
2.1.1. Assurance GAT ................................................................................................................2
2.1.2. Assurance STAR ...............................................................................................................3
2.1.3. BH Assurance ..................................................................................................................4
2.1.4. Tableau comparatif .........................................................................................................4
2.2. Critique de l’existant ............................................................................................................................... 5
2.3. Travail à réaliser ....................................................................................................................................... 5
3. Méthodologie de travail ................................................................................................................................. 6
3.1. Méthode 2TUP: Two Tracks Unified ............................................................................................... 6
3.2. Méthode agile scrum .............................................................................................................................. 7
3.3. Méthodologie adoptée ........................................................................................................................... 9
4. Diagramme de Gantt ........................................................................................................................................ 9
Conclusion...................................................................................................................................................................... 9
Chapitre II. Analyse et spécification des besoins.................................................................................... 10
Introduction ............................................................................................................................................................... 10
1. Analyse et identification des besoins.................................................................................................... 10
1.1. Identification des acteurs .................................................................................................................. 10
1.2. Besoins fonctionnels ............................................................................................................................ 11
1.3. Besoins non fonctionnels .................................................................................................................. 12
2. Spécification des besoins fonctionnels ................................................................................................ 13
2.1. Diagramme de cas d’utilisation général ..................................................................................... 13
2.2. Diagrammes de cas d’utilisation détaillés ................................................................................. 15
2.2.1. Diagramme de cas d’utilisation détaillé de l’acteur « Client » ........................................ 15
2.2.2. Diagramme de cas d’utilisation détaillé de l’acteur « Personnel » .................................. 15
2.2.3. Diagramme de cas d’utilisation détaillé de l’acteur « Admin » ....................................... 16
2.2.4. Diagramme de cas d’utilisation détaillé de l’acteur « Super Admin » ............................. 16
2.3. Diagrammes de séquence acteur-système ................................................................................ 17
2.3.1. Diagramme de séquence « Gérer assurance » ............................................................... 17
2.3.2. Diagramme de séquence « Demande de remboursement » ........................................... 19
2.3.3. Diagramme de séquence « Gérer personnel » ............................................................... 20
3. Choix technique............................................................................................................................................... 22
3.1. Bibliothèque React................................................................................................................................ 22
3.2. Framework Laravel .............................................................................................................................. 23
Conclusion................................................................................................................................................................... 24
Chapitre III. Conception................................................................................................................................. 25
Introduction ............................................................................................................................................................... 25
1. Modèle architectural..................................................................................................................................... 25
1.1. L’architecture 3-tiers........................................................................................................................... 25
1.2. Modèle MVC ............................................................................................................................................. 26
1.3. Architecture adoptée ........................................................................................................................... 27
2. Conception de la base de données ......................................................................................................... 28
2.1. Modèle conceptuel de données (MCD) ....................................................................................... 28
2.2. Modèle Logique de données (MLD) ............................................................................................. 30
3. Conception logicielle détaillée ................................................................................................................. 31
3.1. Vue statique : Diagramme de classe ............................................................................................. 31
3.2. Vue dynamique : diagramme de séquence ............................................................................... 34
3.2.1. Diagramme de séquence général................................................................................... 34
3.2.2. Diagramme de séquences « AjouterAdmin » ................................................................. 36
3.2.3. Diagramme de séquences « ConsulterListeRemboursement » ....................................... 37
3.2.4. Diagramme de séquences « SouscrireAssurance » ......................................................... 38
3.3. Conception des interfaces graphiques ........................................................................................ 39
3.3.1. Diagramme de navigation.............................................................................................. 39
3.3.2. Maquettage .................................................................................................................. 41
Conclusion................................................................................................................................................................... 43
Chapitre IV. Réalisation ................................................................................................................................. 44
Introduction ............................................................................................................................................................... 44
5. Environnement et outils de travail ........................................................................................................ 44
5.1. Environnement matériel ................................................................................................................... 44
5.2. Environnement logiciel ...................................................................................................................... 45
5.2.1. Environnements et technologies de développement ..................................................... 45
6. Bibliothèque React ......................................................................................................................................... 47
6.1. React DOM ................................................................................................................................................ 48
6.2. Le cycle de vie d’un composant React ......................................................................................... 49
7. Framework Laravel ....................................................................................................................................... 49
7.1. Organisation d'un projet Laravel ................................................................................................... 49
7.2. L’architecture de Laravel ................................................................................................................... 50
7.3. Manipulation de données .................................................................................................................. 53
7.4. Invite de commande « Artisan » ..................................................................................................... 54
8. Travail réalisé .................................................................................................................................................. 55
8.1. Interface « Login »................................................................................................................................. 55
8.2. Interface « Register for Insurance » ............................................................................................. 56
8.3. Interface « My Insurance Requests » ........................................................................................... 56
8.4. Interface « Insurance Request » ..................................................................................................... 57
8.5. Interface « Add Staff » ......................................................................................................................... 57
9. Etat de réalisation: ......................................................................................................................................... 58
Conclusion................................................................................................................................................................... 59
Conclusion générale ....................................................................................................................................... 60
Table des figures
Figure 1.1 : Logo du « Make It Happen » .............................................................................................................. 1

Figure 1.2 : Page d'accueil du site « Assurance GAT » ................................................................................... 2
Figure 1.3 : Page d'accueil du site « Assurance Star » ................................................................................... 3
Figure 1.4 : Page d'accueil du site « Bh Assurance » ...................................................................................... 4
Figure 1.5 : Représentation de la méthodologie 2TUP ................................................................................. 7
Figure 1.6 : Représentation de la méthodologie SCRUM ............................................................................. 8
Figure 1.7 : Diagramme de Gantt ............................................................................................................................. 9
Figure 2.1 : Diagramme de cas d'utilisation général ................................................................................... 14
Figure 2.2 : Diagramme de cas d'utilisation du l’acteur « Client »........................................................ 15
Figure 2.3 : Diagramme de cas d'utilisation du l’acteur « Personnel »............................................... 16
Figure 2.4 : Diagramme de cas d'utilisation du l’acteur « Admin » ...................................................... 16
Figure 2.5 : Diagramme de cas d'utilisation du l’acteur « SuperAdmin » ......................................... 17
Figure 2.6 : Diagramme de séquence « Gérer assurance » ....................................................................... 18
Figure 2.7 : Diagramme de séquence « Demande de remboursement » ........................................... 20
Figure 2.8 : Diagramme de séquence « Gérer personnel » ....................................................................... 22
Figure 2.9 : utilisation des frameworks JS les plus utilisées selon google trends ......................... 23
Figure 2.10 : Les frameworks PHP les plus utilisés selon google trends .......................................... 24
Figure 3.1 : L’architecture 3-tiers........................................................................................................................ 26
Figure 3.2 : L'architecture du modèle MVC ..................................................................................................... 27
Figure 3.3 : L'architecture de notre application ............................................................................................ 27
Figure 3.4 : Modèle Conceptuel de données (MCD) .................................................................................... 28
Figure 3.5 : Le Modèle Logique de Données .................................................................................................... 31
Figure 3.6 : Diagramme de classe ......................................................................................................................... 33
Figure 3.7 : Diagramme de séquence général ............................................................................................... 35
Figure 3.8 : Diagramme de séquence « AjouterAdmin » ........................................................................... 36
Figure 3.9 : Diagramme de séquence « ConsulterListeRemboursement » ....................................... 37
Figure 3.10 : Diagramme de séquence « SouscrireAssurance » ............................................................ 38
Figure 3.11 : Diagramme de navigation ............................................................................................................ 40
Figure 3.12 : Interface "Gérer remboursement" ........................................................................................... 41
Figure 3.13 : Interface « souscrire assurance » ............................................................................................. 42
Figure 3.14 : Interface « Consulter assurance » ............................................................................................ 42
Figure 3.15 : Interface « Consulter la liste des admins » ........................................................................... 43
Figure 4.1 : Structure de notre projet React.................................................................................................... 48
Figure 4.2 : Exemple d'un DOM ............................................................................................................................. 48
Figure 4.3 : Organisation de notre projet Laravel ........................................................................................ 50
Figure 4.4 : L’architecture de Laravel................................................................................................................. 51
Figure 4.5 : Extrait du code de l’entité « Client »........................................................................................... 51
Figure 4.6 : Extrait de contrôleurs de notre application ........................................................................... 52
Figure 4.7 : Extrait de routes de notre application ...................................................................................... 52
Figure 4.8 : Extrait du code de « LogIn » ........................................................................................................... 53
Figure 4.9 : Le fichier de configuration de notre base de données ...................................................... 53
Figure 4.10 : Extrait du répertoire « Migration » de notre application.............................................. 54
Figure 4.11 : Extrait du code « Seeder » de la table « User » ................................................................... 54
Figure 4.12 : Interface « Login »........................................................................................................................... 55
Figure 4.13 : Interface « Register for Insurance » ........................................................................................ 56
Figure 4.14 : Interface « My Insurance Requests » ...................................................................................... 56
Figure 4.15 : Vue « Insurance Request » ........................................................................................................... 57
Figure 4.16 : Interface « Add staff » ..................................................................................................................... 57
Figure 4.17 : Interface « Consult staff list » ..................................................................................................... 58
Figure 4.18 : Etat de réalisation des fonctionnalités ................................................................................... 58
Liste des tableaux
Table 1.1 : Tableau comparatif entre les solutions existantes .................................................................. 5
Table 2.1 : Description du C.U « Gérer assurance » ..................................................................................... 17
Table 2.2 : Description du C.U « Demande de remboursement ».......................................................... 19
Table 2.3 : Description du C.U « Gérer personnel » ..................................................................................... 20
Table 3.1 : Les entités du modèle conceptuel de données ....................................................................... 29
Tableau 4.1 : Caractéristique de l'environnement matériel .................................................................... 44
Tableau 4.2 : Environnements et technologies de développement ..................................................... 45
Tableau 4.3 : les commandes importantes de Laravel ............................................................................... 55

Liste des abréviations
 API : Application Programming Interface
 JSON : Java Script Objet Notation
 HTTP : Hypertext Transfer Protocol
 SQL : Structured Query Language
 MVC : Model-View-Controller
 IHM : Interface Homme Machine
 CU : Cas d’Utilisation
 DAL : Data Access Layer
 NPM : Node Package Manager
 UML : Unified Modeling Language
 CSRF : Cross Site Request Forgery
 VDOM: Virtual Document Object Model

Introduction générale
ctuellement, chaque entreprise d’assurance cherche le meilleur moyen pour

A satisfaire les besoins de ses clients au mieux et de confronter les différents
conflits qui peuvent être engendrés par le manque de coordination et
d’organisation de son personnel.
En effet, vu la demande de beaucoup de papiers justificatifs et la procrastination de

répondre aux demandes, une demande d’assurance est devenue de plus en plus complexe et
ennuyeuse pour les clients. En plus, les tâches administratives sont parfois rébarbatives et
chronophages.
Pour dépasser ces difficultés, nous cherchons à créer une application web de gestion
des assurances qui facilite la souscription d’assurance, le suivi des demandes de
remboursement et qui synchronise le travail du personnel.
Le présent rapport présente les différentes étapes de la réalisation de notre projet qui
s’étale sur quatre chapitres. Au niveau du premier chapitre « Contexte et objectifs », nous
présenterons le cadre général et l'idée émergeante du projet puis les solutions existantes et la
méthodologie de travail. Dans le deuxième chapitre « Analyse et spécification des besoins »,
nous mettrons l’accent sur les spécifications des besoins fonctionnels, non fonctionnels et les
besoins techniques. Nous procéderons au cours du troisième chapitre à la « Conception », nous
allons détailler la conception de la base de données, ainsi que, les couches logicielles de notre
application. Nous aborderons aussi la conception des interfaces utilisateurs. Dans le
quatrième chapitre intitulé « Réalisation », nous prendrons en analyse l'environnement
logiciel et matériel que nous allons utiliser pour le développement de l’application. Il illustre
aussi les différentes interfaces de notre système. Et pour finir, nous clôturerons notre rapport
par une conclusion générale.
1
Chapitre I. Contexte et objectifs du projet
Introduction
Au cours de ce chapitre, nous allons introduire notre projet en étudiant son cadre général et
la problématique qui a mené l'organisme d'accueil à réaliser cette application. Ensuite nous
allons procéder à l’étude de l’existant avec leurs critiques et nous introduirons les solutions
proposées.
Par la suite, nous allons aborder une étude sur les différentes méthodologies de travail
existantes afin de dégager celle la plus adéquate à notre projet.
1. Contexte général du projet

Dans cette partie, nous allons présenter le cadre général du projet et ses objectifs.
1.1. Cadre du projet

Le présent travail s'inscrit dans le cadre du projet de fin d'études en vue de l'obtention du
Diplôme de Licence Fondamentale en Informatique à « l'Institut Supérieur d'Informatique et
de Mathématiques de Monastir ». Le stage a été effectué au sein de la société « Make It
Happen » durant la période de trois mois du 15 mars 2021 au 15 Juin 2021.
1.2. Présentation de la société d’accueil

« Make It Happen » [1] est une entreprise d’ingénierie informatique située à Mahdia, crée en
2020 et spécialisée en développement et services informatiques.
Figure 1.1 : Logo du « Make It Happen »
1
Chapitre I Contexte et objectifs du projet
Ses domaines d’activités couvrent essentiellement :
 Développement et Mise en place de solutions Web, Mobile et Desktop.

 Référencement et Hébergement.
 Design Graphique, Marketing et Consulting.
« Make It Happen » est une équipe jeune et dynamique réunie pour répondre aux besoins de
ses clients et les accompagner tout au long de leurs projets qui nous a donné l’opportunité de
développer et mettre en pratique les acquis des connaissances pratiques et théoriques de nos
études.
1.3. Objectifs du projet

L’objectif de notre projet est de concevoir et développer une application web d’assurance en
ligne qui évite les lacunes habituelles de gestion des employés comme les problèmes de
coordination, le manque de communication et le manque de contrôle pour satisfaire les
besoins des clients en améliorant les processus habituels comme l’automatisation de
l’assurance, la possibilité de payer en ligne, le suivi des factures, des demandes d’assurance et
des demandes de remboursement en ligne.
2. Etude de l’existant
L'étude de l'existant consiste à auditer les solutions existantes pour s’inspirer et pour raffiner
de plus l’idée immergeant.
2.1. Solutions existantes

2.1.1. Assurance GAT
Figure 1.2 : Page d'accueil du site « Assurance GAT »
2
GAT ASSURANCES [2] est une compagnie d'assurance tunisienne qui offre une large
gamme de solutions pour les particuliers, professionnels et entreprises. Elle offre à ces
utilisateurs la possibilité de :
 Gérer leur profil.

 Consulter les différentes catégories d'assurance ainsi les annonces dans la page
d’accueil.
 Demander de devis en ligne.
 Consulter les contrats souscrits.
 Payer en ligne les assurances.
2.1.2. Assurance STAR
Figure 1.3 : Page d'accueil du site « Assurance Star »

Assurance Star [3] a pour objet l'assurance et la réassurance de tous les risques pouvant
entraîner tous dommages tant corporels que matériels ou immatériels. Ce site permet ces
utilisateurs de :
 Passer une réclamation.

 Demander de devis en ligne.
 Consulter blog.
3
2.1.3. BH Assurance
Figure 1.4 : Page d'accueil du site « Bh Assurance »

BH Assurance [4] a été créée à l'initiative de la BH BANK (ex-Banque de l'Habitat). Elle offre à
ces utilisateurs la possibilité de :
 Créer et gérer leur compte.
 Avoir un Dashboard qui permet de visualiser les détails de leurs contrats
souscrits.
 S'informer sur les agences proches.
 Payer en ligne les assurances.
2.1.4. Tableau comparatif

Nous pouvons classer les résultats de l'analyse des applications web existantes mentionnées
précédemment, comme l’illustre le tableau 1.1, selon neuf critères (Cx) pris en considération
dans le processus d'évaluation de ses applications :
 C1 : Temps de réponse : Le temps qui s'écoule entre l'application d'un stimulus et la
réaction volontaire consécutive. Ce temps est fourni par le site gtmetrix.com [5].
 C2 : Structure : L'organisation et la structure d'une application sont les deux
éléments principaux qui définissent son architecture. En effet, ce sont tous les
éléments qui vont permettre de faire fonctionner l'application et surtout c'est
comment ils vont permettre de le faire.
 C3 : Mise à jour : Une mise à jour est un programme destiné à apporter une
correction à un programme existant, régulièrement, les mises à jour de son
système, sont destinées à améliorer l’expérience de l’utilisateur.
4
 C4 : Gestion de profil : Préserver la simplicité lors de la gestion d'un profil utilisateur

ou modèle d'utilisateur est un ensemble de données et métadonnées fonctionne
d'un ou plusieurs utilisateurs qui influence le comportement d'un dispositif
informatique.
 C5 : Message : La messagerie c'est un système qui permet à deux ou plusieurs
personnes de discuter virtuellement via un logiciel adéquat.
 C6 : Notification : La notification est la formalité par laquelle on tient officiellement
une personne, informée du contenu d'un acte à laquelle elle n'a pas été partie.
 C7 : Assurances en ligne : Passer les demandes d'assurance en ligne sans se
déplacer.
 C8 : Remboursement en ligne : Passer les demandes de remboursement en ligne.
 C9 : Paiement en ligne : Payer les factures en ligne et immédiatement.
Table 1.1 : Tableau comparatif entre les solutions existantes

Critère BH Assurance BH GAT STAR
Assurance Assurance Assurance
Temps de réponse (C1) 3.2s 8.1s -
Structure (C2) 65% 53% -
Mise à jour (C3) Oui Oui Oui
Gestion profil (C4) Oui Oui Non
Message (C5) Oui Non Non
Notification (C6) Oui Oui Non
Assurances en ligne (C7) Non Non Non
Remboursement en ligne (C8) Non Non Non
Paiement en ligne (C9) Oui Oui Non
2.2. Critique de l’existant

Chaque application mentionnée précédemment ne donne pas l'opportunité aux clients
d’assurer des objets simples et susceptibles d'être endommagés facilement, on parle des
objets vitaux et indispensables comme un téléphone, portatif ou des lunettes de vue. Même si
les objets mentionnés ne coûtent pas cher comme une voiture ou un appartement mais ils sont
nécessaires pour accomplir nos missions journalières.
2.3. Travail à réaliser

De ce fait, il est primordial de proposer une solution innovante et utile qui permet
d'informatiser les demandes d'assurance sur ces objets.
Donc, les principales fonctionnalités que notre application doit offrir :
5
Au client :
 L’Informatisation qui a comme but de supprimer la paperasserie et faire gagner du

temps.
 La gestion de son profil et de ses informations personnelles.
 Une Souscription plus facile que les méthodes habituelles. Il suffit de suivre les
instructions et de remplir soigneusement les formulaires et les demandes.
 Une assurance 100% en ligne sans avoir besoin de se déplacer ce qui permet
d’accélérer le processus d’assurance, de remboursement et permet aux clients de
suivre leurs dossiers en ligne.
 La possibilité de payer en ligne.
 La communication instantanée avec les administrateurs.
Â l’administration :
 L’Informatisation qui a comme but de supprimer la paperasserie et faire gagner du

temps.
 Une gestion plus facile du personnel grâce à une vue d'ensemble détaillée de tous
les paramètres clés, ainsi que, l’affectation rapide de chaque tâche à l’employé
concerné et le contrôle de son rendement par rapport à l’exécution des tâches qui
lui sont affectées.
 La gestion d'assurances et de réclamations.
 La gestion des clients.
3. Méthodologie de travail
Avant de réaliser chaque projet, il est nécessaire de choisir une méthodologie de travail afin
d’aboutir à un logiciel fiable, adaptable et efficace. Et pour pouvoir choisir la méthodologie la
plus adéquate nous avons procédé à une comparaison entre la méthode 2Tup et la méthode
agile Scrum.
3.1. Méthode 2TUP: Two Tracks Unified

La méthode 2 Tracks Unifed est un processus de développement logiciel qui met en œuvre la
méthode du processus unifié (c'est-à-dire construit sur UML, itératif, centré sur l'architecture
et conduit par les cas d'utilisation).
Le 2TUP propose un cycle de développement en Y, qui dissocie les aspects techniques des
aspects fonctionnels. Il commence par une étude préliminaire qui consiste essentiellement à
identifier les acteurs qui vont interagir avec le système à construire, les messages
qu'échangent les acteurs et le système, à produire le cahier de charges et à modéliser le
contexte.
Le processus s'articule ensuite autour de trois phases essentielles comme indique la figure 1.5
6
 Une branche fonctionnelle : elle capitalise la connaissance du métier de l’entreprise.

Cette branche capture des besoins fonctionnels, ce qui produit un modèle focalisé
sur le métier des utilisateurs finaux.
 Une branche technique : capitalise un savoir-faire technique et/ou des contraintes
techniques. Les techniques développées pour le système sont indépendamment des
fonctions à réaliser.
 Une phase de réalisation : elle consiste à réunir les deux branches, permettant de
mener une conception applicative et enfin la livraison d'une solution adaptée aux
besoins
Figure 1.5 : Représentation de la méthodologie 2TUP
3.2. Méthode agile scrum

La méthode agile Scrum, illustrée par la figure 1.6, se base sur le découpage du projet en
itérations nommées sprints qui se succèdent et durent de 2 à 4 semaines. Chaque itération
commence par une réunion de planification appelée « Sprint planning » pour définir son
objectif et décomposer chaque besoin en plusieurs tâches. Le sprint se termine par une
démonstration de ce qui a été réalisé, pour l’évaluer et le valider. Le but de cette méthode est
de produire la plus grande valeur métier dans la durée la plus courte.
Lorsque nous disons Scrum, il faut comprendre les mots concepts suivants :
 Responsable Produit (Product Owner) : Il représente les clients et les utilisateurs et

détermine ce qui doit être réalisé.
 Scrum Master : Le responsable du déroulement du processus. Il gére efficacement le

carnet du produit et il garantit la motivation de l'équipe et l'efficacité de la
collaboration entre les membres.
7
 Équipe projet : L’équipe de développement s'organise elle-même pour déterminer la

meilleure façon de produire les exigences les plus prioritaires, son rôle principal est de
livrer un incrément, une version du logiciel, à la fin de chaque Sprint.
 User story : C’est l’histoire utilisateur décrivant un besoin fonctionnel désiré par le
client.
 Backlog du produit : Besoins priorisés par le product owner et estimés par l’équipe, qui
évoluent et sont affinés.
 Sprint : Un Sprint est une itération. Il s'agit d'une période de 2 à 4 semaines maximum
pendant laquelle une version terminée et utilisable du produit est réalisée. Chaque
sprint a un objectif et une liste de fonctionnalités à réaliser.
 Backlog du sprint : Une sélection de tâches retenues du « Backlog du produit » pour

construire l'objectif du sprint.
 Daily Meeting : C'est une réunion quotidienne qui permet de mettre le point sur ce qui
a été réalisé, les problèmes rencontrés et les objectifs de la journée.
 Démonstration du sprint : Nommé aussi « Sprint Review ». C'est une réunion

programmée à la fin de chaque sprint durant laquelle l'équipe de projet présente le
travail réalisé pour l’évaluer et le valider.
Figure 1.6 : Représentation de la méthodologie SCRUM
8
3.3. Méthodologie adoptée

Nous avons décidé d’adopter le processus 2TUP pour la suite de notre travail car il respecte
le cadre de notre projet qui est basé sur un processus de développement bien défini qui
commence par la détermination des besoins fonctionnels du système jusqu'à la conception et
l’implémentation ainsi qu’il correspond à l’envergure et la durée de notre projet.
4. Diagramme de Gantt
Le diagramme de Gantt est un outil utilisé en ordonnancement et en gestion de projet qui
permet de visualiser dans le temps les diverses tâches qui composent un projet. La figure 1.7
montre graphiquement l'avancement de notre projet pendant la période du stage.
15-mars 25-mars 04-avr. 14-avr. 24-avr. 04-mai 14-mai 24-mai 03-juin 13-juin 23-juin
Formation
Analyse et spécification des besoins
Conception
Implémentation
Test
Rédaction du rapport
Analyse et
Rédaction du
Test Implémentation Conception spécification des Formation
rapport
besoins
Date début 25-mars 28-mai 21-avr. 01-avr. 15-mars 15-mars
Jours pour finir 83 15 50 24 26 22
Figure 1.7 : Diagramme de Gantt
Conclusion
En guise de conclusion, dans ce chapitre nous avons mis notre projet dans son cadre général.
Ensuite, nous avons étudié les solutions existantes et proposé notre propre solution. Enfin,
nous avons clôturé par la méthodologie de développement que nous avons adoptée.
Dans le chapitre suivant nous allons spécifier les différents besoins auxquels doit répondre
notre application.
9
Chapitre II. Analyse et spécification des besoins
Introduction
L’étape d’analyse et spécification des besoins est une étape indispensable pour comprendre
les fonctionnalités que le système doit fourni. Dans ce chapitre nous présenterons les
fonctionnalités fournies et les acteurs concernés par notre système. Nous allons exprimer les
besoins fonctionnels et non fonctionnels sous forme de diagrammes de cas d’utilisation et des
diagrammes de séquence.
1. Analyse et identification des besoins

Dans cette partie, nous voulons identifier les acteurs et leurs rôles. Par la suite, nous allons
analyser les différents besoins fonctionnels et non fonctionnels que notre système cherche à
satisfaire.
1.1. Identification des acteurs

Un acteur est une entité externe qui définit le rôle joué par un utilisateur, humain ou non
humain, qui interagit avec un système interactif.
Notre système comporte les acteurs suivants :
 Internaute : C’est un simple visiteur du site, il peut consulter les nouveautés sur la page
d’accueil. Il a aussi le droit de créer un profil et devenir un client dans notre plateforme.
 Client : C’est un internaute qui possède un profil dans le site, il peut consulter, modifier
ou supprimer son profil. Il peut également souscrire, consulter, annuler une assurance
comme il peut consulter ses factures, ses notifications et ses demandes de
remboursement.
 Personnel : le personnel représente un employé enregistré dans la base de données qui

exerce certaines fonctionnalités pour répondre aux besoins des clients. Il gère les
demandes de remboursement et vérifie les payements effectués par les clients.
 Administrateur : C’est un abonné au site qui a l’accès à l’espace administratif de la

plateforme. Il peut répondre aux messages envoyés par les clients via le système de
chat et gérer les demandes d’assurances.
10
Chapitre II Analyse et spécification des besoins
 Super Administrateur : C’est le responsable du site. Il possède des droits

supplémentaires, comme la gestion des administrateurs et du personnel.
1.2. Besoins fonctionnels

Les besoins fonctionnels sont les fonctionnalités que notre système doit accomplir pour
satisfaire les attentes de l’acteur de l’application.
L’application doit permettre à l’internaute de :
 S’inscrire : L’internaute peut créer un profil dans notre plateforme afin de devenir un
client.
 Consulter site : L’internaute peut consulter notre plateforme pour savoir les types
d’assurances existantes.
L’application doit permettre au client de :
 S’authentifier : Le client après avoir créé son compte il peut connecter à son profil avec
son email et mot de passe.
 Gérer profil : chaque client peut consulter son profil, le supprimer ou modifier ses
informations.
 Gérer assurance : le client peut déposer ou annuler une demande d’assurance, payer
ses factures en ligne et bien sûr consulter la liste des contrats de ces assurances.
 Gérer remboursement : le client peut demander un remboursement quand l'objet

assuré est endommagé. Le remboursement n'est pas en argent, soit l objet endommagé
est réparée ou bien remplacé par un autre.
 Consulter notifications : une notification est envoyée au client pour l’informer de l’état
d’avancement de sa demande de remboursement ou d’assurance ou bien d’une facture
qu’il doit payer.
 Consulter facture : tout utilisateur a la possibilité de consulter ses factures.
 Communiquer via un système de chat : Le client peut échanger des messages avec
l'administrateur.
L’application doit permettre au personnel de :

 S’authentifier : le personnel saisit son login et son mot de passe pour accéder à son espace
administratif.
 Vérifier payement : Le personnel est permis de valider chaque payement fait par les clients.
11
 Gérer les demandes de remboursement : le personnel a un accès à la liste des demandes de

remboursement et il a le droit de changer le statut d’une demande après avoir étudié sa
légitimité.
L’application doit permettre à l’Admin de :
 S’authentifier : L'admin saisit son login et son mot de passe pour accéder à l'espace
administratif.
 Gérer les demandes d’assurance : L'admin peut accepter ou refuser une demande
d'assurance selon plusieurs critères comme l’état de l’objet à assurer ou bien son type.
 Consulter la liste des clients inscrits : Le super admin a le droit de consulter la liste des
clients inscrits dans notre plateforme.
 Communiquer via un système de chat : L'admin peut communiquer avec les clients au
sein de son espace personnalisé.
L’application doit permettre au Super Admin de :
 S'authentifier : Le super admin saisit son login et son mot de passe pour accéder à
l'espace administratif.
 Gérer Admin : Le super admin peut ajouter, supprimer un admin ou modifier ses
privilèges.
 Gérer Personnel : Le super admin peut ajouter, supprimer un personnel ou modifier

ses privilèges.
1.3. Besoins non fonctionnels

Les besoins non-fonctionnels ont comme but de décrire les conditions requises qui
permettent d’assurer le bon fonctionnement du système et optimiser les services qu’il fournit
vis-à-vis l’utilisateur. Notre application doit répondre aux critères suivants :
 Sécurité : L'application doit garantir à l'utilisateur connecté l'intégrité et la confidentialité

de ses données. La sécurité du système est assurée par l'authentification des clients par un
login et un mot de passe crypté.
 Performance : Au niveau d'un système informatique la performance ne se définit pas

uniquement par les temps de réponse résultants des applications aux utilisateurs, cette
notion est plus vaste et comprend les aspects suivants : Les temps de réponse, la
disponibilité du système, la robustesse.
 L’ergonomie : On qualifie d'ergonomique un site web utile, accessible et qui donne

satisfaction à l'utilisateur et qui a pour objectif d'améliorer les interactions homme-
machine, la facilité d'utilisation et d'apprentissage des produits interactifs.
12
2. Spécification des besoins fonctionnels

Cette phase consiste à comprendre le contexte du système. Il s'agit de déterminer les
fonctionnalités et les acteurs les plus pertinents, de préciser les risques les plus critiques et
d'identifier les cas d'utilisation initiaux.
2.1. Diagramme de cas d’utilisation général

La figure 2.1 illustre le diagramme de cas d'utilisation général de notre système.
13
Figure 2.1 : Diagramme de cas d'utilisation général
14
2.2. Diagrammes de cas d’utilisation détaillés

2.2.1. Diagramme de cas d’utilisation détaillé de l’acteur « Client »
La figure 2.2 illustre les fonctionnalités à fournir à l’acteur « client » après l’authentification.
Un client peut gérer son compte, ses assurances et ses demandes de remboursement. Aussi, il
a la possibilité de consulter ses factures et de communiquer avec l’admin via un système de
chat.
Figure 2.2 : Diagramme de cas d'utilisation du l’acteur « Client »

2.2.2. Diagramme de cas d’utilisation détaillé de l’acteur « Personnel »
La figure 2.3. Illustre les fonctionnalités à fournir à l’acteur « personnel » après
l’authentification. Nous citons quelques fonctionnalités : le personnel peut consulter les
demandes de remboursement, étudier leurs légitimités et modifier leurs statuts. Aussi, Il peut
vérifier les payements effectués par les clients.
15
Figure 2.3 : Diagramme de cas d'utilisation du l’acteur « Personnel »

2.2.3. Diagramme de cas d’utilisation détaillé de l’acteur « Admin »
La figure 2.4 illustre les fonctionnalités à fournir à l’acteur « admin ». Nous citons quelques-
unes : un admin peut accepter ou refuser une demande d’assurance, il peut consulter la liste
des clients inscrits et il peut communiquer avec le personnel ou les clients via un système de
chat.
Figure 2.4 : Diagramme de cas d'utilisation du l’acteur « Admin »

2.2.4. Diagramme de cas d’utilisation détaillé de l’acteur « Super Admin »
La figure 2.5 illustre les fonctionnalités à fournir à l’acteur « Super Admin ». Cet acteur
administratif a la permission de consulter et modifier la liste de personnel et la liste des
admins.
16
Figure 2.5 : Diagramme de cas d'utilisation du l’acteur « SuperAdmin »
2.3. Diagrammes de séquence acteur-système

Les diagrammes de séquences permettent de montrer les interactions des éléments du
système entre eux et avec les acteurs.
2.3.1. Diagramme de séquence « Gérer assurance »
Le tableau 2.1 et la figure 2.6 décrivent le diagramme de séquence « Gérer assurance ».
Table 2.1 : Description du C.U « Gérer assurance »
Cas d’utilisation Gérer assurances
Acteur Client
Intérêt Elle permet au client de souscrire ou annuler une assurance
Précondition Client authentifié
Scénario nominal Souscrire assurance :

-Le client demande la page de souscription d’une assurance.
- Le système affiche le formulaire de souscription d’une assurance.
-Le client remplit le formulaire et valide.
- Le système vérifie la validité des informations.
17
- Le système renvoie un message de confirmation au client.

Annuler assurance :
- Le client demande la page de ses contrats d’assurance.
- Le système affiche la page des assurances inscrites.
- Le client choisit le contrat à annuler.
- Le système affiche les détails de l’assurance sélectionnée.
- Le client demande l’annulation de l’assurance.
- Le système confirme l’annulation de la souscription.
Post condition Page de contrats d’assurance mise à jour.
Exception - Si le formulaire de la demande contient des champs vides ou des

données invalides le système affiche un message d’erreur.
- Lors de l’annulation d’une souscription le système vérifie s’il y-a des
factures non payées, si c’est le cas le système affiche un message d’erreur.
Figure 2.6 : Diagramme de séquence « Gérer assurance »
18
2.3.2. Diagramme de séquence « Demande de remboursement »

Le tableau 2.2 et la figure 2.7 décrivent le diagramme de séquence « Demande de
remboursement ».
Table 2.2 : Description du C.U « Demande de remboursement »
Cas d’utilisation Demande de remboursement
Acteur Client
Intérêt Elle permet au client de faire une demande pour réparer l’objet assuré au cas
d’incident.
Scénario nominal -Le client demande la page de remboursement.

-le système affiche le formulaire de remboursement.
-Le client remplit le formulaire et valide.
-le système demande la confirmation de la demande.
-le client confirme la demande.
-le système enregistre la demande et informe l’acteur que la demande est
envoyée avec sucés.
Post condition La demande de remboursement est envoyée.
Exception -Si le formulaire de la demande contient des champs vides ou des données
invalides Le système affiche un message d’erreur.
19
Figure 2.7 : Diagramme de séquence « Demande de remboursement »

2.3.3. Diagramme de séquence « Gérer personnel »
Le tableau 2.3 et la figure 2.8 décrivent le diagramme de séquence « Gérer personnel ».
Table 2.3 : Description du C.U « Gérer personnel »

Cas d’utilisation Gérer personnel
Acteur Super Admin
Intérêt Elle permet au client de faire une demande pour réparer l’objet assuré au
cas d’incident.
Scénario nominal Le super admin demande la page de gestion de personnel.

Le système affiche la page de gestion de personnel.
20
Ajouter personnel
-Le super admin demande l’ajout d’un personnel.
-le système affiche la page d’ajout.
-Le super admin remplit le formulaire par les informations nécessaires et
valide.
-le système vérifie la validité des informations.
- le système renvoie la page de personnel mise à jour avec un message.
Modifier personnel :
-Le super admin choisit le personnel à modifier.
-le système affiche les champs de personnel choisi.
-le super admin fait les modifications adéquates et confirme.
-Le système modifie le profil de personnel.
Supprimer personnel :
-Le super admin choisit le personnel à supprimer.
-le système demande la confirmation.
-le super admin confirme.
-Le système supprime le personnel.
Post condition La liste du personnel mise à jour.
Exception -S’il-y a des champs vides ou ils contiennent des données invalides Le
système affiche un message d’erreur.
-Si le personnel ajouté existe déjà dans la base, le système affiche un
message d’erreur.
21
Figure 2.8 : Diagramme de séquence « Gérer personnel »
3. Choix technique
Pour le coté front-end nous allons utiliser la bibliothèque React JS et le framework Laravel
pour le coté back-end.
3.1. Bibliothèque React

ReactJS [6] est considéré comme une bibliothèque plutôt que comme un framework. C’est une
bibliothèque JavaScript open source développée par facebook depuis 2013.
22
Le but principal de cette bibliothèque est de faciliter la création d'application web mono-page,
via la création de composants réutilisables et dépendants d’état.
Nous avons opté pour la bibliothèque React JS pour les raisons suivantes :
 La Flexibilité : Avec React, la création d’applications est simplifiée grâce à son API qui
permet une utilisation facile des composants et à l’utilisation d’un DOM virtuel.
 Performance : React a été conçu pour offrir des performances élevées grâce à la mise en
œuvre d’un DOM virtuel ce qui rend les applications complexes extrêmement rapides.
La figure 2.9 présente un diagramme qui compare l’utilisation des frameworks JS les plus
utilisées.
Figure 2.9 : utilisation des frameworks JS les plus utilisées selon google trends
3.2. Framework Laravel

Laravel [7] est un framework web PHP open-source gratuit, créé par Taylor Otwell depuis
2011 et destiné au développement d'applications web suivant le modèle architectural modèle
– vue – contrôleur (MVC).
Nous avons opté pour la framework Laravel pour les raisons suivantes :
 Sécurité : Laravel est l’un des frameworks les plus robustes et sécurisés. Parmi les
mesures de sécurité [8] qu’il offre : cryptage des mots de passe[8] lors de
l'enregistrement dans la BD, protection contre les injections SQL [8] et protection
contre les attaques de type CSRF (Cross-site request forgery) [8].
 Performances améliorées : Laravel supporte divers outils pour fournir une excellente
performance aux applications web tels que Memcached et Redis [9], systèmes de
cache performant permettant de stocker pour un temps limité des données sur la
23
mémoire vive, ce qui permet de renvoyer directement une donnée à l’utilisateur sans
avoir besoin d'accéder à la base de données.
La figure 2.10 présente une comparaison entre les frameworks PHP les plus utilisées.
Figure 2.10 : Les frameworks PHP les plus utilisés selon google trends
Conclusion
Dans ce chapitre, nous avons identifié les acteurs, les besoins fonctionnels et non-fonctionnels
de notre système à l’aide de diagrammes de cas d’utilisation et de séquence acteur système.
Aussi nous avons présenté le choix technique des frameworks à utiliser. Le troisième chapitre
sera consacré à la conception de notre application
24
Chapitre III. Conception
Introduction
Dans ce chapitre nous allons entamer une partie importante du développement de
l’application qui constitue un pont entre la spécification et la réalisation. Nous commencerons
par la présentation de l’architecteur générale de notre application ensuite la conception
générale puis la conception détaillée comprenant les vues statiques via les diagrammes de
classes. En fin nous clôturerons ce chapitre par quelques fonctionnalités de l'application à
l'aide des maquettes.
1. Modèle architectural
Après avoir fait le choix de la méthodologie 2TUP, la démarche de conception sera en
adéquation avec l'architecture de l'application
Avant de développer notre application, il est indispensable de choisir un modèle de
conception (pattern design). Parmi les patrons les plus connues, nous mentionnons
l’architecture 3-tiers et le patron Modèle-Vue-Contrôleur (MVC).
1.1. L’architecture 3-tiers

Ce modèle d’architecture, décrit par la figure 3.1, se décompose en trois niveaux logiques bien
distincts qui ont chacune un rôle bien défini :
 La couche de présentation correspond à l’interface utilisateur. Son rôle est d’afficher

les données et de permettre à l’utilisateur final d’interagir avec ces dernières.
 La couche métier est en charge d’appliquer et de respecter les règles métiers (ou actes
de gestion). Avec ce modèle d’architecture, la logique applicative et la sécurité sont
implémentées dans cette couche.
 La couche d’accès aux données, quant à elle, assure la persistance des données qui
doivent être conservées.
25
Chapitre III Conception
Figure 3.1 : L’architecture 3-tiers
1.2. Modèle MVC

L'architecture Modèle/Vue/Contrôleur (MVC) est une façon d'organiser une interface
graphique d'un programme. Elle consiste à distinguer trois entités distinctes qui sont,
le modèle, la vue et le contrôleur ayant chacun un rôle précis dans l'interface. La figue 3.2
décrit l’architecture MVC.
Dans l'architecture MVC, les rôles des trois entités sont les suivants :
 Le modèle : il gère les données de site, son rôle est de récupérer les informations dans
la base de données, de les organiser et de les assembler pour qu'elles puissent ensuite
être traitées par le contrôleur
 La vue : elle représente l’interface utilisateur, sa première tâche est d'afficher les
données qu'elle a récupérées auprès du modèle. Sa seconde tâche est de recevoir
toutes les actions de l'utilisateur. Ses différents événements sont envoyés au
contrôleur.
 Le contrôleur : cette partie est chargée de la synchronisation du modèle et de la vue.

C'est en quelque sorte l'intermédiaire entre le modèle et la vue : le contrôleur demande
au modèle les données, les analyser, prendre des décisions et finalement les déléguer
à la vue.
26
Figure 3.2 : L'architecture du modèle MVC
1.3. Architecture adoptée

L'architecture générale de notre application s'inspire de l'architecture 3-tier. Elle est illustrée
par la figure 3.3.
Figure 3.3 : L'architecture de notre application

Le front-end correspond à la partie présentation de l’architecture 3-tiers. Il comporte deux
couches : la couche « vue » qui représente les interfaces graphiques via lesquelles l’utilisateur
interagit avec le système et la couche « Service » qui permet de structurer les traitements et
d’interagir avec le serveur.
Le back-end correspond à la partie métier et la partie accès aux données de l’architecture 3-
tiers. La première partie comporte deux couches : la couche « Routing » qui permet de router
les requêtes vers leurs contrôleurs appropriés et la couche « Controller » qui permet de
recevoir tous les événements de l'utilisateur et enclenche les actions à effectuer. Quant à la
deuxième partie elle comporte une seule couche :la couche « model » qui représente les entités
métiers gérés par notre application.
Dans la section 3.1, nous détaillons de plus le contenu de chaque couche.
27
2. Conception de la base de données

La conception d'une base de données est l'organisation des données selon un modèle. Elle aide
à déterminer comment les données doivent être stockées et comment ils sont liés.
Donc, Nous commençons par présenter le modèle conceptuel de données (MCD) et par la suite
le modèle Logique de données (MLD).
2.1. Modèle conceptuel de données (MCD)

Un MCD décrit les différentes entités ainsi que les relations qui existent entre elles. La figure
3.4 illustre le modèle conceptuel de notre base de données. Le tableau 3.1 donne les détails de
description de chaque entité.
Figure 3.4 : Modèle Conceptuel de données (MCD)
28
Table 3.1 : Les entités du modèle conceptuel de données

Entités Description Attributs et type
User Tout utilisateur de la plateforme. -Id_User: String

-Nom: String
-Prénom: String
-E-mail: String
-Num_CIN: String
-NuméroTél: Sring
-photo: Binary
Client Elle hérite la classe « User » et -DateInscription : Date
contient les attributs
supplémentaires relatives au
client.
Personnel Elle hérite la classe « User » et -DateEmbauche : Date
contient les attributs -Ancienneté : int
personnel.
Admin Elle hérite la classe « User » et -DateEmbauche : Date
supplémentaires relatives à
l’admin
SuperAdmin Elle hérite la classe « User » et -DateEmbauche : Date
superAdmin
Facture Elle enregistre les coordonnées -Id_Facture: String
du client, les frais de l’assurance -Payée: Booléen
et les informations qui concerne -DatePayement: Date
l’objet assuré.
Notification Elle dépend du chaque client et -Id_Notif : String
permet lui informer du contenu -DateEnvoi : Date
d'un acte ou d’une action.
Remboursement Elle contient les informations -Id_Remboursement : String
qui concerne le client, -EtatDemande : Enum
l’assurance, l’objet assuré et la -Réponse : String
demande de rembourssement. -DateRéponse : Date
Assurance Elle contient toutes les -Id_Assurance: String
informations sur l’assurance. -Type: String
-Pack: String
-DateDebut: Date
-DateFin: Date
-Photo: Binary
-Annulée: Boolean
ObjetAssuré Elle décrit l’objet que le client va -Id_Objet: String
assurer. -NomObjet: String
-Etat: String
-Type: String
-Photo: Binary
29
2.2. Modèle Logique de données (MLD)

Un modèle MCD peut être organisé selon différents modèles logiques de données. Dans notre
projet, nous avons opté pour le modèle relationnel qui répond bien à nos besoins non
fonctionnels.
En appliquant les règles de transformations du modèle E/A vers un modèle relationnel, nous
obtenons le schéma relationnel suivant, illustré dans la figure 3.5. Nous distinguons 9
relations, où 8 relations correspondent aux 8 entités du modèle conceptuel. La relation
Message est le résultat de l’association « communiquer » entre « Client » et « Admin ».
Personnel (Id_Personnel, Nom, Prénom, NumCin, DateEmbauche, Anciennetè, Photo,
NuméroTel, E-mail)
Client (Id_Client, Nom, Prénom, NumCin, Photo, Email, NuméroTel, DateInscription)
Admin (Id_Admin, Nom, Prénom, NumCin, DateEmbauche, Ancienneté, Photo, NuméroTel,

Email)
Assurance (Id_Assurance, Type, Pack, Date_Debut, Date_Fin, Photo, Annulée, #Id_Admin,

#Id_Client, #Id_Objet)
ObjetAssuré (Id_Objet, NomObjet, Type, Etat, Photo)
Remboursement (Id_Remboursement, EtatDemande, Réponse, DateReponse, #Id_Personnel,

#Id_Assurance)
Facture (Id_Facture, Payée, DatePayement,#Id_Assurance)
Notification (Id_Notif, DateEnvoi, #Id_Client)
Message (#Id_Client, #Id_Admin, Timestamp, Contenu,ClientToAdmin)
30
Figure 3.5 : Le Modèle Logique de Données
3. Conception logicielle détaillée

Dans La conception logicielle détaillée nous allons donner une vue statique avec le diagramme
de classe et une vue dynamique avec le diagramme de séquence.
3.1. Vue statique : Diagramme de classe

Dans la section Modèle architecturale adopté, nous avons identifié les différentes couches
logicielles de notre application. Dans ce qui suit nous détaillons les composants logiciels de
chacune de ces couches.
Comme illustré dans la figure 3.6, nous présentons les classes de notre application selon les
couches suivantes :
 Vue : cette couche comporte les composants « Components » qui correspondent aux
interfaces graphiques via lesquelles l’utilisateur interagit avec le système et provoque
des évènements.
Dans la couche Vue nous avons défini les classes suivantes : « Client »,
« Remboursement», « Assurance », « Facture », « Personnel», « Admin » ,
« Notification », « Message », « objetAssuré ».
 Service : cette couche comporte les classes « Service » qui permettent de structurer les
traitements et interagir avec le serveur.
31
Dans la couche Service nous avons défini les classes suivantes : «Client.service», «
Remboursement.service », « Assurance.service », « Facture.service » , «
Personnel.service », «Admin.service» , « Notification.service», « Message.service»,
« objetAssuré.service»
 Routing : Le routage dans Laravel permet de router une requête vers son contrôleur
approprié. Ainsi, nous distinguons un routeur pour chaque contrôleur. Par exemple
« Facture.routing » définit la logique de routage des requêtes vers le contrôleur
« Facture ».
 Controller : cette couche comporte les contrôleurs qui permettent de reçevoir tous les
événements de l'utilisateur et enclenche les actions à effectuer.
Dans la couche Controller nous avons défini les classes suivantes : «Client.controller»,
« Remboursement.controller », « Assurance.controller », «Facture.controller » ,
«Personnel.controller»,«Admin.controller»« Notification.controller», « Message.contr
oller », « objetAssuré.controller »
 Model : cette couche représente les entités métiers gérés par notre application. Il y a
une analogie entre les entités de cette couche et les relations/tableaux de la base de
données. En effet, pour chaque entité il correspond un tableau qui permet la gestion de
la persistance des instances de l’entité correspondante. A partir des classes de cette
couche, le Framework LARAVEL génère automatiquement la couche DAL (Data Access
Layer) qui permet d’interagir avec la base de données.
Dans la couche Model nous avons défini les classes suivantes : « Client », «
Remboursement », « Assurance », « Facture », « Personnel », «Admin » ,
« Notification », « Message », « ObjetAssuré ».
32
Figure 3.6 : Diagramme de classe
33
3.2. Vue dynamique : diagramme de séquence

Dans cette partie nous présentons le déroulement des traitements et des interactions entre
les différentes couches via des diagrammes de séquence.
3.2.1. Diagramme de séquence général
Dans ce qui suit, nous présentons une vue générale des interactions entre les différentes
couches logicielles de notre application. Comme illustré dans la figure 3.7, le rôle d’un
composant est de capter une requête envoyée par l’utilisateur et de provoquer le service
correspondant pour établir une connexion avec le backend. Une fois la connexion est établie,
Laravel route la requête vers le contrôleur approprié. Pour interagir avec la base de données
le contrôleur sollicite la couche model (et la couche DAL par conséquence).
34
Figure 3.7 : Diagramme de séquence général
35
3.2.2. Diagramme de séquences « AjouterAdmin »

La figure 3.8 illustre le diagramme de séquence pour ajouter un administrateur. Ce diagramme
suit le modèle d’interaction générale présenté dans ma section « diagramme de séquence
général ». Coté front-end, le composant invoqué est « AdminComponentt » et le service
sollicité est « AdminService ». Coté back-end, la requête sera redirigée vers le contrôleur
« AdminController » qui sollicitera l’entité « Admin ».
Figure 3.8 : Diagramme de séquence « AjouterAdmin »
36
3.2.3. Diagramme de séquences « ConsulterListeRemboursement »

La figure 3.9 illustre le diagramme de séquence pour consulter la liste de remboursement d’un
client. Ce diagramme suit le modèle d’interaction générale présenté dans ma section
« diagramme de séquence général ». Coté front-end, le composant invoqué est
« RefundComponenet » et le service sollicité est « RefundService ». Coté back-end, la requête
sera redirigée vers le contrôleur « RefundController » qui sollicitera l’entité « Refund».
Figure 3.9 : Diagramme de séquence « ConsulterListeRemboursement »
37
3.2.4. Diagramme de séquences « SouscrireAssurance »

La figure 3.10 illustre le diagramme de séquence pour souscrire une assurance. Ce diagramme
suit le modèle d’interaction générale présenté dans ma section « diagramme de séquence
général ». Coté front-end, le composant invoqué est « InsuranceComponent » et le service
sollicité est « InsuranceService ». Coté back-end, la requête sera redirigée vers le contrôleur
« InsuranceController » qui sollicitera l’entité « Insurance».
Figure 3.10 : Diagramme de séquence « SouscrireAssurance »
38
3.3. Conception des interfaces graphiques

3.3.1. Diagramme de navigation
Le diagramme de navigation permet d’identifier les différentes interfaces utilisateurs, ainsi
que les différents liens de navigation entre ces interfaces. La figure 3.11 illustre le diagramme
de navigation de notre application.
39
Figure 3.11 : Diagramme de navigation
40
3.3.2. Maquettage
Le maquettage est une étape indispensable, il permet de donne une idée sur le site et sur les
différentes interfaces sous forme de schéma. Dans ce qui suit, nous allons illustrer quelques
maquettes de notre application :
 Interface du cas d’utilisation « Gérer remboursement » de l’acteur « Personnel » :

Le personnel est permis de voir les détails d’une demande de remboursement, de modifier
son statut et d’en répondre après avoir vérifié sa légitimité.
Figure 3.12 : Interface "Gérer remboursement"
 Interface du cas d’utilisation « Souscrire assurance » de l’acteur « Client » :

A l'aide de cette interface, le client peut assurer un objet.
41
Figure 3.13 : Interface « souscrire assurance »
 Interface du cas d’utilisation « Consulter assurance » de l’acteur « Client » :

A l'aide de cette interface, le client peut consulter ses assurances inscrites avec leurs détails
et il a la possibilité de télécharger ses contrats.
Figure 3.14 : Interface « Consulter assurance »
42
 Interface du cas d’utilisation « Ajouter Admin » de l’acteur « SuperAdmin » :

A travers cette interface le superAdmin peut voir la liste des admins inscrits dans la base. Il
peut ajouter un admin ou le supprimer comme il peut consulter ou modifier ses détails.
Figure 3.15 : Interface « Consulter la liste des admins »
Conclusion
Dans ce chapitre, nous avons détaillé les principales étapes de la conception de notre projet.
En effet, nous avons commencé par présenter l’architecture générale de notre application.
Ensuite, nous avons détaillé la conception de la base de données via le modèle conceptuel de
données et le modèle relationnel. Puis nous avons passé à la conception logicielle en donnant
le diagramme de classe qui détaille la vue statique et des diagrammes de séquence qui
détaillent la vue dynamique de notre système. Enfin nous avons présenté la conception
graphique des interfaces utilisateur en donnant les différents liens de navigation entre elles.
43
Chapitre IV. Réalisation
Introduction
Dans ce dernier chapitre nous allons décrire les différents outils et frameworks utilisés pour
la réalisation de notre application. Ainsi, nous présenterons aussi quelques interfaces de notre
application.
1. Environnement et outils de travail

Dans cette partie, nous présentons les différents outils matériels et logiciels utilisés pour
l’implémentation de notre application.
1.1. Environnement matériel

Pour le développement de cette application, Nous avons utilisé deux PC ayant les
caractéristiques suivantes :
Tableau 4.1 : Caractéristique de l'environnement matériel

PC 1 PC 2
Marque Asus Asus
Processeur i5 i7
RAM 8Go 8Go
Disque dur 1 To 1To
Système d'exploitation Windows 10 professionnel Windows 10 professionnel
44
Chapitre VI Réalisation
1.2. Environnement logiciel

1.2.1. Environnements et technologies de développement
Dans ce qui suit, nous dresserons la liste des logiciels et des outils qui ont été utilisés pour le
développement et l’implémentation de notre application, ainsi que pour élaborer les
diagrammes de ce rapport. Nous détaillerons en particulier dans les sections qui suivent les
deux frameworks ReactJs et Laravel.
Tableau 4.2 : Environnements et technologies de développement
Environnement Description
Visual Studio Code Visual Studio Code est un éditeur de code open-source,
gratuit et multi-plateforme, développé par Microsoft.
Principalement conçu pour le développement
d'application avec JavaScript, Type Script et Node.js,
l'éditeur peut s'adapter à d'autres types de langages
grâce à un système d'extension bien fourni.
WampServer WampServer est une plateforme de développement

Web de type WAMP, permettant de faire fonctionner
localement (sans avoir à se connecter à un serveur
externe) des scripts PHP. WampServer n'est pas un
logiciel, mais un environnement comprenant trois
serveurs (Apache, MySQL et MariaDB), un interpréteur
de script (PHP), ainsi que phpMyAdmin pour
l'administration Web des bases MySQL.
Postman Postman est un logiciel qui permet de tester des API

pour déterminer s’ils répondent aux attentes en
matière de fonctionnalité, de fiabilité, de performance
et de sécurité.
PhpMyAdmin PhpMyAdmin est un outil logiciel gratuit écrit en PHP,

destiné à gérer l'administration de MySQL sur le Web.
Les opérations fréquemment utilisées (gestion des
bases de données, des tables, des colonnes, des
relations, etc.) peuvent être effectuées via l'interface
utilisateur, tout en permettant d'exécuter directement
n'importe quelle instruction SQL.
45
Mysql MySQL est un système de gestion de bases de données

relationnelles open source développé et supporté par
Oracle.
Balsamiq mockups Balsamiq mockups C’est un outil permettant de créer

facilement des prototypes d'IHM.
StarUml StarUML est un logiciel de modélisation qui permet de

gérer la plupart des diagrammes spécifiés dans la
norme UML (Unified Modeling Language).
Draw.io draw.io est une application de création de diagrammes

et schémas en ligne qui permet de créer des
diagrammes pour toutes les applications.
ReactJS React est une bibliothèque JavaScript qui permet de

créer des applications monopage.
Laravel Laravel est un framework web open-source écrit en

PHP qui respecte le principe modèle-vue-contrôleur et
entièrement développé en programmation orientée
objet.
46
2. Bibliothèque React
L’application cliente est créée par la bibliothèque ReactJS. Cette bibliothèque permet de créer
des interfaces utilisateur et de faciliter la création d'application web mono-page via la création
de composants dépendants.
Pour mettre en place un projet React, il faut tout d’abord installer l’environnement d'exécution
NodeJS du son site officiel.
Après avoir installé le nodeJS nous sommes en mesure d’implémenter notre application.
Dans ce cas, Il suffit de lancer la commande suivante dans le Cmd pour créer un nouveau
projet :
Ensuite, une fois l'installation est terminée, nous devons ouvrir le dossier de projet :
Et lancer le serveur :
Pour la structure du projet il n’y a pas une par défaut, mais l’approche la plus populaire
consiste à placer les fichiers CSS, le JS et les tests ensemble dans des dossiers groupés par
fonctionnalité ou par route comme il est montré par la figure suivante :
47
Figure 4.1 : Structure de notre projet React
2.1. React DOM

Un DOM (Document Object Model) est la représentation objet d’une page web sous forme
d’un arbre permettant de lire et de manipuler le contenu de la page. La figure 4.2 illustre un
exemple d’un code HTML et le DOM correspondant à droite.
Figure 4.2 : Exemple d'un DOM
48
De ce fait, React crée un DOM virtuel qui est une copie du DOM original et lorsque des
changements sont effectués sur cette copie, une comparaison entre le DOM original et le
VDOM est effectuée pour ne mettre à jour que les composants modifiés et pour éviter les
modifications inutiles du DOM original qui sont coûteuses du point de vue des performances
car les modifications apportées au DOM entraînent généralement un nouveau rendu de la
page.
2.2. Le cycle de vie d’un composant React

Les composants sont des éléments indépendants et réutilisables qui constituent l’application.
Un composant est une classe ou une fonction JavaScript qui accepte des propriétés (props) et
renvoie un code qui décrit comment une section de l'interface utilisateur doit apparaître.
Chaque composant React passe par différentes étapes qu’on appelle le cycle de vie d'un
composant. Celui-ci se découpe en 3 parties :
 Mount : Il intervient quand une instance du composant est créée dans le DOM.
 Update : Ce cycle de vie est déclenché par un changement d'état du composant.
 Unmount : cette méthode est appelée une fois qu'un composant est retiré du DOM.
3. Framework Laravel
Laravel est un framework web PHP open-source, destiné au développement d'applications
web suivant le modèle architectural modèle – vue – contrôleur (MVC).
3.1. Organisation d'un projet Laravel

La figure 4.3 montre la structure dénèral d’un projet Laravel.Nous détaillons dans ce qui suit
le contenu de chaque dossier.
 App : Le dossier app est le dossier le plus important dans un projet laravel. Celui-ci
contient le code de l’application, les fonctions, les classes, etc.
 Public : Le dossier public contient tous les fichiers accessibles directement par les
visiteurs. Par exemple, les images publiques du site doivent être dans le dossier public
(ou dans un sous-dossier du dossier public).
 Config : Le dossier config permet la configuration du framework. À l'intérieur, chaque

fichier correspond à une fonctionnalité configurable. Par exemple, le fichier
config/database.php contient un tableau PHP avec différentes valeurs de configuration
pour l'URL de la base de données, l'utilisateur, le mot de passe, etc
 Vendor : Le dossier vendor contient toutes les dépendances PHP téléchargées par
Composer. Nous pouvons trouver dans vendor/laravel/framework le code source de
Laravel. Les fichiers de ce dossier ne doivent pas être changés car ces modifications
seront écrasées par le Composer dans la prochaine mise à jour.
49
Figure 4.3 : Organisation de notre projet Laravel
3.2. L’architecture de Laravel

Comme une grande partie des autres Framework php, Laravel a une architecture dite MVC[10]
(Model-View-Controller), la séparation des composants d’une application en ces trois
catégories permet une clarté de l’architecture et simplifie le développement.
La figure 4.4 décrit l’architecture MVC de Laravel :
50
Figure 4.4 : L’architecture de Laravel
 Models : le Modèle représente les entités métiers manipulées par l’application et qui
sont stockées dans la base de données. Avec la couche DAL (Data Access Layer), il
permet de récupérer, d'insérer et de mettre à jour les données correspondantes dans
la base de données. La figure 4.5 illustre l’entité métier « Client » de la couche « model »
de notre application.
Figure 4.5 : Extrait du code de l’entité « Client »

 Controllers : implémentent la logique métier de l’application. Il interagit avec des
entités métiers et la base de données et retourne des éléments de données à la couche
View.La figure 4.7 illustre un extrait de contrôleurs de notre application
51
Figure 4.6 : Extrait de contrôleurs de notre application
 Le routing : le routing est un mécanisme qui effectue le mapping des requêtes vers les
contrôleurs appropriés. La figure 4.7 illustre quelques routes de notre application.
Figure 4.7 : Extrait de routes de notre application
 View : les vues définissent le rendu graphique à afficher à l’utilisateur. La figure 4.8
illustre un exemple de vue de notre application
52
Figure 4.8 : Extrait du code de « LogIn »
3.3. Manipulation de données

Laravel met à notre disposition un fichier de configuration est un local où vous mettez toute
la configuration de votre environnement,
Comme les informations d'identification de la base de données, les pilotes de cache, clé de
cryptage.etc. Dans cette section nous allons focaliser notre attention sur la configuration de la
base de données.
La figure 4.9 illustre le fichier de configuration de la base de données dans laravel.
Figure 4.9 : Le fichier de configuration de notre base de données

 Migration avec Laravel
Laravel offre la possibilité de créer une base de données sans passer par un gestionnaire de
base tel que phpMyAdmin, ou sql lite.
La commande make:migration permet de générer une migration de base de données. La
nouvelle migration sera placée dans le répertoire database/migrations comme l’illustre la
figure 4.10.
53
Figure 4.10 : Extrait du répertoire « Migration » de notre application

 Seeders avec Laravel
Un seeder est une classe spéciale utilisée pour générer et remplir des tables avec des données
(seeds) de test ou d’initialisation du projet.
La commande make:seeder permet de générer une nouvelle colonne dans la base de données.
Tous les seeders générés par le framework seront placés dans le répertoire
database/seeders.La figure 4.11 donne un exemple d’une classe seeder de notre application.
Figure 4.11 : Extrait du code « Seeder » de la table « User »
3.4. Invite de commande « Artisan »

Artisan est le nom de l'interface de ligne de commande de Laravel. Il fournit un certain nombre
de commandes utiles pour l’utilisation lors du développement de l’application. Le tableau 4.3
décrit les commandes importantes de Laravel.
54
Tableau 4.3 : les commandes importantes de Laravel

Commande Utilisation de la commande
Laravel new projectName Pour Créer un projet laravel
php artisan make :controller ControllerName Pour créer un contrôleur
php artisan make :resource ResourceName Pour créer une ressource
php artisan make : provider ProviderName Pour créer un service
php artisan make : model Test Pour créer un modèle
php artisan make : migration Test Pour créer un squelette de migration
php artisan migrate Pour lancer une migration
php artisan serve Pour lancer le server
4. Travail réalisé
Dans cette section nous allons présenter quelques interfaces graphiques de l’application qui
illustrent les différents cas d'utilisation.
4.1. Interface « Login »

Le client doit, tout d’abord, se connecter via son Login/Mot de passe afin d’accéder aux
différentes fonctionnalités offertes par l’application.
Figure 4.12 : Interface « Login »
55
4.2. Interface « Register for Insurance »

Une fois identifée, cette interface permet au client de passer une demande d’assurance pour
assurer un objet. La figure 4.13 décrit l'interface « Register for Insurance ».
Figure 4.13 : Interface « Register for Insurance »
4.3. Interface « My Insurance Requests »

Cette interface permet au client de consulter ses demandes d’assurance. La figure 4.14 décrit
l'interface « My insurance requests ».
Figure 4.14 : Interface « My Insurance Requests »
56
4.4. Interface « Insurance Request »

La demande d’assurance que le salarié a déjà effectuée et qui a été expliquée dans la figure
précédente est transmise maintenant vers l’admin. Nous basculons, donc, vers l’espace de ce
dernier. La vue « Mes Tâches » contient toutes les demandes, qui contient toutes les
informations saisies par le client lors de l’envoi de sa demande y compris toutes les pièces
justificatives, à valider ou à refuser par cet admin.
Figure 4.15 : Vue « Insurance Request »
4.5. Interface « Add Staff »

La figure 4.16 et la figure 4.17 montrent respectivement les interfaces d’ajout d’un nouveau
personnel et la liste, mise à jour, de personnels inscrit dans la base suite à cet ajout.
Figure 4.16 : Interface « Add staff »
57
Figure 4.17 : Interface « Consult staff list »
5. Etat de réalisation:
Nous avons réalisé 70% des fonctionnalités spécifiées, il nous reste 30%. Par catégorie la
figure 4.18 décrit les fonctionnalités réalisées et non réalisées.
Figure 4.18 : Etat de réalisation des fonctionnalités
58
Conclusion
Au cours de ce dernier chapitre, nous avons commencé par la présentation des
environnements logiciels et matériels que nous avons utilisés. Ensuite, nous avons décrit les
frameworks adoptées dans le développement de notre application à savoir ReactJS et Laravel.
Enfin, nous avons clôturé par quelques interfaces qui présentent les principales
fonctionnalités de notre application.
59
Conclusion générale
N otre projet intitulé « Gestion d’assurance en ligne » synthétise le travail de quatre mois
au sein de la société « Make It Happen ». Il s’agit d’une application web qui avait pour
but d’améliorer le quotidien d’une assurance et d’automatiser les tâches du personnel.
Notre rapport comporte quatre chapitres : Le premier chapitre a été consacré pour le contexte
général du projet. Nous avons commencé par le cadre de projet ensuite nous avons audité les
processus et les solutions informatiques déjà existantes afin de perfectionner le sujet de notre
projet. Puis, nous avons procédé à une comparaison entre les méthodologies existantes ce qui
nous a aidé à choisir la méthodologie 2TUP. Le deuxième chapitre a été consacré à l’analyse et
la spécification des besoins fonctionnels et non fonctionnels via les diagrammes de cas
d’utilisations et les diagrammes de séquence. Nous avons aussi justifié nos choix techniques,
ReactJs pour le front-end et Laravel pour le Back-end, pour l’implémentation de notre
application. Dans le troisième chapitre nous avons présenté le modèle architectural de notre
système, la conception de la base de données, la conception logicielle détaillée et le
maquettage de quelques interfaces de notre application. Finalement, nous avons clôturé par
le quatrième chapitre qui a été consacré à la spécification des différents outils matériels et
logiciels utilisés dans le développement de notre application et nous avons fini par des
captures d’écran du travail réalisé.
Ce travail nous a permis de mettre en œuvre les acquis théoriques que nous avons appris tout
le long de notre cursus universitaire, de consolider et d’approfondir nos connaissances dans
les bonnes pratiques de la gestion de projet vu que nous avons eu l’opportunité d’organiser
son déroulement dès le début et de maitriser les langages de programmation qui seront
certainement utiles au niveau professionnel.
En termes de perspectives, plusieurs évolutions restent envisageables pour compléter les

fonctionnalités non implémentées et nous prévoyons le développement d’une version mobile
pour le site web.
60
Webographie
[1] Site officiel du « Make it Happen » : https://mih.tn/ « Consulté le 15/03/2021 »
[2] Site officiel d’assurance GAT : https://www.gat.com.tn/ « Consulté le 02/04/2021 »
[3] Site officiel d’assurance Star : https://www.star.com.tn/index.php/fr « Consulté le 2/04/2021 »
[4] Site official d’assurance BH : https://bh-assurance.com/ « Consulté le 02/04/2021 »
[5] site de gtmetrix : https://gtmetrix.com/ « Consulté le 19/04/2021 »
[6] site officiel de React : https://fr.reactjs.org/docs/getting-started.html «Consulté le 01/05/2021»
[7] Site officiel de Laravel : https://laravel.com/docs/8.x/readme «Consulté le 01/05/2021»
[8] les mesures de sécurité offertes par Laravel : https://tinyurl.com/hbfz6h5t « Consulté le
13/06/2021 »
[9] Memcached or Redis : https://laravel.com/docs/8.x/cache « Consulté le 13/06/2021 »
[10] Architecture MVC de Laravel : https://tinyurl.com/vsksabn8 « Consulté le 01/06/2021 »
61

PFE UP Pfe Siwar Et Anis

Transféré par

Droits d'auteur :

Formats disponibles

PFE UP Pfe Siwar Et Anis

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PFE UP Pfe Siwar Et Anis

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Projet de Fin d’Etude

Diplôme national de Licence Fondamentale en sciences

Gestion des assurances en ligne

Soutenu le 23-06-2021 devant le jury composé de :

M. Imed Abbassi Président

Année universitaire : 2020 – 2021

Ce travail s’inscrit dans le cadre de l’accomplissement de notre Projet de Fin d’Études à

Mots clés : Laravel8, ReactJs,Artisan,npm,DOM.

Keywords : Laravel8, ReactJs, Artisan,npm,DOM.

A mes parents Latifa et Chams Eddine

Du profond de mon cœur, je dédie ce travail

Chapitre I. Contexte et objectifs du projet ...................................................................................................1

Figure 1.1 : Logo du « Make It Happen » .............................................................................................................. 1

Table 1.1 : Tableau comparatif entre les solutions existantes .................................................................. 5

Table 2.1 : Description du C.U « Gérer assurance » ..................................................................................... 17

Table 2.2 : Description du C.U « Demande de remboursement ».......................................................... 19

Table 2.3 : Description du C.U « Gérer personnel » ..................................................................................... 20

Table 3.1 : Les entités du modèle conceptuel de données ....................................................................... 29

Tableau 4.1 : Caractéristique de l'environnement matériel .................................................................... 44

Tableau 4.2 : Environnements et technologies de développement ..................................................... 45

Tableau 4.3 : les commandes importantes de Laravel ............................................................................... 55

 API : Application Programming Interface

 JSON : Java Script Objet Notation

 HTTP : Hypertext Transfer Protocol

 SQL : Structured Query Language

 IHM : Interface Homme Machine

 DAL : Data Access Layer

 NPM : Node Package Manager

 UML : Unified Modeling Language

 CSRF : Cross Site Request Forgery

 VDOM: Virtual Document Object Model

ctuellement, chaque entreprise d’assurance cherche le meilleur moyen pour

En effet, vu la demande de beaucoup de papiers justificatifs et la procrastination de

1. Contexte général du projet

1.1. Cadre du projet

1.2. Présentation de la société d’accueil

Figure 1.1 : Logo du « Make It Happen »

Ses domaines d’activités couvrent essentiellement :

 Développement et Mise en place de solutions Web, Mobile et Desktop.

1.3. Objectifs du projet

2.1. Solutions existantes

Figure 1.2 : Page d'accueil du site « Assurance GAT »

 Gérer leur profil.

2.1.2. Assurance STAR

Figure 1.3 : Page d'accueil du site « Assurance Star »

 Passer une réclamation.

Figure 1.4 : Page d'accueil du site « Bh Assurance »

2.1.4. Tableau comparatif

 C4 : Gestion de profil : Préserver la simplicité lors de la gestion d'un profil utilisateur

Table 1.1 : Tableau comparatif entre les solutions existantes

2.2. Critique de l’existant

2.3. Travail à réaliser

 L’Informatisation qui a comme but de supprimer la paperasserie et faire gagner du

 L’Informatisation qui a comme but de supprimer la paperasserie et faire gagner du

3.1. Méthode 2TUP: Two Tracks Unified

 Une branche fonctionnelle : elle capitalise la connaissance du métier de l’entreprise.

Figure 1.5 : Représentation de la méthodologie 2TUP

3.2. Méthode agile scrum