I

TABLE DES MATIERES

EPIGRAPHE.........................................................................................................................................III
DEDICACE..........................................................................................................................................IV
IN MEMORIAM...................................................................................................................................V
REMERCIEMENT...............................................................................................................................VI
TABLE DES ILLUSTRATIONS DES TABLEAUX.........................................................................VIII
TABLE DES ILLUSTRATIONS DES FIGURES............................................................................................VIII
SIGLES ET ABREVIATIONS.............................................................................................................IX
RESUME DU TRAVAIL......................................................................................................................X
INTRODUCTION..................................................................................................................................1
1. GENERALITES.........................................................................................................................1
2. ETAT DE LA QUESTION............................................................................................................2
3. CHOIX ET INTERET DU SUJET.............................................................................................3
4. PROBLEMATIQUE ET HYPOTHESES......................................................................................5
5. METHODES ET TECHNIQUES...............................................................................................6
6. DELIMITATION DU SUJET....................................................................................................7
7. SUBDIVISION DU TRAVAIL..................................................................................................8
Chapitre premier : CONSIDERATIONS GENERALES ET THEORIQUES10
I.1. GENERALITES.........................................................................................................................10
I.2. DEFINITIONS DES CONCEPTS CLES...................................................................................10
I.3 CONSIDERATIONS THEORIQUES.........................................................................................12
I.4. LANGAGE DE PROGRAMMATION......................................................................................16
I.5. CONCLUSION PARTIELLE....................................................................................................17
Chapitre deuxième : ETUDE DE L’EXISTANT DU CHAMP D’ETUDE..........................................18
I. GENERALITES............................................................................................................................18
II. PRESENTATION DE L’EXISTANT.........................................................................................18
III. ANALYSE DU METIER...........................................................................................................23
IV. CONCLUSION PARTIELLE....................................................................................................30
Chapitre Troisième : ARCHITECURE DU NOUVEAU SYSTEME..................................................31
III.1 INTRODUCTION....................................................................................................................31
III.2 CAPTURE DES BESOINS FONCTIONNELS DU SYSTEME INFORMATIQUE...............31
III.4 DIAGRAMMES DE CLASSES PARTICIPANTES................................................................52
III.5 DIAGRAMME DE CLASSES DE CONCEPTION.................................................................58
III.6 DIAGRAMME DE DEPLOIEMENT......................................................................................59
III.7 CONCLUSION PARTIELLE..................................................................................................59
Chapitre quatrième : IMPLEMENTATION DE LA SOLUTION........................................................61
 II

IV.1 INTRODUCTION....................................................................................................................61
IV.2 CHOIX DES OUTILS..............................................................................................................61
IV.3 PRESENTATION DES CLASSES DIALOGUES :................................................................62
CONCLUSION GENERALE..............................................................................................................66
BIBLIOGRAPHIE...............................................................................................................................68
 III

EPIGRAPHE
« La principale caractéristique de la gestion actuelle, à quel niveau que ce soit,
c'est le besoin permanent d'informations fiables, obtenues au bon moment et en moindre coût ».

Paul LURKIN
 IV

DEDICACE

À mes parents adorés : MWAMBA WA MWAMBA Mahomet et MWEMA WA

KABONGO Mole. Aucune dédicace ne saurait exprimer l’amour, l’estime, le dévouement et le
respect que j’ai toujours eu pour vous. Rien au monde ne vaut les efforts fournis jour et nuit pour
mon éducation et mon bien-être. Ce travail est le fruit des efforts que vous avez consentis pour
mon éducation et ma formation.

À mes adorables : grand-mère MBUYA WA IUNGA Alexador, papa Faustin

ILUNGA NVWELE NSAMBO et son épouse Chouchou MAKONGA, maman ILUNGA
NYANDWE Meletia et ma très chère sœur Cynthia MONGA WA ILUNGA, qui m'ont comblé
de leur soutien et m'ont voué un amour inconditionnel. Vous êtes pour moi un exemple de
courage et de sacrifice continu. Votre encouragement et votre soutien étaient la bouffée
d’oxygène qui me ressourçait dans les moments pénibles de solitude et de souffrance. Merci
d’être toujours à mes côtés, par votre présence, par votre amour dévoué et votre tendresse, pour
donner du goût et du sens à notre vie de famille. Que ce beau travail témoigne mon affection,
mon éternel attachement et qu'il appelle sur moi votre continuelle bénédiction.

Prosper ILUNGA MWAMBA

 V

IN MEMORIAM

La mort est certaine mais l’heure de la mort est incertaine. C’est avec un grand
regret que nous nous souvenons de notre grand-père Sambia LINGWA et de ma petite sœur
ILUNGA MUJINGA Enodie qui nous ont laissé sur cette terre.

J’aurais voulu tant vous serrer dans mes bras à la fin de mes études pour lesquelles
vous avez de sacrifice afin que je devienne la personne que je suis aujourd’hui. Mais hélas, vous
nous avez quitté trop tôt.

Que vos âmes reposent en paix, car là où nous sommes, vous y avez été et là où
vous êtes, nous y serons, c’est le chemin de tout le monde, que la terre de nos ancêtres vous soit
douce et légère.

Prosper ILUNGA MWAMBA

 VI

REMERCIEMENT

Au seuil du présent travail marquant la fin de notre deuxième cycle à l’Université

de Kamina, UNIKAM en sigle, qu’il nous soit permis de nous acquitter d'un devoir impérieux,
mais aussi agréable, celui d'exprimer notre gratitude à tous ceux qui ont apporté leur contribution
à sa réalisation.
C’est vrai, nous nous sommes lancés dans l’Univers de la recherche, et nous y
aurions feuilleté les plus gros livres du monde, et nous y aurions trouvé un tout « petit mot »
mais plus important que d’autres, c’est « merci ! », merci énormément. À tout seigneur, tout
honneur dit-on.
Vu le temps arrivé, qu’il nous soit permis au terme de ce mémoire d’exprimer
notre profonde gratitude et sincère reconnaissance à notre Dieu, pour la miséricorde qu’il nous a
accordé tout au long de notre parcours universitaire ; il est celui qui nous protège dès notre
conception et qui continue à le faire. Que la gloire, l’honneur et l’adoration soient rendus à lui,
pour son amour immensurable.
Nous disons sincèrement merci au Directeur de ce modeste travail, le professeur
Daily KALOMBO SHIMBA VIDJE, et à son collaborateur assistant NDENGANDENGA
MAKENKEWE Natalis pour avoir accepté la direction de ce travail vu leurs multiples
préoccupations, qu’ils trouvent ici, l’expression de notre sentiment le plus dévoué.

Nous remercions également tout le corps académique ainsi que le comité de

Gestion de l’Université de Kamina, en particulier le recteur Phiné YUMBA MUSOYA,
professeur ordinaire, et au doyen de la faculté des sciences informatiques le professeur Lucain
KASONGO MWADIAVITA, au vice-doyen chargé de l’enseignement, le chef des travaux
Gabin NDAY-A-MANDE, au vice-doyen chargé de la recherche le chef des travaux
RAMAZANI ZABURI Ramy, au secrétaire général de la faculté Jean-Paul BWANA ainsi que
tous les enseignants de la faculté des sciences informatiques, les cadres par excellence de notre
formation.
Nous disons merci à tous les membres de la famille dont : Sarah MONGA, Clovis
MUYOMBI, Reagan KABAYO, Taylor MANANGWA, Michou BANZA, Simon LUPINDA,
Laurent MONGA, Demaman KISHIKO, Charlène MWEPU, Anisia MBUYA, Meletia
Nyandwe, Dorcas NYANDWE, Yannick NVWELE, Alpho BADIMBA, Obed ILUNGA, Sandra
ILUNGA, Barthelemy NOWA, Gaël NSHIMIKULU, Emmanuel KITETE, Calliopie
 VII

MUJINGA, pour leurs conseils pertinents au moment où le désir de continuer avec les études
nous quittait.

Nul mot ne suffit pour exprimer notre gratitude aux camarades et compagnons de
lutte, dont, tous peuvent se sentir remercier à travers ces quelques noms à l’occurrence :
KANONO FUMANI Hornel, Salem KAYOYO, Dannick MWIMBI, Isen NSENGA, MONGA
WIFWENEBANTU Dickson, KAZADI MUKALA Rosco, BANZA MUKALAY Mary,
KIMPANGA MALOBA Hariton, KABEYA TSHIBANDA Reddy, MULONGOIE BARUANI
Marie, KASONGO NGOYI Nadine, KABEYA TSHIBANDA Reddy, Niclette KARUMB, Nick
KABEYA, Benjamin KAHENGA, ISSA BUNGIBWAO Yannick, Fatin MBUYA pour les
échanges et partages d’expériences, les remarques et suggestions pertinentes, le climat fraternel
et itératif qui a régné tout au long de notre parcours académique.

Nous ne saurons terminer sans dire merci aux amis et connaissances à

l’occurrence de : Manix KAZEMBE, Yannick YAKOBA, Ganelon BANZE, Marie MUSEKA,
Vicsa KAYEMBE, Cédric KASONGO, Yolande KABONGO, Brigitte MULENDA, Bonheur
MBAYO, Vivace KUMWIMBA, Héritier Maya, Morgan LUSAMBO, ainsi qu’à ma très chère
et aimable Naomie KASONGO pour nous avoir encouragé et donné quelques conseils pertinents.

Que tout celui dont son nom n’est pas cité ci-haut ne se sente pas lésé, mais plutôt
remercier, car il nous sera injuste que de se limiter qu’à ces quelques noms.

Prosper ILUNGA MWAMBA

 VIII

TABLE DES ILLUSTRATIONS DES TABLEAUX

Tableau 1: Identification des acteurs du système..................................................................................24

Tableau 2: Identification de cas d'utilisation métier.............................................................................27
Tableau 3: Identification des acteurs du système informatique............................................................32

TABLE DES ILLUSTRATIONS DES FIGURES

Figure 1 Organigramme de l'agence Sonas/Kamina.............................................................................22

Figure 2: Diagramme de contexte statique..........................................................................................25
Figure 3 : Diagramme d'activités..........................................................................................................26
Figure 4 : Diagramme de cas d'utilisation métier.................................................................................27
Figure 5: Diagramme des classes de domaine......................................................................................28
Figure 6: Le diagramme de cas d'utilisation conception.......................................................................33
Figure 7: Diagramme de séquence du cas d'utilisation s'authentifier....................................................34
Figure 8: Diagramme de séquence du cas d'utilisation s'inscrire..........................................................35
Figure 9: Diagramme de séquence du cas d'utilisation demander assurance........................................36
Figure 10: Diagramme de séquence du cas d'utilisation demander assurance......................................37
Figure 11: Diagramme de séquence du cas d'utilisation contrat assurance...........................................39
Figure 12: Diagramme de séquence du cas d'utilisation contrat assurance...........................................39
Figure 13: Diagramme de séquence du cas d'utilisation Gérer demandes.............................................41
Figure 14: Diagramme de séquence du cas d'utilisation Gérer utilisateurs...........................................43
Figure 15: Diagramme de séquence du cas d'utilisation Gérer quittances............................................45
Figure 16: Diagramme de séquence de conception du cas d'utilisation s'authentifier...........................46
Figure 17: Diagramme de séquence de conception du cas d'utilisation Gérer demandes......................47
Figure 18: Diagramme de séquence du cas d'utilisation Gérer utilisateurs...........................................48
Figure 19: Diagramme de séquence de conception du cas d'utilisation Gérer contrat assurance..........49
Figure 20: Diagramme de séquence de conception du cas d'utilisation Gérer contrat assurance..........49
Figure 21: Diagramme de conception du cas d'utilisation Gérer Quittance..........................................50
Figure 22: Diagramme de séquence de conception du cas d'utilisation Remplir contrat.......................50
Figure 23: Diagramme de séquence du cas d'utilisation S'inscrire........................................................51
Figure 24: Diagramme de séquence de conception du cas d'utilisation Demander Assurance..............51
Figure 25: Diagramme de classes participantes s'authentifier...............................................................53
Figure 26: Diagramme de classes participantes Gérer utilisateurs........................................................54
Figure 27: Diagramme de classes participantes Gérer demandes.........................................................54
Figure 28: Diagramme de classes participantes Gérer contrat assurance..............................................55
Figure 29: Diagramme de classes participantes Gérer quittance...........................................................55
Figure 30: Diagramme de classes participantes Remplir contrat..........................................................56
Figure 31: Diagramme de classes participantes Demander assurance..................................................56
Figure 32: Diagramme de classes participantes S'inscrire....................................................................57
Figure 33: Diagramme de classes participantes de conception.............................................................58
Figure 34: Diagramme de déploiement................................................................................................59
 IX

SIGLES ET ABREVIATIONS
 BD : Base de Données
 PHP : HyperText processor
 UP: Unified process (Processus unifié)
 MERISE : Méthodologie de recherche et de réalisation informatique par sous-
ensemble
 SGBD : Système de Gestion de Bases des Données
 XAMPP: X (cross) Apache Maria DB Perl PHP
 SQL: Structured Query Language
 Ms: Microsoft
 VB: Visual Basic
 MRS : Méthode de Recherche Scientifique
 SI : Système d’Information
 UML : Unified Modeling Language
 Unikam : Université de Kamina
 SONAS : Société nationale d’assurances
 TFC : Travail de Fin de Cycle
 IHM : Interface Homme Machine
 X

RESUME DU TRAVAIL
Le projet de conception d'une application web de gestion des demandes
d'assurances automobiles pour l'agence SONAS de Kamina vise à moderniser et optimiser les
processus de traitement des demandes. Le besoin d'une telle application est justifié par les défis
actuels rencontrés par l'agence, tels que des délais de traitement longs et un manque d'efficacité
dans la gestion des dossiers. Nous avons abordé les considérations théoriques liées à l'assurance
automobile et soulignons l'importance de la digitalisation pour améliorer la qualité des services
offerts.

En analysant les processus existants au sein de l'agence SONAS et en identifiant

les besoins spécifiques des utilisateurs, tant du côté des agents que des assurés. Nous trouvons
qu'avec une architecture modulaire qui permet une intégration facile et une sécurité renforcée des
données détaille l'implémentation de la solution, incluant le développement technique, les tests et
la formation des utilisateurs. En somme, ce projet représente une démarche proactive pour
transformer la gestion des assurances automobiles en intégrant des outils numériques adaptés aux
besoins contemporains.
 1

INTRODUCTION
1. GENERALITES
D’aucun ne redoute actuellement la révolution scientifique à laquelle le monde est
soumis avec l’apport de l’informatique ; cette science domine actuellement notre monde et
pénètre tous les secteurs de la vie de l’homme.

Avec les différentes disciplines l’informatique change et modélise notre vie au

point même de l’assujettir. Ainsi, en automatisant le traitement de l’information, l’informatique
nous amène à un nouveau siècle où nous constatons la rapidité et la perfection de la technologie
que nous n’avons jamais connue dans le passé. En outre, il faut retenir que l’usage de
l’ordinateur apporte aussi vite que possible un grand changement et spécifie la véritable portée
de la science ainsi que de la technique dans une institution ou encore une société.

Comme il parait facile de constater l’émergence de la technologie imposée aux

entreprises dites modernes la nouvelle stratégie quant à leurs différentes prestations. Ainsi,
l’outil informatique, qui fait partie du quotidien de tout travailleur devient de ce fait le
compagnon idéal de l’homme. Ce dernier lui facilite certaines tâches qui étaient complexes dans
le passé.

L’agence connait plusieurs difficultés dans le domaine de demandes comme, la

gestion manuelle des demandes d’assurances automobile peut être sujette à des erreurs, à des
retards et à une inefficacité opérationnelle, la manipulation manuelle des informations sensibles
liées aux demandes d’assurances peut poser des défis en matière de sécurité des données,
entraîner des lacunes dans la prestation de services et la communication avec les clients.

Pour surmonter ces défis, nous nous sommes alors décidés de mener nos
recherches sur la thématique intitulée « Conception d’une application web de gestion des
demandes d’assurances automobiles » (cas de l’agence SONAS de Kamina). Améliorant
l’expérience client et optimisant ses opérations internes.

C’est alors que ce travail permettra aux responsables de l’institution de s’adapter à

la plateforme web en vue d’une meilleure exploitation et pour l’émergence de ladite agence.
 2

2. ETAT DE LA QUESTION
Dans tout cet effectif des gens et surtout de la planète terre il serait risqué de dire
que nous sommes la seule et première personne à pouvoir mener des investigations dans le sens
de cette thématique ; mais la réalité est que d’autres chercheurs ont menés et continuent de
poursuivre des recherches dans le même domaine. Pour ce faire, nous avons consulté les travaux
de personnes ci-après :

Monsieur Gerson MWAMBAY KASONGO, dans son travail de fin de cycle

intitulé : « Mise en place d’une application de gestion des assurances automobiles. » 1 Cas
de la Sonas Kamina dont il avait évoqué les problèmes suivants :
 L’incapacité d’enregistrer plusieurs automobiles simultanément et dans un temps
record ;
 Perte de temps dans le traitement d’informations ;
 Utilisation d’un système de gestion de données manuel.

Il avait terminé par cette question :

 Comment arriver à réorganiser le service ?

Pour arriver à répondre aux problèmes, sa suggestion a tourné autour de la

réponse suivante :

 La mise en place d’un logiciel informatique serait capable de gérer tous les travaux en
rapport avec les assurances automobiles et cela, en temps plus rapide et efficace.

Dans le cadre de sa formation de fin d'étude, il lui aurait été demandé de trouver
une solution aux problèmes de la gestion des assurances automobiles que rencontrent les cadres
de la SONAS/KAMINA ; et pour l’analyse et la conception du système d’information, il s’y
serait arrivé en utilisant la méthode UP et avait présenté une solution sous JAVA et MySQL
comme SGBD.

Monsieur Prosper ILUNGA MWAMBA, dans son travail de fin de cycle intitulé : « Suivi
automatisé de facturation d’assurance véhicule »2 Cas de l’agence SONAS/Kamina et
ayant comme problématique :

1
Gerson MWAMBAY KASONGO, « Mise en place d’une application de gestion des assurances automobiles »,
travail de fin de cycle, Université méthodiste de Kamina (UMK) Kamina, éd.2021
2
Prosper ILUNGA MWAMBA, « Suivi automatisé de facturation d’assurances véhicules », travail de fin de cycle,
université de Kamina (UNIKAM) Kamina, ed.2022
 3

 La perte de temps : lors du suivi, le réceptionniste met beaucoup du temps pour la

recherche, et le contrôle de différents documents en rapport avec les clients ;
 Manque de la confidentialité de l’information : étant donné que la Sonas de Kamina
manque les agents dans le département de l’informatique, ses informations sont à la
portée de tout le monde, par conséquent ces informations considérées secrètes seront
diffusées par n’importe qui et cela peut nuire à la direction.

Ses suggestions aux problèmes rencontrés sont les suivantes :

 Quant à la perte du temps, notre application sera dotée d’un système de gestion de base
des données pour rechercher automatiquement les documents recherchés et que la
personne concernée soit au courant immédiatement ;
 Pour la confidentialité, notre application sera dotée d’un système permettant à chaque
utilisateur de voir ou d’entendre les informations qui lui concernent.

Dans le cadre de sa formation de fin d'étude, il lui aurait été demandé de trouver
une solution aux problèmes du Suivi de facturation des assurances véhicule que rencontrent les
cadres de la SONAS/KAMINA ; et pour l’analyse et la conception du système d’information, il
s’y serait arrivé en utilisant la méthode MERISE et avait présenté une solution sous JAVA et
MySQL comme SGBD.

Ayant présenté quelques réalisations antérieures inhérentes à l’état de la question,

nous signifions que notre sujet est différent de ceux référencés par le fait que le nôtre n’est pas à
la gestion des assurances automobiles seulement, ni au suivi de facturation d’assurance véhicule,
mais prendra en considération le processus traitant de la gestion des demandes d’assurances
automobiles. A cela, s’ajoutera un autre point de démarcation qui est l’application informatique
ainsi que les fonctionnalités qui y seront développées.

3. CHOIX ET INTERET DU SUJET

a) Choix du sujet

Le choix du sujet est une justification qu’apporte l’Etudiant ou le chercheur en

prouvant pourquoi se pencher à ce dernier que d’autres.3

33
OMARI J., Cours de méthode de recherche scientifique, G2 INFO 2021, UNIKAM, Inédit
 4

Quant à ce qui nous concerne, nous voudrions répondre à la préoccupation de

gérer les réservations des assurances automobiles au sien de la société nationale d’assurances
automobiles en mettant en place une application informatique et, la SONAS/Kamina est prise en
l’occurrence.

Dans le souci de participer à l’amélioration de ladite société et objectif

d’informatisation dans la gestion de demandes d’assurances automobiles au sein de l’agence
SONAS de Kamina, nous avons choisi ce sujet pour concevoir une application informatique
permettant l’informatisation de la gestion des demandes d’assurance automobiles pour diminuer
la perte de temps dans le traitement qui est aussi manuel.

b) Intérêt du sujet

L’intérêt c’est le souci de ce qui va dans le sens de quelque chose, de quelqu'un,

qui leur est favorable, constitue pour eux un avantage : Agir dans l'intérêt de la science4.

Dans le cadre de notre travail de fin d’études, notre sujet regorge un triple
avantage :

 INTERET PERSONNEL : sur le plan personnel, ce travail nous aidera à

l’approfondissement de nos connaissances informatiques et apportera un plus à notre bagage
intellectuel. Il nous permettra aussi de concilier la théorie à la pratique de toutes les
connaissances acquises en traitant un cas réel qui exige une implication personnelle.

 INTERET SOCIAL : ce travail apportera un grand apport au sein de la SONAS, dans le

domaine de la réservation d’assurances véhicule en leurs offrant une solution informatique
qui servira d’outil automatisé au responsable de ladite organisation.

 INTERET SCIENTIFIQUE : nous ne serons pas le premier ni encore le dernier à pouvoir

en parler. Les chercheurs à venir pourront nous compléter en s’inspirant de notre courage ; Il
sera classé dans la bibliothèque pour aider d’autres chercheurs qui viendront s’imprégner de
notre service rendu.

44
OMARI J., Cours de méthode de recherche scientifique, G2 INFO 2021, UNIKAM, Inédit
 5

4. PROBLEMATIQUE ET HYPOTHESES
4.1. Problématique

La problématique désigne l’ensemble des questions posées dans un domaine de la

science en vue d’une recherche de la solution. Elle désigne donc un ensemble d’idées qui
spécifie la position du problème suscité par le sujet d’étude5.

Il est considérable de savoir que la gestion des demandes d’assurances

automobiles au sein de la SONAS de Kamina présente fréquemment de sérieux problèmes, tels
que :

 La conservation des données : les données sont enregistrées sur des papiers mal
placés et mis à la disposition de tout le monde et avec tous les risques de perte des
données ;
 La perte de temps : lors du suivi, le réceptionniste met beaucoup du temps pour la
recherche, et le contrôle de différents documents en rapport avec les clients ;
 Manque de la confidentialité de l’information : étant donné que la SONAS de
Kamina manque les agents dans le département de l’informatique, ses
informations sont à la portée de tout le monde, par conséquent ces informations
considérées secrètes seront diffusées par n’importe qui et cela peut nuire à la
direction.

Ainsi, Les difficultés relevées ci-haut nous ont poussées à nous poser une question
qui constituera un jalon de cette étude : « Quelle solution informatique adéquate mettre en
place pour faciliter la gestion des demandes d’assurances automobiles au sein de l’agence
SONAS/Kamina ? ».

4.2. Hypothèse

L’hypothèse est une réponse présumée à la question qui oriente une recherche
8
.
Pour ce faire, nous reformulons l’hypothèse de cette manière : « mettre en place
une application web pouvant permettre la gestion des demandes d’assurances véhicules ou
automobiles serait la meilleure solution informatique ».

55
IPANGA T., Cours des méthodes de recherche scientifique, G2 INFO 2009, ISIM, Inédit
88
https://www.cheneline.infl.efile/complement.org, consulté le 06 Mai 2024 à 12h13’
 6

L’application informatique que nous allons mettre en place sera en mesure d’apporter de la
performance attendue par la société, c’est-à-dire, elle fournira des fonctionnalités pour :

 Quant à la conservation des données, nous mettrons en place une base des
données capable de stocker une grande quantité d’information ;
 Quant à la perte du temps, notre application sera dotée d’un système de gestion de
bases des données pour rechercher automatiquement les documents désirés et que
la personne concernée soit au courant immédiatement ;
 Pour la confidentialité, notre application sera dotée d’un système permettant à
chaque utilisateur de voir ou d’entendre les informations qui lui concernent.

4.3. Objectif du travail

L’objectif de ce sujet est de concevoir une application web efficace et conviviale

pour permettre aux clients de l’agence SONAS de demander des assurances automobiles en
ligne. L’application visera à simplifier le processus de demande d’assurance, à offrir une
visibilité claire sur différentes options de couverture disponibles, et à faciliter la gestion des
polices d’assurance pour les utilisateurs.

En répondant à ces besoins, l’application web contribuera à renforcer la relation

client, à accroître la satisfaction des utilisateurs et à soutenir la croissance commerciale de
l’agence SONAS

5. METHODES ET TECHNIQUES
5.1. Méthodes

Au bon fil du temps, la méthodologie fait partie intégrante de ce qui donne

l’importance à une science, ce qui facilite la démarcation d’une science par rapport aux autres.
Pour mener notre étude, nous avons besoin d’une méthode et des

techniques, Mascous BIN DUNGWA IBANDA définit la méthode comme « un

ensemble organisé des procédés mis en œuvre afin d’atteindre l’objectif que l’étudiant s’est
assigné dans son travail ».1010

1010
M. BINDUNGWA IBANDA, comment élaborer un travail de fin de cycle ? contenu et étapes,
Lubumbashi, édit, média Paul 2004, p.47
 7

En outre, Une méthode de conception des systèmes d’information a pour objectif,

la formalisation des étapes préliminaires du développement d'un système, afin de rendre ce
développement le plus fidèle possible aux besoins du client.1111

Il existe plusieurs méthodes d'analyse et de conception des systèmes

d’informations (UP, RUP, MERISE, PRAXEME), ainsi, la méthode qui sera utilisée dans ce
mémoire, c’est la méthode UP (Unified Process) en français Processus unifié.

Un processus unifié est un processus de développement de logiciel construit sur

UML (Unified Modeling Language).

5.2. Techniques

Une technique est l’ensemble d’outils importants permettant au chercheur de

récolter et de traiter les données de sa recherche

Elles sont des instruments ou des moyens manipulés par le chercheur pour assurer
l’opérationnalité conceptuelle de la méthode aux différents moments de la recherche, c.à.d. de la
conception à la réalisation (collecte et traitement des donnés) ainsi que de la compréhension ou
de son explication à la planification des phénomènes étudiés.1212

Dans ce travail, nous recourons aux techniques suivantes pour récolter les données :

a. Technique documentaire

Permet de consulter, d’analyser certains documents existants afin de recueillir les

informations convenant à la confection de ce travail de fin d’études.

b. Technique d’interview

Consiste à organiser de communication verbale entre enquêteur et enquêté pour

permettre à l’enquêteur de relever certaines informations de l’enquête concernant un projet
précis.

c. Technique d’observation

Sert de faire la descente sur terrain, effectuer les opérations afin de voir comment
se traitent les informations et en tirer des informations qui nous échapperaient lors de l’utilisation
d’autres techniques.

1111
LOBO M., Cours de conception de système d’informations, L1 CSI 2023, UNIKAM, Inédit
1212
J.G.C KAMBAJI WA KAMBAJI, « Dictionnaire du kambajisme », éd. La dialectique, Kinshasa, 2004, P.129
 8

DELIMITATION DU SUJET
Il est difficile de confectionner un travail scientifique sans pour autant fixer le lieu
où l’on mène les recherches et le temps pendant lequel le phénomène s’est déroulé. Tout travail
scientifique doit être délimité dans le temps et dans l’espace.

 Du point de vue temporel : notre travail s’étend sur une période allant du mois de
Mars jusqu’au mois d’Aout 2024, soit une période de 6 mois ;
 Du point de vue spatial : notre étude concerne que la SONAS de Kamina située
dans la ville de Kamina au quartier centre-urbain sur l’avenue du manguier au
numéro 24.

 Du point de vue fonctionnel : sachant que l’agence SONAS/Kamina a plusieurs

tâches, nous n’allons pas aborder toutes ses tâches, mais notre plateforme ne
sera limitée que sur les fonctions suivantes :

 Soumission en ligne des demandes d’assurance ;

 Consultation des différentes options de couverture ;
 Gestion des polices d’assurance ;
 Notifications et rappels ;
 Support client en ligne.

6. SUBDIVISION DU TRAVAIL
Outre l’introduction générale et la conclusion générale, nous avons subdivisé
notre travail en quatre chapitres à savoir :

Chapitre Premier : considérations générales et théoriques : Dans ce chapitre

nous présenterons l’ensemble de théories nécessaires pour bien aborder ce travail en donnant les
définitions des concepts de l’informatique et du domaine de l’application, ensuite nous
donnerons des théories nécessaires sur la méthode utilisée et notation, enfin le langage de
programmation et la gestion des données.

Chapitre deuxième : mission du champs d’étude : Ce chapitre sera consacré à la

présentation de notre champs d’étude, à la modélisation du processus métier ciblé, analyse des
besoins, description des données enfin à la critique de l’existant afin d’émettre les faiblesses et
rechercher les solutions
 9

Chapitre troisième : architecture du nouveau système : Il montrera l’analyse et

la conception d’un système informatique ;

Chapitre quatrième : implémentation de la solution : Il s’agira dans ce chapitre

de déterminer le type d’architecture qui sera utilisé et d’implémenter l’application qui tournera
selon les améliorations obtenues dans les chapitres précédents.
 10

Chapitre premier : CONSIDERATIONS GENERALES ET

THEORIQUES
I.1. GENERALITES
Dans ce chapitre il est question de définir les concepts de base en rapport avec ce
sujet, de présenter la théorie liée aux concepts de notre champs d’investigation, les concepts et
théories liés à la méthode UP, les théories liées au langage de modélisation UML ainsi que les
notions théoriques sur la plateforme de développement.

I.2. DEFINITIONS DES CONCEPTS CLES

I.2.1. Définitions des concepts du domaine

 CONCEPTION : Ensemble de méthodes, techniques et outils pour la production et la

maintenance de composants logiciels de qualité1313.

C’est l’élaboration, la production, d’un projet ou d’idées dans des contextes variés.

 APPLICATION : Logiciel permettant la réalisation d’une ou plusieurs tâches ou

fonctions1414. Programme informatique qui a pour objectif de résoudre un problème
spécifique.

 WEB : Ensemble des données reliées par des liens hypertextes sur internet. 15

 GESTION : Action ou manière de gérer, d'administrer, de diriger, d'organiser quelque chose ;

période pendant laquelle quelqu'un gère une affaire : La gestion d'un stock16.

Est l’ensemble des connaissances, des technologies, et des outils en rapport avec
la gestion de données, c’est-à-dire la collecte, la vérification et l’organisation de grandes
quantités d’informations.

 DEMANDES : Requête ou démarche exprimant le souhait d’obtenir quelque chose1717

 ASSURANCE : Contrat par lequel on garantit contre certains risques sa personne ou son
bien, ou par lequel, à de certaines conditions on assure à soi ou à d’autres le paiement d’une
somme convenue18.

13 13
https://www.emse.fr, Consulté le 01 Mai 2024 à 09h5’
14 14
https:// fr.m.wikipedia.org/wiki/Application, Consulté le 01 Mai 2024 à 09h09’
15
https://dictionnaire.lerobert.com/definition/web, Consulté le 01 Mai 2024 à 09h15’
16
Eric MITONGA LUMBALA, Impact de la gestion des abonnés sur le recouvrement des recettes SNEL/Kamina,
Mémoire de licence, L2 Economie, UNIKAM, 2018-2019, inédit.
17
https://www.lalanguefrancaise.com/dictionnaire/definition/demande, consulté le 01 Mai 2024 à 09h :20’
1718
https://dictionnaire.lerobert.com/definition/assurance, Consulté le 01 Mai 2024 à 09h25’
 11

 AUTOMOBILE : Est un véhicule à quatre roues fonctionnant à l’aide d’un moteur (à

essence, électrique, à gaz, etc.) utilisé pour le transport terrestre de personnes ou de
marchandises19.

 ASSURANCE AUTOMOBILE : Est une assurance qui couvre les dommages causés avec/à
un véhicule automobile. Cette couverture est régie dans un contrat s’appelant contrat
d’assurance automobile20.

 AGENCE : Est une entité qui bénéficie d’une certaine autonomie, sans être formellement
indépendante vis-à-vis d’un des organismes centraux du gouvernement(un ministère), et qui
prend en charge des services d’intérêts public pour le compte de cedernier21.
 SONAS : Société Nationale d’Assurances.

I.2.2. LES CONCEPTS PROPRE A L’ORGANISATION

La Société Nationale d’Assurance SONAS S.A a pour mission la vente des
assurances et le règlement des sinistres ; cette vente des assurances, fait intervenir 3 personnes
ci-après :
▪ La Société Nationale d’Assurances, elle-même et ses agences ;
▪ Les courtiers avec les maisons de courtage ;
▪ Les producteurs indépendants.
 ASSURANCE AUTOMOBILE : A pour objectif de garantir l’assuré contre les
conséquences pécuniaires résultant des dommages matériels ou corporels causés son
véhicule et des tiers (responsabilité civile),
 ASSURANCE INCENDIE : Elle a pour objectif de garantir l’assuré contre les
dommages matériels causés aux biens assurés par un évènement garanti ainsi que les frais
et pertes qui en résulte ;
 ASSURANCE TRANSPORT : Elle comprend à la fois :
 L’assurance du matériel de transport (corps) ;
 Celle des objets transportés (faculté ou marchandises) ;
 Et celle de la responsabilité assumée par les transporteurs ou propriétaire en
risque

219
https://fr.m.wikipedia.org/wiki/Automobile, Consulté le 01 Mai 2024 à 09h30’
20
J. Landelet et J. Pechinot, assurance automobile ,2 ème édition ; 2003 ; page 10.
21
Shughart, W. et L. Razzolini (2001). The Elgar companion to Public Choice, Cheltenham, Edward Elgar Pub.
Weber, M. (2003). Economie et société, Vol. 1, tome 1, Paris, Agora Pocket.
 12

 ASSURANCE ACCIDENTS ET RISQUES DIVERS : Tout est focalisé sur la

personne humaine. Dans les accidents nous distinguons : les accidents proprement dits,
La responsabilité civile, Les assurances des choses,
 ASSURANCE TOUS RISQUES CHANTIERS : Lorsqu’on parle de la tous risques
chantiers, on fait appel au Maitre de l’ouvrage (M.O) et le Maitre de l’œuvre (M.E).
I.3 CONSIDERATIONS THEORIQUES
I.3.1. PRESENTATION DU PROCESSUS UNIFIE
Le Processus Unifié (UP, pour Unified Process) est un processus de
développement logiciel « itératif et incrémental, centré sur l’architecture, conduit par les cas
d’utilisation et piloté par les risques ».

C’est un patron de processus pouvant être adapté à une large classe de systèmes
logiciels, à différents domaines d’application, à différents types d’entreprises, à différents
niveaux de compétences et différentes tailles de l’entreprise.

I.3.2. LE PROCESSUS UNIFIE EST CONDUIT PAR LE CAS D’UTILISATION

Le projet est mené en tenant compte des besoins et des exigences des utilisateurs.
Les cas d’utilisation du futur système sont identifiés, décrits avec précision et priorisés.

Le but principal d’un système informatique est de satisfaire les besoins de client.
Le processus de développement sera donc axé sur l’utilisateur. Les cas d’utilisation permettent
d’illustrer ces besoins. Ils détectent puis décrivent le besoin fonctionnel et leur ensemble
constitue le modèle des cas d’utilisation qui dicte les fonctionnalités complètes du système.

I.3.3. LE PROCESSUS UNIFIE EST CENTRE SUR L’ARCHITECTURE

Tout système complexe doit être décomposé en parties modulaires afin de garantir
une maintenance et une évolution facilitées. Cette architecture (fonctionnelle, logique, matérielle,
etc.) doit être modélisée en UML et pas seulement documentée en texte.

I.3.4. LE PROCESSUS UNIFIE EST ITERACTIF ET INCREMENTALE

Le projet est découpé en itérations ou étape de courte durée (environ 1 mois) qui
aident à mieux suivre l’avancement global. À la fin de chaque itération, une partie exécutable
du système final est produite, de façon incrémentale (par ajout).
 13

I.3.5. LE PROCESSUS UNIFIE EST PILOTE PAR LES RISQUES

Les risques majeurs du projet doivent être identifiés au plus tôt, mais surtout levés
le plus rapidement possible. Les mesures à prendre dans ce cadre déterminent l’ordre des
itérations.

I.3.6. LE CYCLE DE VIE D’UN PROCESSUS UNIFIE

L’objectif d’un processus unifié est de maitriser la complexité des projets

informatiques en diminuant les risques.
UP : est un ensemble de principe générique adapté en fonction de spécificité des projets.
L’architecture bidirectionnelle : UP gère le processus de développement par deux axes.

 L’axe vertical : représente les principaux enchainements d’activités, qui

regroupent les activités selon leur nature. Cette dimension rend compte l’aspect statique
du processus qui s’exprime en termes des composants, de processus, d’activités,
d’enchainements, d’artefacts et de travailleurs ;
 L’axe horizontal : représente le temps et montre le déroulement du cycle
de vie du processus ; cette dimension rend compte de l’aspect dynamique du processus
qui s’exprime en termes de cycles, de phases, d’itérations et de jalons.

Pour mener efficacement un tel cycle, les développeurs ont besoin de toutes les
représentations de produit logiciel :
 Un modèle des cas d’utilisation ;
 Un modèle d’analyse : détailler les cas d’utilisation ;
 Un modèle de conception : définissant la structure statique du système
sous forme de sous-systèmes, de classes et interfaces ;
 Un modèle d’implémentation : intégrant les composants ;
 Un modèle de déploiement : définissant les nœuds physiques des
ordinateurs ;
 Un modèle de test : décrivant le cas de test vérifiant les cas d’utilisation ;
 Une présentation de l’architecture.
I.3.7. ETAPES DE LA METHODES UP

La méthode UP a deux étapes :

 Les phases ;
 Les activités.
 14

I.3.8. PRESENTATION DULANGAGE UML

La description de la programmation par objets a fait ressortir l'étendue du travail

conceptuel nécessaire : définition des classes, de leurs relations, des attributs et méthodes, des
interfaces, etc.

Pour programmer une application, il ne convient pas de se lancer tête baissée dans
l'écriture du code : il faut d'abord organiser ses idées, les documenter, puis organiser la
réalisation en définissant les modules et étapes de la réalisation. C'est cette démarche antérieure à
l'écriture que l'on appelle modélisation ; son produit est un modèle.

Les spécifications fournies par la maîtrise d'ouvrage en programmation impérative

étaient souvent floues : les articulations conceptuelles (structures de données, algorithmes de
traitement) s'exprimant dans le vocabulaire de l’informatique, le modèle devait souvent être
élaboré par celle-ci.

L'approche objet permet en principe à la maîtrise d'ouvrage de s'exprimer de

façon précise selon un vocabulaire qui, tout en transcrivant les besoins du métier, pourra être
immédiatement compris par les informaticiens. En principe seulement, car la modélisation
demande aux maîtrises d'ouvrage une compétence et un professionnalisme qui ne sont pas
aujourd'hui répandus.

a. UML EN OEUVRE
UML n'est pas une méthode : ses auteurs ont en effet estimé qu'il n'était pas
opportun de définir une méthode en raison de la diversité des cas particuliers. Ils ont préféré se
borner à définir un langage graphique qui permet de représenter et de communiquer les divers
aspects d'un système d'information.

Aux graphiques sont bien sûr associés des textes qui expliquent leur contenu.
UML est donc un métalangage, car il fournit les éléments permettant de construire le modèle qui,
lui, sera le langage du projet.

Il est impossible de donner une représentation graphique complète d'un logiciel,

ou de tout autre système complexe, de même qu'il est impossible de représenter entièrement une
statue (à trois dimensions) par des photographies (à deux dimensions), mais il est possible de
donner sur un tel système des vues partielles, analogues chacune à une photographie d'une statue,
et dont la conjonction donnera une idée utilisable en pratique sans risque d'erreur grave.
 15

UML 2.0 comporte ainsi treize types de diagrammes représentant autant de vues
distinctes pour représenter des concepts particuliers du système d'information 2222. Ils se
répartissent en deux grands groupes :
 Six diagrammes structurels et Sept diagrammes comportementaux :

Le diagramme de cas d’utilisation est utilisé dans l’activité de spécification des

besoins. Il montre les interactions fonctionnelles entre les acteurs et le système à l’étude.

Le diagramme de classes est le point central dans un développement orienté objet.

En analyse, il a pour objet de décrire la structure des entités manipulées par les utilisateurs. En
conception, le diagramme de classes représente la structure d’un code orienté objet.

Le diagramme de packages montre l’organisation logique du modèle et les

relations entre packages. Il permet de structurer les classes d’analyse et de conception, mais aussi
les cas d’utilisation.

Les diagrammes de séquence et les diagrammes de communication sont tous deux

des diagrammes d’interactions UML. Ils représentent des échanges de messages entre éléments,
dans le cadre d’un fonctionnement particulier du système.

Les diagrammes de séquence servent d’abord à développer en analyse les

scénarios d’utilisation du système. Plus tard, les diagrammes de séquence et de communication
permettent de concevoir les méthodes des classes.

Le diagramme d’états représente le cycle de vie commun aux objets d’une même
classe. Ce diagramme complète la connaissance des classes en analyse et en conception en
montrant les différents états et transitions possibles des objets d’une classe à l’exécution.

Le diagramme d’activité représente les règles d’enchaînement des actions et

décisions au sein d’une activité. Il peut également être utilisé comme alternative au diagramme
d’états pour décrire la navigation dans un site web.

Le diagramme d’objets est un instantané, une photo d’un sous-ensemble des

objets d’un système à un certain moment du temps. C’est probablement le diagramme le moins
utilisé d’UML et nous n’en verrons pas d’illustration.

2222
Joseph Gabay et David Gabay, UML 2 ANALYSE ET CONCEPTION « Mise en œuvre guidée avec études de cas
», Edition Dunod, Paris, 2008, P.11
 16

Le diagramme de composants montre les unités logicielles à partir desquelles on a

construit le système informatique, ainsi que leurs dépendances.

Le diagramme de déploiement montre le déploiement physique des artefacts

(Éléments concrets tels que fichiers, exécutables, etc.) sur les ressources matérielles.

Le diagramme de vue d’ensemble des interactions fusionne les diagrammes

d’activité et de séquence pour combiner des fragments d’interaction avec des décisions et des
flots.

Le diagramme de temps fusionne les diagrammes d’états et de séquence pour

montrer l’évolution de l’état d’un objet au cours du temps et les messages qui modifient cet état.

Le diagramme de structure composite montre l’organisation interne d’un élément

statique complexe sous forme d’un assemblage de parties, de connecteurs et de ports.

I.4. LANGAGE DE PROGRAMMATION

Un langage de programmation est une notation conventionnelle destinée à
formuler des algorithmes et produire des programmes informatiques qui les appliquent2323.

I.4.1. LANGAGE INFORMATIQUE

On appelle « langage informatique » un langage destiné à décrire l’ensemble des

actions consécutives qu’un ordinateur doit exécuter. Un langage informatique est ainsi une façon
pratique pour nous (humains) de donner des instructions à un ordinateur. Au contraire, le terme «
langage naturel » représente les possibilités d’expression partagé par un groupe d’individus (par
exemple l’anglais ou le français).2424

Les langages servant aux ordinateurs à communiquer entre eux n’ont rien avoir
avec des langages informatiques, on parle dans ce cas de protocoles de communication, ce sont
deux notions totalement différentes. Un langage informatique est rigoureux :

À chaque instruction correspond une action du processeur. Le langage utilisé par

le processeur est appelé langage machine. Il s’agit des données telles qu’elles arrivent au
processeur, constituées d’une suite de 0 et de 1 (données binaires).

Le langage machine n’est ainsi pas compréhensible par l’être humain, c’est
pourquoi des langages intermédiaires, compréhensibles par l’homme, ont été mis au point. Le

2323
BALDO M., « cours des questions spéciales de programmation », L1 CSI 2023, UNIKAM, Inédit
2424
Idem
 17

code écrit dans ce type de langages est transformé en langage machine pour être exploitable par
le processeur.

L’assembleur est le premier langage informatique qui ait été utilisé. Celui-ci est
très proche du langage machine mais reste compréhensible pour des développeurs. Toutefois, un
tel langage est tellement proche du langage machine qu’il dépend étroitement du type de
processeur utilisé (chaque type de processeur peut avoir son propre langage machine).

Ainsi, un programme développé pour une machine ne pourra pas être porté sur un
autre type de machines. Le terme « portabilité » désigne l’aptitude d’un programme informatique
à être utilisé sur des machines de types différents.

Pour pouvoir utiliser un programme informatique écrit en assembleur sur un autre

type de machines, il sera parfois nécessaire de réécrire entièrement le programme !

I.4.2. AVANTAGES DE LANGAGES INFORMATIQUES

Un langage informatique a donc plusieurs avantages :

 Il est plus facilement compréhensible que le langage machine ;

 Il permet une plus grande portabilité, c’est-à-dire une plus grande
facilité d’adaptation sur des machines de types différents. La liste n’est pas
exhaustive.

I.5. CONCLUSION PARTIELLE

Dans ce premier chapitre, nous avons exploré les fondements théoriques et les
considérations générales qui sous-tendent la conception d'une application web de gestion de
demandes d'assurances automobiles, en prenant comme cas d'étude l'agence SONAS de Kamina.
 18

Chapitre deuxième : ETUDE DE L’EXISTANT DU CHAMP D’ETUDE

I. GENERALITES
Ce chapitre est consacré à la présentation du champ d’investigation, et à l’analyse
du métier. Il se consacrerait à la description du domaine tout d’abord, où nous présenterions
d’une façon un peu détaillée notre système ; à la modélisation du processus métier, où nous
tracerions différents diagrammes ; à la suite, nous analyserions les besoins, et nous décririons les
données ; nous critiquerions l’existant, et nous bouclerions ce chapitre par la proposition de la
solution nouvelle.

II. PRESENTATION DE L’EXISTANT

La SONAS est une entreprise publique à caractère technique et commerciale dotée
d’une personnalité juridique propre sous la tutelle du ministère de l’économie et de budget et
celui du portefeuille. Cette entreprise jouit du monopole de l’exploitation du marché des
assurances sur toute l’étendue de la république démocratique du Congo.

II.1. HISTORIQUE

Avec plus 50 ans d’expérience, la SONAS est la société leader des toutes les
sociétés d’assurances existants en RDC.
A l’époque coloniale, il n’existait pas d’entreprises publiques exploitant le
domaine des assurances en RDC. Ce qui veut dire, les assurances ont été un domaine réservé aux
étrangers dont : les belges, les hollandais, les canadiens et les britanniques, exerçant leurs
activités sur le sol congolais par le biais de leurs filiales, courtiers et agents généraux au
détriment des intérêts du pays. Les revenus encaissés par ces entreprises provenant de leurs
activités étaient transférés directement dans leurs pays respectifs.

Ces derniers exploitent les branches ci-après :

 Assurance automobile ;
 Assurance incendie ;
 Assurance transport ;
 Assurance vie ;
 Assurance accidents et risques divers.

Ils travaillaient avec les sociétés dont les plus importantes étaient :
IMMOCONGO, IMMOAF, BOELS BEGAUT, CHARLES LE JEUNE. Ces sociétés ne
 19

parviennent à contrôler l’ensemble de l’Etat congolais. Ce qui donnait aux nationaux l’idée de
récupérer la gestion du secteur des assurances par une entreprise publique pour que les recettes et
les primes soient au profit des congolais.

Cependant, en date du 31 décembre 1960, il y a eu une rumeur des nationaux

ayant l’initiative de créer une entreprise nationale qui s’occupait des assurances
dénommée « Compagnie Nationale d’Assurance au Congo CONASCO en sigle ».

Ces derniers avaient pour branche principale d’exploiter : l’accident, l’incendie, la

réassurance. Mais en réalité cette compagnie n’était qu’une maison de courtage au service des
étrangers.
Toujours dans le souci de reformer dans le secteur économique, il y a eu création
d’une Société Nationale d’Assurances, SONAS en sigle en date du 23 novembre 1966 par
l’ordonnance loi du président MOBUTU, N°66/622. Il est à noter qu’avant 1966 le secteur des
assurances étaient dans les mains des compagnies étrangères qui transféraient tout argent vers les
métropoles sans que la population congolaise en bénéficie, cet état des choses à pousser le
législateur à prendre une décision grave en créant une société nationale d’assurances en
république démocratique du Congo.

Ainsi l’agence SONAS de Kamina a été créée à partir du mois de février 2009
avec comme objectif de promouvoir les assurances de proximités dans l’environnement
économique et social caractérisé par l’absence de la culture d’assurance c’est-à-dire que de
rapprocher l’assuré. Et cette entité est dirigée par le chef d’agence.

II.2. SITUATION GEOGRAPHIQUE

La société nationale d’assurances (SONAS) agence de Kamina est située dans le

quartier centre-urbain, commune de Kamina, dans la ville de Kamina. Cette agence se trouve
actuellement sur l’avenue des manguiers au numéro 24.

II.3. OBJECTIF SOCIAL

Le statut de la société précise que la SONAS a pour objectif l’exploitation de

toutes les opérations d’assurances, l’exploitation de toutes les opérations de coassurances,
l’exploitation de toutes les opérations de réassurances, d’effectuer le contrôle technique d’un
véhicule automoteur, d’effectuer les transactions immobilières notamment les locations et les
 20

ventes des immeubles des tiers dont la gestion est confiée à la SONAS et d’effectuer les
opérations financières et d’investissement s’y rattachant directement sur le territoire congolais.

II.4. STRUCTURE ORGANISATIONNELLE ET FONCTIONNELLE

a. Chef d’agence
Il coordonne et contrôle l’ensemble des activités de la Sonas, à ce titre, il assure
l’exécution des décisions pour toute libération des documents, l’élaboration et l’orientation de la
politique de l’agence conformément aux objectifs préalablement définit, et toute sortie du
personnel.

b. Secrétaire

Il s’occupe de la gestion de tous les documents venant en ailleurs avant de les

présentés au chef d’agence, il reçoit toutes les doléances du personnel, il met en contact toutes
les personnes désirantes de voir le chef d’agence en personne.

c. Chef d’agence adjoint

Il travail presque comme le chef d’agence beaucoup plus à son absence donc il
seconde le chef d’agence pour certaines tâches et avant de prendre une décision il est son
consultant principale.

d. Technique commerciale

Elle s’occupe d’élaborer toute sorte de contrat d’assurances, il enregistre tous les
documents édités par le chef d’agence et les livrent à la personne concernée.

e. Administration de finance

Il s’occupe de gérer deux services dans son sein, le service de la caisse et

comptable, il garde les archives de paiement du personnel et sinistrés.

f. Responsable sinistre

Il s’occupe de la conservation du dossier sinistre en pièce justificative, de la

gestion sinistre, de la formation de demandes et d’expertise.
 21

g. Comptable

Il répond à tout prix d’élaborer le budget annuel que doit égorger la Sonas pour
toutes les activités réalisées pour le personnel et de risques, les soumet à la signature
d’administration de finance.

h. Caissier

Il s’occupe de la caisse de la Sonas entre autre de toutes les entrées et sorties de

fond. Il établit les ordonnances de paiement qui, après la vérification de fond dans la caisse, les
soumet à la signature d’administration de finance.
 22

II.5. ORGANISATION HIERARCHIQUE

ORGANIGRAMME

CHEF D’AGENCE

SECRETAIRE

ADJOINT AU CHEF D’AGENCE

ADMINISTRATION TECHNICO-
RESPONSABLE SINISTRE
FINANCE COMMERCIAL

COMPTABILITE CAISSIER LESION

ASSURANCE ASSURANCE DEGATS
ASSURANCE CORPORELL
INCENDIE A.R.D AUTOMOBI MATERIELS
ES
LE
PERSONNE
ARCHIVES INTENDENCE,
GARDE
Figure 1 Organigramme de l'agence Sonas/Kamina

Source : Secrétariat de l’Agence Sonas/Kamina

 23

III. ANALYSE DU METIER

A. DESCRIPTION DU METIER
Cette partie est consacrée à la compréhension de l’idée du métier dans son
ensemble, à une identification des acteurs qui interagissent avec le système. Dans la conception
d’un système nouveau, plateforme INFORMATIQUE, au sein de l’agence engendre des
conséquences dans le fonctionnement ; l’importance est d’avoir l’idée sur le problème qui
intervient et qu’on doit résoudre ou y proposer une solution.

Dans le contexte de notre travail, nous avons choisi le processus de gérer les
demandes d’assurances automobiles que nous allons décrire, comme il se passe dans l’agence
SONAS/Kamina, pour qu’en fin y proposer une solution nouvelle sur la plateforme
informatique.

B. ETUDE PRELIMINAIRE
Cette partie nous servirait à passer la base de la capture des besoins du système à
réaliser. L’étude préliminaire (ou pré-étude), est la toute première étape de notre processus de
développement. Elle consiste à effectuer un premier repérage des besoins fonctionnels, et
utilisant principalement le texte, ou des diagrammes très simples. Elle prépare les activités plus
formelles de capture des besoins fonctionnels et de capture des besoins techniques2525.

Elle prépare les activités plus formelles de la capture des besoins fonctionnels, et
de capture des besoins techniques.

a. DESCRIPTION TEXTUELLE DU PROCESSUS METIER

Dns cette etape nous allons permet de voir comment les informations circulent
dans ce système d’informations.

A l’agence SONAS Kamina le client désirant assurer son véhicule se présente au

service technique avec sa carte rose, ainsi, La technique vérifie si ladite carte rose est valide et
lui propose le contrat d’assurance, ce contrat présente les informations suivantes : Si le client
accepte alors, il remplit et dépose ce contrat au secrétaire.

Le secrétaire dépose ce contrat à son tour au chef d’agence, le chef signe le

contrat et édite une quittance et envoi au service technique, ce dernier remet la quittance non
approuvée au client, en suite il présente la quittance et paye le montant à la caisse, cette dernière

2525
Pascal Roques, Franck Vallée, Op.cit., p.46.
 24

envoi ladite quittance non approuvée au chef d’agence, le chef approuve la quittance et édite le
certificat, il envoi au service technique et enfin le technicien les livre au client.

b. IDENTIFICATION DES ACTEURS

Un acteur est une entité quelconque ayant un comportement qui inclut d’autres
systèmes faisant appel au système modélisé ou auquel le système modélisé fait appel. Plus
généralement, il s’agit d’une catégorie de personnes qui peut agir comme utilisateur du système
et interagir avec ce dernier2626.
Un acteur peut consulter et/ou modifier directement l’état du système, en émettant et/ou en
recevant des messages éventuellement porteurs de données. Les acteurs candidats sont
systématiquement :
 Les utilisateurs humains directs : identifier tous les profils possibles, sans oublier
l’administrateur, l’opérateur de maintenance, etc. ;
 Les autres systèmes connexes qui interagissent aussi directement avec le système.

Dans l’angle de la présente étude, voici la liste des acteurs qui interagissent avec le système de
gestion des demandes en ligne d’assurances automobiles :
N° ACTEURS TYPE RÔLES
1 CHEF D’AGENCE Interne Il est chargé d’approuver la quittance et le
certificat.
2 TECHNITIEN Interne Il est chargé de vérifier si la carte rose du
demandeur est valide, il lui propose le contrat
d’assurance.
3 SECRETAIRE Interne Il est chargé de prendre le contrat d’assurance
remplit par le client et le déposer au chef
d’agence.
4 DEMANDEUR Externe Il vient pour solliciter l’assurance automobile.
Tableau 1: Identification des acteurs du système
c. DIAGRAMME DE CONTEXTE STATIQUE

Le diagramme diagramme de contexte statique, délimite le domaine d’étude en

précisant ce qui est à la charge du système, et en identifiant l’environnement extérieur au
système étudié, avec lequel ce dernier communique. Ses composants sont :

2626
GILLES ROY, GILLES ROY, Conception de base de données avec UML, Presses de l’Université de Québec,
Québec, 2009, p.356.
 25

 Les acteurs externes. Un acteur externe est une entité externe au système étudié qui
interagit avec le système.
 Un processus unique symbolisant le Système Information étudié
 Échange entre le système étudié et son environnement.

Figure 2: Diagramme de contexte statique

d. DIAGRAMME D’ACTIVITES
Le diagramme d’activités n’est autre que la transcription dans UML de la
représentation du processus telle qu’elle a été élaborée lors du travail qui a préparé la
modélisation : il montre l’enchaînement des activités qui concourent au processus2727.
Voici comment est présenté notre diagramme d’activite

2727
Laurent AUDIBERT, UML 2.0 (département informatique), Institut Universitaire de Technologie de
Villetaneuse, 1re année, p.23.
 26

Figure 3 : Diagramme d'activités

D. IDENTIFICATION DE CAS D’UTILISATION DU METIER

L’identification des cas d’utilisations pour une première fois, nous donne un
aperçu des fonctionnalités futures que doit implémenter le système. Cependant, il nous fait
plusieurs itérations pour ainsi arriver à constituer des cas d’utilisations complets. D’autres cas
d’utilisations vont apparaître au fur et à mesure de la description de ceux-là, et l’avancement
dans le « recueil des besoins fonctionnels ».

En regroupant les intentions fonctionnelles dans des unités cohérentes, on obtient

les cas d’utilisations suivants :
 27

N° NOM CAS ACTEURS PRINCIPAL/ SECONDAIRE ACTIONS

D’UTILISATIONS

1 Demander Assurance Demandeur/Technicien Introduire la requête de

demande d’assurance.
2 Traiter demande Technicien/Chef d’Agence/Demandeur Enregistrer carte rose et
consulter le contrat rempli
par le demandeur.
3 Approuver demande Chef d’Agence/caissier/demandeur Accordé l’assurance après
traitement et payement.

Tableau 2: Identification de cas d'utilisation métier

2. DIAGRAMME DE CAS D’UTILISATION METIER

Ce diagramme représente les interactions entre les acteurs et le système

d’information. Il regroupe plusieurs cas d’utilisations qui ont un fort lien fonctionnel.

Figure 4 : Diagramme de cas d'utilisation métier

3. DIAGRAMME DE CLASSE DU DOMAINE

Le diagramme de classes est généralement considéré comme le plus important

dans un développement orienté objet. Il représente l’architecture conceptuelle du système : il
décrit les classes que le système utilise, ainsi que leurs liens, ces dernières représentent une mise
en boite conceptuelle ou une relation organique2828.

2828
Laurent AUDIBERT, UML 2.0, IUT, département, 1ière année, P22
 28

Ce diagramme permet de décrire un ensemble d’objet (attributs et

comportements), Le diagramme de classe exprime de manière générale la structure statique d’un
système, en terme de classes et de relations entre ces classes.

Figure 5: Diagramme des classes de domaine

 29

E. ETUDE DES SUPPORTS D’INFORMATIONS

L’étude du support d’informations construit une étape par laquelle on identifie les
supports informationnels utilisés dans un métier, de les décrire et de modéliser les concepts du
métier.

 Identification des supports d’informations

A l’agence SONAS Kamina les documents utilisés dans le processus d’assurance

des véhicules automobiles sont :

 La carte rose
 La proposition de contrat
 Quittance
 Certificat d’assurance.
1. Carte rose
La carte rose est un document qui permet à la SONAS d’avoir une certitude si le
véhicule vous appartient réellement.

2. La proposition de contrat
La proposition de contrat est un document que la SONAS propose aux clients de
choisir le contrat voulu.
3. La quittance
La quittance est un document que la SONAS livre au client après le paiement.
4. Certificat d’ assurance
Le certificat d’assurance est la preuve d’un contrat d’assurance. Ce document
justifie l’assurance d’un véhicule automobile.

F. PRESENTATION DU DIAGNOSTIC DE L’EXISTANT

1. Critiques de l’existant

La critique se veut une phase très essentielle dans tout travail scientifique. Après
un diagnostic fait dans le système actuel, nous avons trouvé comme grande faiblesse :

 L’incapacité de recevoir plusieurs demandes d’assurances des clients

simultanément et dans un temps record ; cela entraine comme conséquence
négative perte de temps et de certains clients non habitués à des files
d’attentes.
 30

 Le système actuel présente certaines limites dans le sens qu’il ne permet pas
d’élargir les possibilités d’assurance, sans passer physiquement au siège,
alors que la ressource internet pouvant offrir cette possibilité est
disponible.
 L’inutilisation de la ressource web (Internet) : alors qu’elle peut être utilisé
pour renforcer la capacité en demande pour un meilleur rendement de la
société.
Comme toute chose ne manque pas de bon côté. La SONAS a aussi ses points
forts tel que :
Une bonne communication et collaboration avec leurs clients.
Un contrôle rigoureux des informations même si le système est manuel.

2. Proposition de la solution nouvelle

Pour remédier à ces problèmes nous proposons de mettre en place un système

automatisé pour la gestion des demandes en ligne des assurances automobiles.

IV. CONCLUSION PARTIELLE

Dans ce chapitre, nous avons approfondi le champ d'étude relatif à la conception

d'une application web de gestion des demandes d'assurances automobiles, en nous concentrant
spécifiquement sur le contexte et les pratiques de l'agence SONAS à Kamina.
 31

Chapitre Troisième : ARCHITECURE DU NOUVEAU SYSTEME

III.1 INTRODUCTION
La conception du système informatique permet d’acquérir une compréhension
Approfondie des contraintes liées au langage de programmation, à l’utilisation des composants,
et au système d’exploitation. Elle détermine les principales interfaces, et les transcrit à l’aide
d’une notation commune.
Dans ce chapitre, la principale préoccupation est de représenter l’architecture du
système de la solution informatique, portant sur la conception de diagramme de séquence de
conception, diagramme de classes participantes, diagramme de classe de conception, et le
diagramme de déploiement.

III.2 CAPTURE DES BESOINS FONCTIONNELS DU SYSTEME INFORMATIQUE

La conception d’un système informatique, est la préoccupation des utilisateurs
pour une satisfaction des besoins ; Ce sont des besoins qui déterminent ce que le système doit
fournir à ses utilisateurs.
A ce niveau, les éléments comme cas d’utilisation, vont nous permettre de voir la
fonctionnalité du système ainsi que la manière dont les différents acteurs vont manipuler le
système.
III.2.1 Identification des acteurs du système
Un acteur représente l’abstraction d’un rôle joué par des entités externes (Utilisateur, dispositif
matériel ou autre système) qui interagissent directement avec le système étudié. Un acteur peut
consulter et/ou modifier directement l’état du système, en émettant et/ou en recevant des
messages éventuellement porteurs de données2929.
Les acteurs suivants sont ceux qui interagissent avec le système à développer :

N° ACTEURS TYPE RÔLES

1 CHEF D’AGENCE Interne Il est chargé d’éditer et d’approuver la

quittance et le certificat d’assurance après
vérification du contrat d’assurance.
2 TECHNICIEN Interne Il est chargé de faire toutes les actions allant
de la réception de la demande d’assurance,
son traitement jusqu’à la remise du certificat
d’assurance.
3 CAISSIER Interne Il est chargé de facturer le demandeur selon le
contrat d’assurance choisi.

2929
P. Roques et F. Vallée, UML 2 en action de l’analyse des besoins à la conception, 4e Ed. EYROLLES, paris
2007, p. 51
 32

4 DEMANDEUR Externe Il vient pour demander l’assurance de son

véhicule muni de la carte rose de son véhicule.
5 WEBMASTER Interne Il est responsable de la maintenance du site et de
l'héberger à l'aide d'un logiciel FTP comme
FILEZILA et faire la mise à jour des programmes
(Template, applications, etc.), il peut aussi gérer
utilisateurs (ajouter utilisateurs, modifier leurs
informations, réinitialiser leurs mots de passe, ou
les supprimer), gérer les constantes, les résultats,
les donneurs et gérer aussi les entretiens, contacts,
ainsi gérer les médias en passant par une
authentification.
Tableau 3: Identification des acteurs du système informatique
III.2.2 Besoins Fonctionnels du système et non fonctionnels du système
a. Besoins fonctionnels
Il s'agit des fonctionnalités du système. Ces sont les besoins spécifiant un
comportement d'entrée / sortie du Système.
Le système doit permettre :
 De s’authentifier ;
 S’inscrire ;
 Demander assurance
 Ajouter Demande ;
 Remplir contrat ;
 Gérer quittance ;
 Gérer contrat ;
 Gérer demande ;
 Gérer utilisateurs.
b. Besoins non fonctionnels
Il s'agit des besoins qui caractérisent le système. Ce sont des besoins en de
performance, de type de matériel ou le type de conception. Ces besoins peuvent concerner les
contraintes d'implémentation (langage de programmation, type SGBD, de système
d’Exploitation,…)

Dans le cadre de ce travail, l'application devra être extensible, c'est-à-dire qu'il

pourra y avoir une possibilité d'ajouter ou de modifier de nouvelles fonctionnalités.

L'application devra être capable de :

 Tourner en réseau ;
 Être compatible avec n'importe quel système d'exploitation.
 33

IL faudra aussi noter que l'application devra être hautement sécurisée car les informations ne
devront pas être accessibles à tout le monde.
III.2.3 Diagramme de cas d’utilisation de conception
Le diagramme de cas d’utilisation « use case diagram » vient décrire le système
étudié en privilégiant le point de vue de l’utilisateur. Il permet de recueillir, d’analyser,
d’organiser les besoins, et de recenser les grandes fonctionnalités de ce système. Voici les
différentes fonctionnalités identifiées3030.

S'INSCRIRE GERER DEMANDES

«include»
TECHNICIEN

DEMANDEUR DEMANDER ASSURANCE GERER UTILISATEURS

«include» «includ» WEB MASTER

«extend» S'AUTHENTIFIER

REMPLIRE CONTRAT
ASSURANCE
«includ»
«includ» GERER CONTRAT
GERER QUITTANCE ASSURANCE
CHEF D'AGENCE
CAISSIER

Figure 6: Le diagramme de cas d'utilisation conception

III.2.4 Description textuelle des cas d’utilisation de conception

1. Description textuelle du cas d’utilisation : « S’authentifier »
 Résumé : Ce cas d’utilisation permet aux utilisateurs du système informatique de
s’authentifier avant d’y accéder au système
 Acteurs :
- Principal : Utilisateur
- Secondaire : Système
 Pré-condition :
- Avoir son login et son mot de passe
 Post-condition : Accès autorisé ou non autorisé.
 Scénario nominal :
1. L’utilisateur ouvre son navigateur et se connecte au système
2. Le système affiche la page d’authentification
3030
Pascal Roques, UML 2.5 par la pratique, Etudes de cas et exercices corrigés, 8è édition Eyrolles, p.24
 34

3. L’utilisateur fournit son login et son mot de passe

4. L’utilisateur clique sur le bouton « Connexion »
5. Le système vérifie le login et le mot de passe de l’utilisateur
6. Ouvreir page.
 Scénario alternatif :

a.1. Le système bloque l’accès à l’utilisateur au point 5 du scénario nominal

lorsque le login et le mot de passe de l’utilisateur sont incorrects
a.2. Le système retourne l’utilisateur au point 2 du scénario nominal et affiche
un message d’erreur.

 DESCRIPTION FORMELLE DU C.U système : « S’authentifier »

Figure 7: Diagramme de séquence du cas d'utilisation s'authentifier

2°. Description textuelle du cas d’utilisation : « S’inscrire »
 Résumé : Ce cas d’utilisation permet au client de s’enregistrer avant de passer sa
demande d’assurance.
 Acteurs :
- Principal : Demandeur
- Secondaire : Système
 Précondition :
- Se connecter
 Post-condition :
- Inscription acceptée ou refusée.
 Scénario nominal :
 35

1. Le client clique sur le menu inscription

2. Le système affiche la page d’inscription
3. Le client remplit ses coordonnées
4. Le client clique sur le bouton « Soumettre »
5. Le système vérifie les coordonnées
6. Le message de conformation
 Scénario alternatif :

a. Le système refuse l’inscription au client au point 5 du scénario

nominal lorsque les coordonnées du client sont incorrectes
b. Le système retourne le client au point 2 du scénario nominal et affiche
un message d’erreur.

 DESCRIPTION FORMELLE DU C.U système : « S’inscrire »

Figure 8: Diagramme de séquence du cas d'utilisation s'inscrire

3°. Description textuelle du cas d’utilisation : « Demander Assurance »

 DESCRIPTION TEXTUELLE
 Résumé : Ce cas d’utilisation permet au client voulant assurer son véhicule de
passer la demande d’assurance.
 Acteurs :
- Principal : Demandeur
 36

- Secondaire : Système
 Précondition :
- Avoir carte rose
- Etre inscrit.
 Post-condition : Demande acceptée ou refusée.
 Scénario nominal :
1. Le client clique sur le menu demander assurance
2. Le système affiche la page de demande assurance
3. Le client fournit les informations de la carte rose
4. Le client clique sur le bouton « Envoyer »
5. Le système vérifie les informations
6. Le système accepte la demande.
 Scénario alternatif :
- Le système refuse la demande au client au point 5 du scénario nominal
lorsque les informations de la carte rose sont incorrectes
 DESCRIPTION FORMELLE DU C.U système : « Demander assurance »

Figure 9: Diagramme de séquence du cas d'utilisation demander assurance

4°. Description textuelle du cas d’utilisation : « Remplir contrat »

 37

 DESCRIPTION TEXTUELLE
 Résumé : Cette fonctionnalités permet au client désirant assurer son véhicule de
remplir la clause ou le contrat d’assurance.
 Acteurs :
- Principal : Demandeur
- Secondaire : Système
 Précondition :
- Savoir les droits et devoirs
 Post-condition : Le contrat est bien rempli.
 Scénario nominal :
1. Le client clique sur le menu remplir contrat
2. Le système affiche la page remplir contrat
3. Remplir le formulaire du contrat
4. Valider saisie
5. Le client clique sur le bouton « Envoyer »
6. Le système vérifie les informations
7. Le système affiche le message de confirmation.
 Scénario alternatif :
- Contrat bien rempli et envoyé
 DESCRIPTION FORMELLE DU C.U système : « Remplir contrat »

Figure 10: Diagramme de séquence du cas d'utilisation demander assurance

5°. Description textuelle du cas d’utilisation : « Gérer contrat assurance »
 38

 DESCRIPTION TEXTUELLE
 Résumé : Ce cas d’utilisation permet au Chef d’agence de gérer les contrats des
tous les clients via le système configuré.
 Acteurs :
- Principal : Chef d’agence
- Secondaire : Système
 Précondition :
- Etre connecté au système
- Le Chef d’agence s’est déjà authentifié
 Scénario nominal :
1. Le Chef d’agence clique sur le menu « Gestion contrat assurance »
2. Le système affiche la page de gestion de contrat assurance
3. Le Chef d’agence clique sur le bouton « Etablir quittance » ou « Etablir
certificat » si la quittance a déjà été validée
4. Le système affiche le formulaire
5. Le Chef d’agence rempli les informations demandées et clique sur le bouton «
Valider »
6. Le système enregistre la quittance ou le certificat et affiche un message de
confirmation.
 Scénario alternatif : -
 Post-condition :
- Contrat assurance enregistré (quittance ou certificat)
DESCRIPTION FORMELLE DU C.U système : « Gérer Contrat assurance »

Système

Chef d'agence Cliquer sur le menu "Gestion contrats assurances"

Afficher page des contrats assurances

Cliquer sur le bouton "Etablir quittance"

Affichage du formuaire

Remplir le formulaire
Clique sur bouton "Valider formulaire"

Enregistrer
Affichagedu message de confirmation
 39

Figure 11: Diagramme de séquence du cas d'utilisation contrat assurance

Figure 12: Diagramme de séquence du cas d'utilisation contrat assurance

6°. Description textuelle du cas d’utilisation : « Gérer demandes »
 DESCRIPTION TEXTUELLE
 Résumé : Cette fonctionnalité permet au Technicien de gérer toutes les demandes
des clients à l’aide de ce système configuré.
 Acteurs :
- Principal : Technicien
- Secondaire : Système

 Précondition :
- Le technicien s’est déjà authentifié
- Etre connecté au système
 Scénario nominal :
 NOM : RECHERCHER DEMANDE
1. Le technicien clique sur le menu « Gestion demande »
2. Le système affiche la page de gestion de demandes
3. Le technicien clique sur le bouton « Rechercher demande » de la demande
concernée.
4. Le système affiche la page de recherche demande
 40

5. Le technicien saisit les informations concernées et clique sur le bouton «

Rechercher demande »
6. Le système affiche un message du résultat recherché.

 NOM : SUPPRIMER DEMANDE

1. Le technicien clique sur le menu « gestion demandes »
2. Le système affiche la page de gestion demandes
3. Le technicien clique sur le bouton « demande » du client concerné.
4. Le système affiche un message de confirmation de suppression d’une demande.
5. Le Technicien clique sur le bouton « Oui »
6. Le système supprime la demande et affiche un message de confirmation.
 Scénario alternatif : -
 Post-condition :
- Demande recherchée
- Demande supprimée

DESCRIPTION FORMELLE DU C.U système : « Gérer demandes »

 41

Figure 13: Diagramme de séquence du cas d'utilisation Gérer demandes

7°. Description textuelle du cas d’utilisation : « Gérer utilisateurs »
 DESCRIPTION TEXTUELLE
 Résumé : Ce cas d’utilisation permet au Webmaster du système, d’ajouter, de
modifier ou encore de supprimer les utilisateurs du système informatique.
 Acteurs :
- Principal : Webmaster
- Secondaire : Système
 Précondition :
- Le webmaster s’est déjà authentifié
- S’il existe un utilisateur voulant utiliser le système.
- Un utilisateur à rechercher
- S’il existe un utilisateur à modifier dans le système
- S’il existe un utilisateur à supprimer dans le système
 Scénario nominal :
 NOM : AJOUTER UTILISATEUR
1. Le Webmaster clique sur le menu « Gestion utilisateurs »
 42

2. Le système affiche la page de gestion des utilisateurs

3. Le Webmaster clique sur le bouton « Créer un utilisateur »
4. Le système affiche la page de création utilisateur
5. Le Webmaster remplit les informations demandées et clique sur le bouton « Créer
utilisateur »

6. Le système enregistre l’utilisateur et affiche un message de confirmation.

 NOM : MODIFIER UTILISATEUR
1. Le Webmaster clique sur le menu « Gestion utilisateurs »
2. Le système affiche la page de gestion des utilisateurs
3. Le Webmaster clique sur le bouton « Modifier utilisateur » de l’utilisateur
sélectionné.
4. Le système affiche la page de modification utilisateur
5. Le Webmaster édite les informations fournies et clique sur le bouton «
Modifier utilisateur »
6. Le système met à jour l’utilisateur et affiche un message de confirmation.
 NOM : SUPPRIMER UTILISATEUR
1. Le Webmaster clique sur le menu « Gestion utilisateurs »
2. Le système affiche la page de gestion des utilisateurs
3. Le Webmaster clique sur le bouton « Supprimer utilisateur » de l’utilisateur
sélectionné.

4. Le système affiche un message de confirmation à l’administrateur de suppression

d’un utilisateur
5. Le Webmaster clique sur le bouton « Oui »

6. Le système supprime l’utilisateur et affiche un message de confirmation.

 Post-condition :

- Utilisateur crée

- Utilisateur recherché

- Utilisateur modifié

- Utilisateur supprimé.
DESCRIPTION FORMELLE DU C.U système : « Gérer utilisateurs »
 43

Figure 14: Diagramme de séquence du cas d'utilisation Gérer utilisateurs

 44

8°. Description textuelle du cas d’utilisation : « Gérer Quittance »

 DESCRIPTION TEXTUELLE
 Résumé : Cette fonctionnalité a pour objectif d’élaborer la quittance du client
suivant les conditions de la prime à payer.
 Acteurs :
- Principal : Caissier
- Secondaire : Système
 Précondition :
- Percevoir l’argent
 Scénario nominal :
- Le caissier lance la page Gérer quittance
- Le système affiche la page demandée
- Le caissier saisit les informations dans le formulaire
- Le caissier clique sur le bouton « valider »
- Affichage du message de confirmation.
 Scénario alternatif : -
 Post-condition : Quittance remplie
DESCRIPTION FORMELLE DU C.U système : « Gérer quittances »
 45

Figure 15: Diagramme de séquence du cas d'utilisation Gérer quittances

III.3. CONCEPTION DES INTERACTIONS SYSTEME
III.3.1. DIAGRAMMES DE SEQUENCE DE CONCEPTION DETAILLEE DU
SYSTEME
Par rapport aux diagrammes de séquences système, nous remplacerions, ici, le
système, vu comme une boîte noire, par un ensemble d’objets en collaboration. Ces objets sont
des instances des trois (3) types de classes d’analyse du diagramme de classes participantes, à
savoir des dialogues (les classes qui permettent les interactions entre l’IHM et les utilisateurs),
des contrôles (les classes qui modélisent la cinématique de l’application) et des entités (les
classes métier, qui proviennent directement du modèle du domaine).
Les diagrammes de séquences élaborés dans cette section doivent donc toujours
respecter les règles. Ces règles doivent cependant être transposées car, pour que deux objets
interagissent directement, il faut que :
 46

 Les classes dont ils sont issus soient en association dans le diagramme de classes
participantes ;
 L’interaction respecte la navigabilité de l’association en question.

1. Diagramme de Séquence de Conception S’authentifier

Figure 16: Diagramme de séquence de conception du cas d'utilisation s'authentifier

 47

2. Diagramme de Séquence de Conception Gérer demandes

Figure 17: Diagramme de séquence de conception du cas d'utilisation Gérer demandes

 48

3. Diagramme de Séquence de Conception Gérer utilisateurs

Figure 18: Diagramme de séquence du cas d'utilisation Gérer utilisateurs

 49

4. Diagramme de séquence de conception Gérer contrat Assurance

Figure 19: Diagramme de séquence de conception du cas d'utilisation Gérer contrat assurance

Figure 20: Diagramme de séquence de conception du cas d'utilisation Gérer contrat assurance
 50

5. Diagramme de séquence de conception Gérer Quittance

Figure 21: Diagramme de conception du cas d'utilisation Gérer Quittance

6. Diagramme de séquence de conception Remplir Contrat

Figure 22: Diagramme de séquence de conception du cas d'utilisation Remplir contrat

 51

7. Diagramme de séquence de conception S’inscrire

Figure 23: Diagramme de séquence du cas d'utilisation S'inscrire

8. Diagramme de séquence de conception Demander Assurance

Figure 24: Diagramme de séquence de conception du cas d'utilisation Demander Assurance

III.4 DIAGRAMMES DE CLASSES PARTICIPANTES

Le diagramme de classes participantes est un diagramme de classes UML qui
décrit cas d’utilisation par cas les trois principales classes d’analyse et leurs relations 3131:

3131
Joe NTAMBWE, mise au point d’un système de gestion des panneaux publicitaires, mémoire de licence, L2
Informatique et télécommunications, UPL, 2011, inédit.
 52

 Les classes dialogues possèdent des attributs et des opérations. Les attributs représentent
des champs de saisie ou des résultats. Les opérations quant à elles, représentent des
actions de l’utilisation sur l’Interface Homme Machine ;

 Les classes contrôles contiennent des opérations. Ces opérations représentent la logique
applicative de l’application, les règles métiers ou les comportements du système
informatique ;
 Les classes entités possèdent en général des informations persistantes de l’application.

Le diagramme de classes participantes est particulièrement important puisqu’il effectue la

jonction entre, d’une part, les cas d’utilisation, le modèle du domaine et la maquette, et d’autre
part, les diagrammes de conception logicielle que sont les diagrammes d’interaction et le
diagramme de classes de conception3232.
Lors de l’élaboration du diagramme de classes participantes, il faut veiller au respect des règles
suivantes :
 Les entités, qui sont issues du modèle du domaine, ne comportent que des attributs
;
 Les entités ne peuvent être connectées (association) qu’avec d’autres entités ou

avec des contrôles mais, dans ce dernier cas, avec une contrainte de navigabilité
interdisant de traverser une association d’une entité vers un contrôle ;

 Les contrôles ne comportent que des opérations. Ils implémentent la logique

applicative, et peuvent correspondre à des règles transverses à plusieurs entités.
Chaque contrôle est généralement associé à un cas d’utilisation, et vice versa.
Mais rien n’empêche de décomposer un cas d’utilisation complexe en plusieurs
contrôles ;
 Les contrôles peuvent être associés à tous les types de classes, y compris d’autres
contrôles. Dans le cas d’une association entre un dialogue et un contrôle, une
contrainte de navigabilité doit interdire de traverser l’association du contrôle vers
le dialogue ;
 Les dialogues comportent des attributs et des opérations. Les attributs

représentent des informations ou des paramètres saisis par l’utilisateur ou des

résultats d’actions. Les opérations réalisent (généralement par délégation aux
contrôles) les actions que l’utilisateur demande par le biais de l’IHM ;

3232
Laurent AUDIBERT, op.cit., p.115.
 53

 Les dialogues peuvent être en association avec des contrôles ou d’autres

dialogues, mais pas directement avec des entités ;
 Il est également possible d’ajouter les acteurs sur le diagramme de classes
participantes en respectant la règle suivante : un acteur ne peut être lié qu’à un
dialogue.

1.Diagramme de Classes Participantes S’authentifier

Figure 25: Diagramme de classes participantes s'authentifier

2.Diagramme de classes participantes Gérer utilisateurs

 54

Figure 26: Diagramme de classes participantes Gérer utilisateurs

3. Diagramme de classes participantes Gérer Demandes

Figure 27: Diagramme de classes participantes Gérer demandes

4. Diagramme de classes participantes Gérer contrat assurance

 55

Figure 28: Diagramme de classes participantes Gérer contrat assurance

5. Diagramme de classes participantes Gérer Quittance

Figure 29: Diagramme de classes participantes Gérer quittance

6. Diagramme de classes participantes Remplir contrat

 56

Figure 30: Diagramme de classes participantes Remplir contrat

7. Diagramme de classes participantes Demander assurance

Figure 31: Diagramme de classes participantes Demander assurance

8. Diagramme de classes participantes S’inscrire

 57

Figure 32: Diagramme de classes participantes S'inscrire

 58

III.5 DIAGRAMME DE CLASSES DE CONCEPTION

Figure 33: Diagramme de classes participantes de conception

 59

III.6 DIAGRAMME DE DEPLOIEMENT

Le diagramme de déploiement permet de représenter les outils sur lesquels
s’exécute l’application. Ces outils comprennent des nouds correspondant aux supports physique
(serveur, routeurs) ainsi que la répartition des artefacts logiciels (bibliothèques, exécutables) sur
ces nœuds. Ce, faisant notre application, sera déployée sur un serveur dédiée et emprunte le
réseau internet pour être accessible aux clients.

Figure 34: Diagramme de déploiement

III.7 CONCLUSION PARTIELLE
Dans ce troisième chapitre, nous avons abordé la conception du système
informatique destiné à la gestion des demandes d'assurances automobiles pour l'agence
SONAS/Kamina. Cette étape cruciale a permis de traduire les besoins identifiés dans les
chapitres précédents en solutions techniques concrètes.

Nous avons commencé par définir l'architecture générale du système, en

choisissant une approche modulaire qui facilite l'intégration de différentes fonctionnalités tout en
assurant une maintenance simplifiée. Cette architecture permettra également de faire évoluer
l'application selon les besoins futurs de l'agence et des utilisateurs.

Ensuite, nous avons détaillé les principales fonctionnalités de l'application, telles

que la soumission en ligne des demandes, le suivi des statuts, et la gestion des documents
 60

associés. Chaque fonctionnalité a été conçue en tenant compte des retours d'expérience des
utilisateurs et des meilleures pratiques en matière d'ergonomie et d'expérience utilisateur.
L'objectif est de garantir une interface intuitive qui facilite la navigation et encourage l'utilisation
régulière de l'application.
 61

Chapitre quatrième : IMPLEMENTATION DE LA SOLUTION

IV.1 INTRODUCTION

L’objectif de ce présent chapitre est de faire la description du processus qui nous a

permis de parvenir à l’implémentation de la plateforme informatique. Ce processus a commencé
par une implémentation de la base de données destinée à contenir les données utilisées par le
futur système. A la suite de cela, nous essayerons de montrer quelques bouts de code réalisés
avec le langage PHP qui nous ont permis d’implémenter la plateforme. Et enfin nous montrerons
les principales interfaces et fenêtres de l’application ainsi que les codes.

IV.2 CHOIX DES OUTILS

Pour développer l’application liée à la gestion des demandes d’assurances
automobiles de l’agence Sonas de Kamina, nous avons utilisé plusieurs outils et nous allons faire
une petite présentation de ces derniers.

 Le langage de programmation et la plateforme de développement :

Le langage de programmation est un langage qui sert à décrire les actions qu'un
ordinateur doit réaliser. Ces actions sont innombrables et variées. Pour réaliser des actions que
l’ordinateur doit exécuter. Il existe plusieurs langages de programmation tels que : l’Assembleur
(ASM), le Cobol, le Basic, le Java, le C/C++, le Pascal, le Visual Basic, le Delphi, les langages
du web ( HTML - CSS - JS - PHP - SQL), le Flash.

En effet, pour développer l’application attendue par les utilisateurs, nous

choisirions les langages de programmation web PHP, HTML et CSS, et c’est le Visual code
2012 qui serait utilisé comme l’environnement de développement.

 Système de gestion de la base de données :

L’outil pour le développement de l’application en mode local est le logiciel
XAMPP version 3.2.4 X64.

Un serveur web est spécifiquement un serveur multi-service utilisé pour publier

des sites web sur Internet ou un intranet. XAMPP (X (cross) Apache Maria DB Perl PHP) est un
serveur web parmi tant d’autres (EasyPHP, WAMP, etc.). C’est un ensemble de logiciels
permettant de mettre en place facilement un serveur Web local, un serveur FTP et un serveur de
 62

messagerie électronique. Il offre une bonne souplesse d'utilisation, réputée pour son installation
simple et rapide.

IV.3 PRESENTATION DES CLASSES DIALOGUES :

a. Page d’accueil

b. page authentification
 63

c. Inscription

d. page demandeur

e. demande assurance
 64

f. demande approuvée

g. Page demande

h. valider une demande

 65

i. Quittance valider
 66

CONCLUSION GENERALE
Tout au long du vaste chemin emprunté à la recherche des solutions de nos études
engagées pour notre sujet, nous voici arrivé à la fin de notre travail scientifique qui met en cause
notre objectif d’atteinte du grade de licencié en conception des systèmes d’information.

De nos études parcourues sur : « conception d’une application web de gestion de

demandes d’assurances automobiles à l’agence Sonas de Kamina », nous avons soulevé des
problèmes qui ont été regroupés en une pertinente question de recherche se basant sur la gestion
des demandes d’assurances en guise de notre problématique :

 Quelle solution informatique adéquate mettre en place pour faciliter la gestion des
demandes d’assurances automobiles au sein de l’agence SONAS/Kamina ?

Ainsi, il serait évidant de spécifier que l’hypothèse a été avancée d’une manière
provisoire au début de notre étude et à sa fin nous l’avons confirmé du fait qu’elle est compatible
avec la réalité vécue sur terrain lors de la collecte de données ; cette hypothèse est la suivante :

 La mise en place d’une application web pouvant permettre la gestion des demandes
d’assurances véhicules ou automobiles serait la meilleure solution informatique.

Pour traiter les données et rendre ce travail effectif, nous avons jugé bon d’utiliser
la méthode UP attachée au langage de modélisation UML qui nous a permis de concevoir un
système informatique. Cette méthode a été appuyée par la technique documentaire, d’interview
et d’observation. Pour pallier les problèmes techniques de perturbation de gestion, nous avons
conçu notre application en programmation Web avec le langage PHP.

En faisant abstraction à l’introduction et à la conclusion générale, notre travail a

été subdivisé en quatre chapitres qui se résument de la manière suivante :

 Le chapitre premier est intitulé « considérations générales et théoriques ». Dans ce

chapitre, la définition des concepts de base en rapport avec le sujet et la présentation des
concepts de base ainsi que des théories liées à la méthode UP, ont constitué son socle ;
alors que celles liées au langage de modélisation UML ainsi qu’aux notions théoriques
sur la plateforme de développement utilisé, l’ont jalonné.
 Le chapitre deuxième « mission du champ d’étude », il était question dans ce chapitre,
de présenter le champ d’investigation, et l’analyse du métier. Il était consacré à la
 67

description du domaine tout d’abord, où nous avions présenté d’une façon un peu
détaillée notre système ; à la modélisation du processus métier, où nous avions tracés
différents diagrammes ; à la suite, nous avions analysé les besoins, et avions décrit les
données.
 Le troisième chapitre a traité sur « l’architecture du nouveau système », la principale
préoccupation était celle de représenter l’architecture du système de la solution
informatique préconisée, partant de la conception de diagrammes de séquence de
conception et de diagramme de classes de conception au choix technologique et logiciel.
 Le quatrième chapitre « implémentation de la solution » : dans celui-ci, il était question
de mettre en place la plate-forme informatique longtemps soutenue dans ce mémoire.

Pour clore, nous nous libérons enfin de la tâche que nous nous sommes assignés
tout au long du choix approuvé pour notre sujet sanctionnant la fin du deuxième cycle de nos
études.

Il est évident de mettre de côté toute sureté d’exactitude sur les recherches faites,
ainsi serait nécessaire d’accepter toute critique et suggestion afin d’améliorer nos recherches en
sciences informatiques.
 68

BIBLIOGRAPHIE
1. OUVRAGES
 GILLE ROY, Conception de base de données avec UML, presses de l’université
de Québec, 2003 ;
 GILLES ROY, GILLES ROY, Conception de base de données avec UML,
Presses de l’Université de Québec, Québec, 2009 ;
 Joseph Gabay et David Gabay, UML 2 ANALYSE ET CONCEPTION « Mise
en œuvre guidée avec études de cas, Edition Dunod, Paris, 2008 ;
 PIERRE G. et BERGERON. « La gestion » (1984 :91) ;
 Laurent AUDIBERT, UML 2.0 (département informatique), Institut Universitaire
de Technologie de Villetaneuse, 1ère année ;
 M. BINDUNGWA IBANDA, comment élaborer un travail de fin de cycle ?
contenu et étapes, Lubumbashi, édit, média Paul 2004 ;
 P. Roques et F. Vallée, UML 2 en action de l’analyse des besoins à la
conception, 4e Ed. EYROLLES, paris 2007 ;
 Pascal Roques et Frank vallée, UML 2 en action <<De l’analyse des besoins à la
conception, 4ème édition Eyrolles, 61, bd 5t-GERMAIN 75240, Paris ;
 Pascal Roques, UML 2.5 par la pratique, Études de cas et exercices corrigés, 8è
édition Eyrolles ;
 Ronger, méthode des sciences, paris éd. Dalloz, 197.

2. NOTES DE COURS
 BALDO M., « cours des questions spéciales de programmation », L1 CSI
2023 ;
 UNIKAM, Inédit OMARI J., Cours de méthode de recherche scientifique, G2
INFO 2021, UNIKAM, Inédit ;
 LOBO M., Cours de conception de système d’informations, L1 CSI 2023,
UNIKAM, Inédit.
3. TRAVAUX DE FIN D’ETUDES ET DE FIN DE CYCLE

 Gerson MWAMBAY KASONGO, « Mise en place d’une application de gestion

des assurances automobiles », travail de fin de cycle, Université méthodiste de
Kamina (UMK) Kamina, éd.2021
 69

 Prosper ILUNGA MWAMBA, « Suivi automatisé de facturation d’assurances

véhicules », travail de fin de cycle, université de Kamina (UNIKAM) Kamina,
ed.2022
 Joe NTAMBWE, mise au point d’un système de gestion des panneaux
publicitaires, mémoire de licence, L2 Informatique et télécommunications, UPL,
2011, inédit.
 Eric MITONGA LUMBALA, Impact de la gestion des abonnés sur le recouvrement des recettes
SNEL/Kamina, Mémoire de licence, L2 Economie, UNIKAM, 2018-2019, inédit.

4. DICTIONNAIRES
 Copyright (©) jargon informatique ;
 Dictionnaire Français, application androïde version 4.0 ;
 Dictionnaire petit Robert, Larousse, éd.2010.
 J.G.C KAMBAJI WA KAMBAJI, « Dictionnaire du kambajisme », éd. La
dialectique, Kinshasa, 2004, P.129
5. SITES INTERNET
 https://www.cheneline.infl.efile/complement.org,
 https://www.emse.fr,
 https:// fr.m.wikipedia.org
 https://dictionnaire.lerobert.com
 https://perso.ens-lyon.fr