« Implémentation d’une application informatique pour la gestion de paie de sinistre au sein de la SONAS MAKISO/Kisangani

Par Jordi Trésor Kasongo

TFC ISC-Kis, informatique de Gestion édition 2021

INTRODUCTION

Depuis la découverte de l’Informatique comme science de traitement rationnel de l’information des entreprises. Aujourd’hui des nombreuses activités de la vie courante ont été simplifiés dans tous les domaines de la vie de l’homme spécifiquement dans les entreprises, l’avènement du traitement automatique notamment par des machines automatisées qui sont devenu le cerveau, le système nouveau, le cœur, le noyau de tout système d’information.
Le fléau de Traitement automatique de l’information a pris de l’ampleur grâce à l’expansion de machine informatique de grande performance et l’augmentation de précision dans le traitement de données ou dans la transformation de l’information. Ces traitements étant automatique, réalisé par des machines, le temps n’est plus quelque chose face à l’automatique ; Dans un laps de temps le traitement automatique et rationnel peut produire efficacement et rapidement, les résultats que le cerveau humain. Un traitement rationnel implique un traitement exact dans la précision et rassurant. De même pour la gestion de paie des sinistres au sein de la
SONAS MAKISO-KISANGANI, Le traitement rationnel devient envisageable afin d’éradiquer où de diminue efficacement le degré d’erreur.
O.1. ETAT DE LA QUESTION

L’Etat de la question étant définit comme un produit documentaire établissant le bilan critique des travaux effectués sur un sujet donné pendant une période déterminée et pouvant se présenter sous forme écrite ou orale, précise par Bruno CLAPARADE .
Plusieurs chercheurs se sont déjà lancé dans le processus de transformation de la Gestion de paie de sinistres, parmi eux nous avons considéré les travaux de :
ILONDO EKANGOLAKA Jephté : a opté de parler sur la Conception et réalisation d’une application informatique pour la Gestion des Sinistres « cas de la SONAS KISANGANI »
Tout au long de sa recherche, il a constaté les problèmes de la gestion qui se posent au seins de la Sonas Kisangani, au regard de ces problèmes, il a formulé des problématiques suivantes :

 La difficulté à établir la liste complète des sinistres
 Le risque d’erreur dans le calcul de paiement des sinistres ;
 La lenteur dans la recherche des données concernant le frais ;  Etc…
Pour atteindre ses objectifs il a utilisé comme méthode, MERISE pour faire ses analyses et Conception, et pour l’Application il a choisis le langage de programmation Java et Ms Access version 2016 comme Système de Gestion de Base des Données.
SITUNGWO NGOY Pascal qui a opté de parler sur la mise en place d’une application pour la gestion des sinistrés automobile au sein de la société nationale d’assurance « SONAS en sigle »
Tout au long de sa recherche, il a constaté qu’il existe les problèmes de la gestion qui se posent au sein de la SONAS/KISANGANI, au regard de ces problèmes, il a formulé des problématiques suivantes :

 Comment s’effectue le système de gestion des sinistrés automobiles au sein de la SONAS Kisangani ?
 Que devons-nous faire pour aider cette société à résoudre les problèmes liés à cette gestion ?

Après ces analyses il avait proposé les hypothèses suivantes :

 La gestion des sinistres automobiles s’effectuerait manuellement à la SONAS/Kisangani ;
 La mise en place d’un système informatisé serait une solution qui va permettre de résoudre les problèmes cités ci-haut.

Pour atteindre ses objectifs il a utilisé comme, méthode MERISE pour faire ses analyses et Conception, et pour l’application il a choisis le langage de programmation VB.Net version 2010 et MS Access 2016 comme Système de Gestion de Base des Données.
A la différence des auteurs ci-haut, notre travail s’oriente vers l’Implémentation d’une application informatique pour la Gestion de Paie de Sinistres Au sein de la SONAS MAKISOKISANGANI.
O.2 PROBLEMATIQUE

La problématique est l’ensemble des questions posées dans un domaine bien déterminé en vue de la recherche de la solution, elle est aussi un ensemble des questions suscitées par le sujet d’étude.

En d’autres termes, la problématique est définie comme un écart constaté entre une situation de départ insatisfaisante et une situation d’arrivée désirable dont un processus de recherche est entrepris afin de combler cet écart.2

Selon Pierre PAILLE et Alex MUCCHIELLI, la problématique est définie comme
« l’ensemble des questions qui préside à la recherche, car les faits ne parlent qu’à celui qui sait les interroger. Elle est aussi définie comme la mise en relation argumentée des considérants permettant de poser un problème ». 3

Dans une décente sur terrain, nous avons constaté qu’il y a plusieurs sérieux problèmes que connait la SONAS MAKISO-Kisangani tels que : la gestion de paie des sinistres qui reste encore manuelle.

Donc, il n’y a pas une application automatisée pour assurer cette gestion en toute
sécurité et rapidité.

Face à ce que nous avons fait comme constant, trois question nous ont conduit à réfléchir de la manière suivante :

 La paie de sinistrés manuellement est-elle vraiment une solution efficace et rentable au sein de la SONAS ?
 Est-il opportun d’implémenter un système automatisé de gestion des paies des sinistres au sein de la SONAS ?
 Quels sont les avantages d’utilisation d’un système informatique dans la gestion des paies des sinistres au sein de la SONAS ?
0.3. HYPOTHESES

L’hypothèse est à la fois une création de l’esprit ou une invention, mais aussi une
conception provisoire jusqu’à ce qu’une vérification lui enlève son caractère anticipatif, précise
VITAMARA KITAMBALA.4

Partant des questions soulevées dans notre problématique, nous proposons l’usage de l’informatique qui est un moyen capable de faciliter et simplifier la gestion de paie de sinistrés à la SONAS par l’implémentations d’une application intégrée. En effet, nous pensons que :

• La paie des sinistres manuellement ne serait pas une solution efficace et rentable au seins de la SONAS.
• Oui, par ce qu’une implémentation d’une application informatique conviendrait mieux pour assurer l’organisation et la structuration des activités de la paie des sinistres au sein de la SONAS.
• Les avantages d’utilisation d’un système informatique dans la gestion des courriers seraient la sécurité des données et la cohérence des informations.

PAILLE, P. et MUCHIELLI, A, 2003, L’analyse qualitative en sciences humaines et sociales, Paris, Arnaud collin, p.16.
⁶ VITAMARA KITAMBALA, Cours de la Méthodes de recherche scientifique, G2 IG, ISP-KIS, 2013-2014.

0.4. OBJECTIFS DU TRAVAIL

En abordant ce travail partant sur l’implémentation d’une application informatique pour la Gestion de paie des sinistrés au sein de la SONAS MAKISO-Kisangani, notre étude, aura donc pour objectif :

  • Automatiser la gestion de paie des sinistres au sein de la SONAS, • Imprimer automatiquement les documents suivants :
     La liste de paie des sinistres partant d’une période définie ;  Le reçu des paies des sinistres.
    0.5 CHOIX ET INTERET DU SUJET
    Concrétiser à la théorique.
    0.5.1 Choix du sujet
    Le choix de ce sujet se justifie par le fait qu’il cadre avec notre formation en sciences informatiques. Il nous permet de concilier les différentes théories apprises aux cours à la pratique dans le domaine informatique et nous a aider à approfondir nos connaissances en informatique.
    0.5.2 Intérêt du sujet

La réalisation de ce travail présente triple intérêt :
 Sur le plan Scientifique : Pour la science, ce travail restera dans l’histoire de l’informatique à l’ISC-KISANGANI, dans les rayons de bibliothèque scientifique et servira de référence à tous les autres chercheurs voulant aborder ce domaine.
 Sur le plan Personnel : Pour notre vie scientifique, car celui-ci est la pratique de la théorie apprise aussi en vue d’obtentions d’un diplôme de graduant.
 Sur le plan pratique ou professionnel : l’application que nous produirons permettra à la SONAS MAKISO-Kisangani de gagner le temps dans le processus de paie des sinistres et aussi d’afficher les résultats fiables et à temps réel.
0.6 METHODES ET TECHNIQUES UTILISEES
0.6.1 Méthodes

Pour faire bouture d’une manière scientifique une recherche scientifique, il faut utiliser les méthodes et techniques scientifique, spécifiques de son devoir de garantir une forte transparence à ce sujet. Nous avons répondu à cette démarche en utilisant une méthode.
Par définition une méthode est un ensemble organisé des procédés mis en œuvre afin d’atteindre l’objectif que l’étudiant s’est assigné dans le travail ; disait AUGUSTIN WILIWOLI SIBILONI5

Pr. Fr, A. WILIWOLI SIBILONI, Cours de Méthode de recherche scientifique, G2 Informatique, ISC-KIS, 2018-2019.
Il existe plusieurs méthodes comme la méthode structuro-fonctionnelle ; méthode merise ; etc. Ainsi, nous avons choisis la méthode MERISE qui est une méthode la plus utilisée, celle-ci nous a permis de faire l’analyse et la conception de notre système.

  • LA MERISE : est une méthode d’analyse de conception et de développement du système d’information d’une entreprise. Le but de cette méthode est d’arriver à concevoir un système d’information. ⁶
    0.6.2 Techniques
    Une technique est un procédé, un moyen utilisé pour obtenir un résultant fixé.
    Définition selon KALONJI MPANGA. Dans la recherche qui a conduit à l’élaboration de ce travail, ou nous sommes servis de trois techniques.
    0.3.1.1 Technique d’observation direct

Cette technique nous a permis de recevoir certaines informations après l’observation
et cela, manière dont s’effectuent les mouvements de paie.

0.6.2.2 Technique de documentation

Cette technique nous a permis de consulter les différents documents spécifiques concernant notre travail, de collecter les données utiles à nôtres études à partir des travaux du fin de cycle, ouvrages, revues etc…

0.6.3 Technique d’interview

Elle consiste à aller vers toute personne, susceptible de détenir une information
intéressante pour la concrétisation d’un travail scientifique.
0.7 DELIMITATION DU SUJET
Le présent travail est délimité dans le temps et dans l’espace.
 Délimitation spatial : Comme tout travail scientifique est censé être circonscrit dans l’espace, le nôtre se rapporte sur l’implémentation d’une application informatique pour la gestion de paie des sinistres au sein de la SONAS MAKISO-Kisangani.
 Délimitation temporelle : Dans le temps, notre travail couvre la période allant de 20192021.
0.8 Difficultés Rencontrées
La réalisation d’une œuvre scientifique ne manque pas des difficultés tout au long de la réalisation. Nous les avons affrontées comme toute chercheur scientifique, on a pris la résolution d’amener son travail jusqu’à sa matérialisation.
Nous avons heurté les difficultés suivantes :
 La pandémie de Covid-19 qui a bougé le monde entier ;
 La distance entre le domicile et la Sonas pour la récolte de donnée ;
 Les difficultés d’ordres général : l’accès aux données n’as pas été chose facile, il a fallu beaucoup d’efforts pour les obtenir ;
 Les difficultés de la gestion du temps entre les cours et la décente sur terrain pour la récolte des données ;
 Les difficultés de manque d’ouvrage du domaine informatique dans quelques bibliothèques disponibles dans notre ville, d’où il ne nous a pas été facile de réunir une documentation suffisante ;
 La perturbation du courant.
Pour contourner ces difficultés, nous avons usé de la patience, de la persévérance ;
d’humilité et raffermir notre volonté d’aboutir aux conclusions de notre analyse.
0.9 SUBDIVISION DU TRAVAIL

Hormis l’introduction et la conclusion, notre travail comprend donc trois chapitres à
savoir :
CHAPITRE PREMIER : Ce chapitre est consacré à la PRESENTATION DU MILIEU D’ETUDE ET LA DEFINITION DES CONCEPTS CLES
CHAPITRE DEUXIEME : Celui-ci est consacré à ; L’ANALYSE CONCEPTUELLE DU SYSTEME EXISTANT
CHAPITRE TROISIEME : Celui-ci est consacrée à ; L’IMPLEMENTATION DU NOUVEAU SYSTEME ET LA PRESENTATION DE L’APPLICATION.

Chapitre premier : PRESENTATION DU MILIEU D’ETUDE ET DEFINITION DES CONCEPTS CLES

Ce chapitre est divisé en deux sections : dont la première porte sur le cadre conceptuel, dans ce point, nous allons présenter les concepts clés de notre étude et les définir ; la deuxième est intitulée la présentation du milieu d’étude, ce point se focalise sur la présentation de la Société National d’Assurance « SONAS en sigle » qui est notre milieu d’étude.
1.1. Définition des concepts clés du sujet.

Dans ce point, il est question d’expliciter quelques concepts utilisés dans le cadre de
ce travail.

o Implémentation : Selon le Grand robert, l’implémentation est définie comme l’action d’exécuter, réaliser où spécialiser un logiciel plus tard. o Application : Selon le Grand robert6, Une application est définie comme un programme écrit en vue d’une utilisation précise (calcul, gestion, jeu, etc…). Logiciel, software.
o Informatique : L’informatique selon Philip DREYFUS ; est la combinaison de deux mots : Information réduite à « infor » et l’Automatique réduite à « matique ». Il dit : c’est une science de traitement rationnel de l’information de manière automatique. Ce traitement est réalisé par de machine informatique appelée Ordinateur.
o Gestion : C’est l’action de gérer les affaires d’un autres, et ses propres affaires. Administration du patrimoine ou de certains biens d’une personne physique ou moral par son représentant légal, juridique ou conventionnel. Selon Peter Drucker7, théoricien américain du management, la gestion est l’art de prendre une décision rationnelle et informée. La décision se fait donc à partir d’une analyse complète et réfléchie. Gérer s’oriente plus vers gouverner une organisation en précisant les buts et les moyens pour les atteindre.
o Paie : C’est l’action de payer (agents, fonctionnaire, militaire)
o Sinistre : C’est la personne qui a subi des dommage, du fait d’un sinistre où la personne physique ou moral à qui le malheur est arrivé. o Sonas : Société National d’Assurance.
1.2. PRESENTATION DU MILIEU D’ETUDE
I.2.1. Aperçus historique

Dans ce point, nous allons présenter l’organisation du marcher d’assurance congolais
d’assurance avant et après la création de la Société National d’Assurance, « SONAS en sigle ».

⁸ LE GRAND ROBERT : Dictionnaire de la langue Française.
⁹ Op Cit.
¹⁰ Op cit.
¹¹ Peter Drucker, l’art du management, édition Print Hall 2003, p.132
1.2.1.1. ORGANISATION DU MARCHER CONGOLAIS D’ASSURANCE
1.2.1.2. HISTORIQUE

a) Avant la création de la SONAS

Comme toute activité économique et sociale, l’assurance a été organisée dans le contexte du libéralisme économique qui a caractérisé l’époque du XIXe siècle.
Exceptionnellement au Congo, les activités d’assurance s’exerçaient dans le grand esprit de la conférence internationale de Berlin de 1885 complétée par les chartes du 22 mars 1885 de saint-germain de la Haye portant sur la liberté de commerce dans tout le territoire du bassin conventionnel du Congo.

L’annexion du Congo au Royaume de la Belgique n’as fait que renforcer l’implantation des sociétés d’exploitation de diverses richesses de ce pays sous les esprits les plus divers, le tout dans une structure à l’économie extravertie c’est-à-dire que le Congo constituant la périphérie et la métropole, était le centre de décision vers lequel était destinée la plus-value résultant des comptes d’exploitation des dites sociétés.

L’industrie d’assurances n’as pas manqué elle aussi de subir la même loi. Le transfert à l’étranger des bénéfices d’exploitation, plus-value de diverses compagnies d’assurances était facilité et favorisé par l’absence complète des mécanismes de contrôle au niveau de la Banque Centrale du Congo Belge et du Ruanda-Urundi.

C’est seulement vers les années 1928 que les compagnies d’assurances commencèrent à s’installer au Congo belge et étaient représentées par les généraux ou des courtiers.
Il s’agit notamment des sociétés suivantes :

  1. Le crédit foncier africain ;
  2. L’HELVETTIA ;
  3. L’IMMOAF, Immobilier Africain ;
  4. L’IMMOCONGO ;
  5. Charles Lejeune, etc…

Il y’a lieu de signaler que les compagnies Britanniques d’assurances ont couvert 80%
de l’ensemble du marché congolais d’assurances.

b) Après la création de la SONAS

Créée le 23 novembre 1996 par l’ordonnance loi n°66/0622 bis la Société National d’Assurances a vu le jour avec comme mission première d’unifier les activités d’assurances exercées jadis par les compagnies privées étrangères.
Cette création a mis fin au libéralisme économique dans ce secteur d’activités économiques au Congo en confiant à la nouvelle société le monopole de toutes ces activités ainsi la SONAS était devenue la seul compagnie d’assurances à couvrir l’ensemble du marché national d’assurances.
De ce fait, les anciennes compagnies d’assurances qui voulaient bien rester au Congo et continuer à y travailler s’étaient converties en agents généraux ou courtiers d’assurances agrées par la SONAS et œuvrant désormais pour son compte moyennant paiements d’une commission de courtage calculée sur le nombre d’affaires qu’elles réalisaient.

Le système mis en place le 1e janviers 1967, c’est-à-dire quelques mois seulement après la création de la SONAS apporta des modifications fondamentales dans la structure de l’économie du Congo, notamment dans le secteur des assurances en transformant une structure économique libérale extravertie en une structures économique intégrées et autocentrée ou la périphérie et le centre se confondent en d’autres termes au lieu que le résultat d’exploitation ou la plus-value soit transformée à des milliers de kilomètres au-delà des frontières nationales comme ce fut le cas dans le temps, celui-ci reste au pays et est utilisé pour les investissements locaux.
Pour mener à bien sa tâche, la SONAS étendait ses activités sur l’ensemble du territoire national afin de faire face aux multiples sollicitations. C’est dans ce cadres que fut aussi implantée la succursale de la SONAS à Kisangani en Mars 1967 afin de rapprocher les assurés des assureurs en matière d’indemnisation des sinistrés.

Pour renforcer davantage le rapprochement entre assurés et assureurs une première restructuration de la SONAS fut effectuée en mars 1985. En effet, par ordre de service n°11/DG du 28 février 1985, la succursale de Kisangani a été érigée en Direction de région Nord-Est ayant autorité technico-administrative sur les succursales de Bunia et Isiro, ainsi que les bureaux de souscription de Buta, Mahagi, Aru et Watsa.

Compte tenu de la régression considérable des recettes de la Direction de Région NordEst qui ne parvenait plus à couvrir les couts d’exploitation, le conseil d’administration décida en mai 1991 la suppression de la Direction de région Nord-Est et de son remplacement par une sous-direction dirigée par un sous-directeur secondé par deux fondés de pouvoir. Ainsi créée, la succursale de la SONAS/Kisangani a été rattachée à la Direction de région du Sud-est à Lubumbashi.

I.2.1.3. SITUATION GEOGRAPHIQUE

L’Agence de la SONAS/KISANGANI est située dans la commune de la MAKISO, à côté de la librairie St Paul au numéro 15 boulevard du 30 juin. Avec un bâtiment en étage, au rez-de-chaussée nous retrouvons tous les services du pool technico-commercial, pool sinistré, ainsi que la caisse auxiliaire, et à l’étage, nous retrouvons le pool administratif et financier, la caisse centrale, le bureau du chef d’agence, une salle d’attente ainsi que le secrétariat.

I.2.1.4. OBJETIFS DE LA SONAS

Le statut de la société précise que la SONAS a pour objectifs :

  • 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 toutes les transactions immobilières notamment les locations et/ou les ventes des immeubles des tiers dont la gestion est confiée à la SONAS ;
  • D’effectuer les opérations financières et d’investissements s’y rattachant directement ou indirectement sur le territoire congolais.

I.2.1.5. MISSION SOCIALE DE LA SONAS

La SONAS a pour mission principale de sécuriser les personnes et leur bien et assurer également le développement du pays par des investissements dans plusieurs secteurs du pays en apportant des capitaux frais et résorbe aussi, le chômage en créant le marcher d’emplois.

I.2.1.6 ORGANISATION ET FONCTIONNEMENT
1.2.1.7 Au niveau de la Direction Générale.

La SONAS a une structure centralisée c’est-à-dire qu’elle applique la centralisation du pouvoir macro hiérarchique au niveau de la direction générale. En d’autres termes, les décisions importantes doivent provenir de la direction générale. Le siège social de la SONAS est à Kinshasa sur le boulevard du 30 juin dans la commune de la Gombe. Les principales directions de l’administration centrale de la SONAS sont :

  • Direction automobile ; – Direction incendie ;
  • Direction d’assurances vie ;
  • Direction des réassurances ;
  • Direction des A.R.D ;
  • De ses directions fonctionnelles ci-après ;
  • Direction des études et statistiques ;
  • Direction administrative et immobilière ; – Direction médicale ;
  • Direction de l’audit interne.

a) Le conseil d’administration
Au terme de la loi n°78/002, le conseil d’administration conçoit et trace la politique générale de l’entreprise et en assure le suivi.

b) Le comité de gestion

Il applique la politique du conseil d’administration dans l’entreprise. Les contributions sont définies par les textes légaux et réglementaires régissant l’organisation et le fonctionnement des entreprises du portefeuille de l’Etat.

c) Le collège des commissaires aux comptes

Il comprend le directeur Général et le Directeur Général Adjoint, la Direction du personnel est chargée de veiller à l’application des décisions du comité de Gestion. Le Directeur général gère l’entreprise au quotidien et coordonne toute les activités qui s’y déroulent. Il supervise les directions juridiques stations et informatique, audit interne, service généraux, recherches, Développement et Réassurances.

1.2.1.8 Au niveau des provinces : Les Directions ou Agences

Ces organes représentent le volet opérationnel de la présente restructuration en ce sens
qu’ils comprennent les agents qui descendent sur terrain pour s’occuper directement de la souscription de la police d’assurance et du règlement des sinistrés.

a) Pools
Ils regroupent plusieurs cadres et agents de grade divers, placé sous la supervision d’un
encadreur, cet organe présente l’avantage de privilégier la fonction par rapport au grade.

b) Les sous pools Ils sont constitué d’agents exerçant une tache précise et sont placés sous la responsabilité directe du pool. La caractéristique la plus dominante des agents y affectés est la polyvalence dans l’exercice de leurs fonctions.

c) Les bureaux Ils renferment le nombre d’agents dont la mission consiste à exécuter des tâches précises et parfois ponctuelles.

d) SONAS MAKISO KISANGANI
o Organisation structurelle de la SONAS/Kisangani
Sur le plan structurel, la SONAS/Agence de Kisangani est dirigée par un chef d’agence, un chef d’agence adjoint, des chefs de pools financier, administratif et technicocommercial.
o Les chefs d’agence
Placé sous l’autorité du Directeur de Région, il gère l’agence et veille au quotidien sur l’application de la politique de gestion tracée par la Direction Générale.

o Les Chefs d’Agence adjoint
Il assume les mêmes fonctions que son titulaire en cas d’absence de ce dernier.

1.2.2 ORGANIGRAMME DE LA SONAS AGENCE DE KISANGANI

Légende
I. Chef d’Agence
I.1 Secrétariat d’Agence II. Chef d’Agence Adjoint
III. Chef de Pool Technico-Commercial
III.1. Sous Pool Automobile
III.2. Sous Pool Incendie, Accidents Risques Divers (IARD)
III.3. Sous Pool Transport
III.4. Sous Pool Sinistrés & Archives
IV. Chef de Pool Administratif & Financier
IV.1. Sous Pool Administratif, Immobilier et Ressources Humaines
IV.2. Sous Pool Financier & Budgétaire

Chapitre Deuxième : ANALYSE CONCEPTUELLE DU SYSTEME
EXISTANT

L’analyse du système d’information existant est une étape très importante, elle concerne la description des différents documents utilisés au sein du système d’information actuel.
II.1. Analyse de la Communication
II.1.2 Définition des Concepts Communicationnels a. Définition L’analyse du système d’information existant a pour but de recueillir les données qui vont servir pour élaborer le diagnostic en vue de la recherche et de choix des solutions ou de la solution future permettant l’amélioration du système actuel.⁶
Un système est l’ensemble d’éléments en interaction poursuivant un but précis. Les éléments qui font l’interaction dans un système sont : Informations, Logiciels, Matériels, Personnels, Finances, Logistiques.)⁷
Un système est caractérisé par trois sous-systèmes à savoir :

  1. Sous système de pilotage : Le système de pilotage définit les missions et les objectifs, organise l’emploi des moyens, contrôle l’exécution des travaux. Il assigne des objectifs à l’organisation, analyse l’environnement et le fonctionnement interne à l’organisation, contrôle le système opérant. Il est relié aux autres systèmes par des flux d’informations internes.8
  2. Sous système d’opéra : Le système opérant est l’ensemble des moyens humains, matériels, organisationnels qui exécutent les ordres du système de pilotage. Il assure le fonctionnement du système global, son activité est contrôlée par le système de pilotage.
  3. Sous système d’information : Le système d’information est l’ensemble des ressources humaines, techniques et financières qui fournissent, utilisent, compilent, traitent et distribuent l’information de l’organisation. Il alimente l’organisation en informations d’origines diverses (internes ou externes). Il est la passerelle obligatoire pour toutes les informations de l’entreprise.
    L’une des décompositions désormais classiques du système d’entreprise en soussystème est la suivante : le système de pilotage, le système opérant et le système d’information. C’est à travers le système d’information que transite l’information réciproque au système de pilotage et le système opérant.
    Modèle d’une organisation selon la théorie des systèmes : 8

Figure N° 01 : Schéma de fonctionnement de système d’entreprise.
Source : Cours de MAI2

b. Modèle conceptuel des communications.

Appelé autrement le modèle conceptuel de flux ou diagramme de flux, le modèle conceptuel de communication est le résultat de l’expression des besoins des utilisateurs. Son but est de représenter le flux d’informations qu’échange le système avec ses partenaires et le flux d’informations qu’échangent les acteurs internes entre eux
La première étape de ce modèle est d’arriver à isoler le système en le délimitant. Il s’agit donc de définir le système et les éléments externes avec lesquels il échange des flux d’informations. Ces éléments extérieurs sont appelés acteurs externes (ou partenaires).
La seconde étape consiste à découper l’organisation en entités appelées acteurs internes (ou domaines). Lorsque les domaines d’une organisation sont trop importants, ils peuvent être décomposés eux-mêmes en sous-domaines.
La dernière étape est l’analyse des flux d’informations, c’est-à-dire la définition des processus.
C. Concepts des communications.

  • L’acteur (interne ou externe au domaine d’étude) est un système actif intervenant dans le domaine d’étude au moyen des flux.
     Le flux symbolise un échange entre deux acteurs du système d’information étudié. Il est représenté par une flèche, porte un nom et peut, pour soucis de lisibilité chronologique, être numéroté.
     Le diagramme de contexte a pour but de représenter les flux d’informations entre l’organisation et les acteurs externes selon une représentation standard dans laquelle chaque objet porte un nom.
     Le diagramme conceptuel de flux (appelé aussi modèle conceptuel de la communication) permet de compléter le diagramme de contexte en décomposant l’organisation en une série d’acteurs internes.
     Un Domaine est un système ou sous système qui a une mémoire et un SI. Il est fonctionnel et il joue un rôle. Un domaine peut se décomposer en sous domaines.
    Description textuelle
    La Gestion de paie des sinistres se fait de la manière suivante : la paie de sinistre
    s’effectue au cours de l’opération dénommée Jeudi Sinistre ; cette opération s’effectue après une instruction du chef d’agence qui sur proposition faite par le chargé des sinistres (sous pools sinistre) instruit les services de finances : Comptabilité et caisse de décaisser un montant de la dotation de la paie, une fois la dotation est disponible, le sous pool (service sinistre) vérifie les documents et différentes déclarations de sinistre au service d’expertise pour les analyses. Une fois les analyses faites, si les sinistres sont en ordre dans ces différents documents d’assurance la SONAS, à travers son service sinistre programme ces sinistres pour la paie de leur indemnité et lorsque ces derniers se présentent, le sous pools sinistre les orientes vers le service de finance pour toucher leur indemnité.
    II.1.3 Recensement des acteurs

Tableau n°1 : Recensement des acteurs
N° ACTEURS TYPES ROLE
01 Sinistre Externe Toute personne ayant subis un accident ou qui es aussi enregistré à la SONAS et à droits a une indemnisation.
02 Comptabilité Interne Tout un service de paiement de tout dommage
03 Chef d’agence Interne Il est chargé de tous coordonnée et instruit les opérations d’indemnisation
04 Service du sinistre (sous pools) Interne C’est un service chargé de la gestion de sinistre ainsi que les opération de leurs indemnisations.
05 Service d’expertise Interne Service charger de faire les analyses des dégâts, l’enregistrement de dossier et différentes déclaration de sinistre.
Sources : Nos propres investigations

II.1.4 Elaboration du Schéma de circulations des informations globales

Figure N°2 : Schéma de circulation des informations Présentation
Source : Nos Propres investigations
II.1.5 Elaboration du MCC

Le Modèle conceptuel de communication a pour but de modéliser les arcs de communication entre les différents intervenants ou acteurs d’un projet ou d’une application. C’est un modèle de circulation des informations dans l’organisation représentant au niveau conceptuel, les échanges d’information entre les acteurs.

Figure N°3 : Présentation du MCC Source : Nos Propres investigations
Legends

  1. Demande de proposition de l’opération de paie ;
  2. Autorisation de l’opération de paie au service sinistre ;
  3. Service sinistre instruit le service de caisse et comptabilité de décaisser l’argent de dotation de l’opération ;
  4. La caisse disponibilise l’argent de la dotation ;
  5. Vérification des documents de la souscription et la déclaration du sinistre au service d’expertise ;
  6. L’expertise confirme l’enregistrement et la déclaration du sinistre ;
  7. Le service sinistre invite ceux qui seront programmés et enregistré pour toucher leurs indemnités ;
  8. Présentation des sinistres au service sinistre ;
  9. Le service sinistre oriente le sinistre vers le service de caisse et comptabilité ;
  10. La caisse et comptabilité paye les indemnités des sinistres ;
    II.1.6 Elaboration du MOC

Le MOC est un modèle de merise qui nous permet d’organiser les communications en interne du système.
II.1.6.1. Recensement de poste des travaille
N° Poste de Travails Descriptions
1 Sous pools sinistre Le sous pool sinistre chargé de la gestion de sinistre ainsi que les opération de leurs indemnisations.
2 Chef d’Agence Il est chargé de tous coordonnée et instruire les opérations d’indemnisation ainsi que les différentes opérations de service de l’agence.
3 Service d’expertise Ils sont chargé d’analyser des dégâts, l’enregistrement de dossier et différentes déclaration des sinistres.
4 Comptabilité Service chargé de paiement de tout dommage
Tableau N°2 : Recensement de poste des travails
Source : Nos Propres investigations

II.1.6.2 Etablissement du MOC

Figure N°4 : Etablissement du MOC Source : Nos Propres investigations Légende :

  • Ecriture
  • Lecture
    II.2 Analyse des données
    II.2.1 Définition de concept Données
    a. Modèle Conceptuel de données (MCD)
    Le Modèle Conceptuel des données a pour but de décrire de façon formelle les données qui seront utilisées par le système⁷ d’information. Il s’agit donc d’une représentation des données, facilement compréhensibles, permettant de décrire le système d’information à l’aide d’entités et chaque entité est composée des propriétés.

b. Concept des données
• Entité : est un ensemble d’objets concrets ou abstraits de même nature. Elle est caractérisée par son nom et ses propriétés12. Ou encore, un ensemble d’informations relatives à un même objet, une même personne. C’est la représentation dans le système d’information d’un objet matériel ou immatériel.
• Propriété : est un attribut d’une entité ou d’une association. Les propriétés sont les informations de base du système d’information13. C’est aussi une rubrique d’une entité ou relation qui peut être mémorisée ou calculée.
• Identifiant : est une propriété permettant d’identifier de façon sûre et unique l’occurrence de l’entité14.
• Relation : C’est la prise en charge par le système d’information du fait qu’il existe un lien entre les objets. Elle représente les liens sémantiques qui peuvent exister entre deux ou plusieurs entités. Autrement appelée association qui est une liaison entre deux ou plusieurs entités avec une signification précise15.
• Cardinalité : c’est le nombre de fois qu’une occurrence d’entité participe à une relation.
La cardinalité d’un lien entre une entité et une association précise le minimum et le maximum de fois qu’un individu de l’entité peut être concerné par l’association.
• Occurrence : Est une valeur de la variable propriété ou de l’ensemble d’entités ou tout simplement c’est une valeur possible que peut prendre une entité ou une propriété16.
II.2.2 Dictionnaire des données
C’est un document qui permet de recenser, de classer et de trier toutes les informations (les documents) collectées dans une entreprise ou de l’étude des documents.
Nom Format Longueur Nature Règle de gestion
E, CO, CA SIG, M, SIT
Matricul_Ag AN 10 E SIG –
Nom_Ag AN 30 E SIG –
Postnom ag AN 30 E SIG –
Prénom_Ag AN 30 E SIG –
Genre_Ag AN 10 E SIG –
Adresse_Ag AN 10 CO SIG –
Fonction_Ag AN 30 E SIG –
Grade Ag AN 15 E SIG –
Email Ag AN 30 E SIG –
Téléphone_Ag AN 15 E SIG –
Etat-civil Ag AN 20 E SIG –
Id Sinistre AN 10 E SIG –
Nom_Sin AN 30 E SIG –

¹² KUTUMBAKANA P. Op.cit.
¹³ MAYAMONA E., Notes du cours de méthodologie d’analyse informatique II, G3 Informatique, ISC/Kisangani, 20192020, (inédit).

Postnom Sin AN 30 E SIG –
Prénom_Sin AN 30 E SIG –
Adresse_Sin AN 40 CO SIG –
Téléphone_Sin AN 15 E SIG –
Email Sin AN 30 E SIG –
Genre_Sin A 10 E SIG –
Etat-civil_Sin AN 20 E SIG –
Code-paie AN 10 E SIG –
Motif-paie AN 25 E SIG –
Montant AN 6 E SIG –
Date paie AN 25 E SIG –
Source : nôtre propre analyse.
Tableau N°3 : Dictionnaire des données

II.2.3 Graphe de dépendance fonctionnelle
L’élaboration de graphe de dépendance fonctionnelle est « une étape intéressante car elle épure le dictionnaire en ne retenant que les données non déduites et élémentaires et elle permet une représentation spatiale de ce que sera le futur modèle conceptuel des données

Figure N°5 : graphe de dépendance fonctionnel
Source : Nos propres investigations

II.2.4 Recensement de règle de gestion (RG)
RG1 : Le processus de paie s’effectue dans la matinée vers 07h30 à 16h30.
L’activité est 24h/24h
RG2 : Le rapport journalier de paie doit être établi et remis à chaque fin de la journée.
RG3 : Les agents sont libérés que si tous les rapports sont jugés conformes.
RG4 : Tous les sinistres devez passer à la comptabilité pour le paiement de leur indemnité.
RG5 : La fiche de paie est livrée que si le sinistre se présente à la réception.
RG6 : les sinistres doivent nécessairement être en ordre avec toute le condition d’assurance et document de déclaration pour être indemniser.
RG7 : le réceptionniste fourni la fiche de paie aux sinistres.

II.2.5 Elaboration du Modèle conceptuel de données

Figure N°6 : Model conceptuel de donnée
Source : Nos propres investigations

II.3. CRITIQUE DU SYSTEME D’INFORMATION EXISTANT

Après une étude approfondie du fonctionnement de l’entreprise, il nous incombe la tache de ressortir des défauts et qualités. Il ne s’agit pas de vouloir tout détruire sous prétexte que les nouvelles solutions seront proposées mais plutôt de dire ce qui est réel. ¹³
En effet, la critique de l’existant va nous permettre de cerner davantage les principaux problèmes et nous allons les analyser en deux volets : les points forts et les points faibles du système.
a. Points forts

  • Le climat de collaboration entre les agents est parfait ;
  • Chaque service (poste) exécute parfaitement son rôle et la distribution
    b. Points faibles
  • Nous avons remarqué que les documents sont conservés dans des papiers fardes qui peuvent être détruits facilement ;
  • Nous avons bien noté qu’il est difficile de retrouver dans quel dossier qu’on peut trouver les documents de tel ou tel cas de sinistre ;
  • Insuffisance des matériels de travail
  • Une file d’attente de personnes au niveau de la souscription ou au niveau du sous pools sinistre, de part une forte lenteur dans le travail.

c. Bilan du critique de l’existant La critique de l’existant que nous avons venons de faire, nous a permis de relever les points forts et points faibles de notre système existant.
Après analyse, nous arrivons à la conclusion selon laquelle l’informatisation de la
gestion de paie de sinistre s’avère inévitable pour l’amélioration du traitement des informations afin de rendre plus efficace et moderne le système existant.
d. Proposition des solutions
Après avoir décelé quelques faiblesses du système, il est à présent question de supprimer ces insuffisances en proposant des solutions très efficaces.
Pour y parvenir, nous pouvons opter pour la réorganisation du système en place en tenant compte des anomalies rencontrées. Apportant ainsi des solutions qui font intervenir l’ordinateur, permettant ainsi l’automatisation du système et la rapidité garantie.
Nous notifions que notre proposition n’est pas faite par intuition ou par hasards ;
 Avantage
L’augmentation de nombre des ordinateurs permettant donc à l’agent du sous pool sinistre et le service de finance de ne plus prendre beaucoup de temps au moments de la paie des sinistres.
 Inconvénients
Cette solution accuse certaine défaillance du système actuels non informatisé.
Alors nous pouvons dire :

  • Les taches seront plus fastidieuses ;
  • Lenteur de traitement d’informations ;
  • Pas de sécurité pour les données ; – Existence de plusieurs papiers ;
  • Retard dans la diffusion d’information ;

c. Scenario informatique
Cette solution consistera à mettre en place un logiciel en tenant compte des renseignements sur la gestion des sinistres.
Ce logiciel sera structuré essentiellement d’une base de données dont l’application sera destinée à gérer et traiter sera liée à la gestion des données.
 Avantage

  • Bonne sécurité et conservation des données ;
  • Diminution d’erreurs lors de la paie et l’enregistrement de documents de paie ;
  • Facilitation d’accès aux informations ;
  • Traitement rapide des données ;
  • Fiabilité de résultats ;
  • Mise à jour des données facile.

 Désavantage

  • Cout élevé des matériels et leurs entretiens ;
  • Retard et perte des données en cas de coupure de l’électricité ; – Inexigence d’un personnel qualifié. Chapitre Troisième : IMPLEMENTATION DU NOUVEAU SYSTEME ET
    PRESENTATION DE L’APPLICATION

Le troisième et dernier chapitre de notre travail est axé sur deux points : le premier
portera sur l’implémentation du nouveau système et le second sur la présentation de l’application. Au niveau de l’implémentation du système, nous développerons certains sous points comme l’implémentation des données (MLD, MPD) et celle de traitement (MCT, MOT, MLT, MLC).
En ce qui concerne la présentation de l’application, il sera question de présenter notre
application comme le signifie le titre. Tout en spécifiant les différents formulaires ou fenêtre de l’application, l’explication brève de son fonctionnement et une brève présentation de l’application et ces quelques états de sorties moyennant de printScreen (des images imprimées de l’écran).
III.1. Elaboration du modèle logique des communications

Figure N°7 : Model conceptuel de donnée
Source : nos propres investigations
III.2. Conception des traitements
III.2.1 Définition des concepts Traitements
 Evénement : c’est un fait observé dans le traitement d’information. Il est toujours représenté par une ellipse.
Types d’événements :
 Evénement déclencheur17 : Un fait qui poste le traitement. La de traitement.
 Evénement contributif 18: Un fait qui accompagne l’événement déclencheur dans le traitement.
 Evénement résultat19 : Un fait qui est observé après traitement. Il peut être à la fois un événement résultat et un événement déclencheur dans le traitement suivant.

  • Opération 20: Est une suite d’actions. Pour trouver les opérations, on se sert du diagramme de flux conceptuel de niveau le plus bas et on décompose les activités en un ensemble d’opérations élémentaires21.

III.2.2. Formalisme du MCT et MOT

 Figure N° 8 : Formalisme du MCT

Source : Nos propres investigations

¹⁴ MAYAMONA E., Notes du cours de méthodologie d’analyse informatique II, G3 Informatique, ISC/Kisangani, 2019-2020, (inédit).
¹⁵ KUTUMBAKANA Philémon, Méthodologie d’Analyse Informatique I (inédit), G2 IG, ISC-KIS, 2014-2015.
¹⁶ KUTUMBAKANA Philémon, op.cit.

 Figure N° 9 Formalisme du MOT
DEROUL EMENT ENCHAINEMENT DES PROCEDURES FONCTIONNELLES NAURE POST DE TRAVAIL
8 H OO A
15H30 M LIEU RESPO
SABLE RESOURCE
CAISS
E CAISS IER STYLO

CAHIER
LATTE
Source : Nos propres investigations
III.2.3. Etablissement du Modèle Conceptuel des Traitements

  1. Processus de Déclaration de Matériels
  2. Processus de Contrôle du dossier
  3. Processus d’indemnisation

III.2.4. Tableau de recensement des procédures fonctionnelles (PF)

  1. Processus d’indemnisation
    DEROULEMENT ACTION NATURE POSTE DE TRAVAIL
    LIEU RESPONSABLE RESSOURCE
    7h30′ à 16h30′ Paiement d’indemnité M Bureau Comptable Comptable
    7h30′ à 16h30′ Etablissement rapport M Bureau Comptable Comptable
    7h30′ à 16h30′ Envoie du rapport de paie M Bureau Agent Comptable
    Tableau N°6 : Processus de control dossier
    Source : Nos propres investigation

III.2.5. Etablissement du Modèle Organisationnel des Traitements
Les modèles organisationnels de traitement (MOT) définissent ce que fait chaque poste de travail, QUI FAIT QUOI ? Préalablement à ces modèles, l’organisation des postes de travail, QUI, est définie.
Le passage des modèles conceptuels de traitement (opérations effectués par des intervenants) aux modèles organisationnels de traitement (opérations effectuées par une structure organisée) n’est pas automatique. La construction de la structure des postes de travail apporte une dimension nouvelle qu’il faut assimiler. Les fonctions de l’entreprise sont « projetées » sur les postes de travail. Toute opération conceptuelle devra être exécuter de manière organisée par un poste de travail.
a. Définition des concepts organisationnels

 Poste de travail : Le découpage organisationnel de l’entreprise définit les postes de travail ou les unités d’organisation. « QUI », poste de travail est défini avant de déterminer « QUI FAIT QUOI ? » Un poste de travail est une responsabilité au sein de l’entreprise.
 Organigramme : L’organigramme est un dessin représentant la structure d’organisation des postes de travail de l’entreprise. Pour être défini sans ambiguïté, un poste de travail ne doit dépendre que d’un seul poste de travail amont (qui est responsable ?) et doit avoir ses responsabilités clairement énoncées (que fait-il ou que doit-il faire ?). Cela évitera d’embaucher un salarié pour faire A, lui faire faire B, le juger sur C et lui octroyer la médaille du travail pour D.
 Procédure fonctionnelle : Est un ensemble logique structuré d’actions élémentaires dont l’activation est provoquée par l’application d’un ou plusieurs événements. Elle est réalisée par un même acteur et son déroulement ne nécessite pas l’intervention d’autres événements ou acteurs.

a. Diagramme d’enchainement des procédures fonctionnelles. Le Diagramme d’enchaînement des procédures fonctionnelles met en lumière la transformation des opérations en procédures fonctionnelles dotées des aspects organisationnels suivants : le temps (périodicité, temps début, durée d’exécution), la nature, le poste de travail avec les ressources qui sont affectées. Dans le futur système, les procédures fonctionnelles apparaitront en effet comme des réactions concrètes d’Operations conceptuelles qui se situent à un niveau dénué de contraintes organisationnelles22

¹⁷ KUTUMBAKANA P., Op cit.

  1. Processus de déclaration de Matériels
  2. Processus de contrôle du dossier
  3. Processus d’indemnisation

III.2.6. Elaboration Modèle Logique des Traitements
Le modèle logique de traitement est la suite du MCT; il comprend la partie visible, la
spécification externe des transactions informatiques, le cheminement possible d’écran à écran après un menu principal et la partie non visible, interne, lecture et action d’écritures d’informations dans le modèle logique des données23.
Définition des concepts
 Outil transactionnel : il consiste à un traitement immédiat, ou en temps réel.
 Outils interactifs : consiste à un dialogue entre utilisateur et ordinateur via un écran et un clavier.
 Unité logique de traitement : est un ensemble des traitements informatiques aperçus comme homogènes en terme de finalités.
 Procédure logique : est un enchaînement logique de traitement réalisant l’information d’une tache ou phase de modèle organisationnel de traitement.

¹⁸ KUTUMBAKANA Philémon, op.cit.
¹⁹ MAYAMONA E., Notes du cours de méthodologie d’analyse informatique II, G3 Informatique, ISC/Kisangani, 2018-2019, (inédit).
²⁰ MAYAMONA E., Op.cit.
 Etat : c’est qui exprime les conditions préalables ou des résultats conditionnels d’une unité logique de traitement.
 L’évènement (message, Résultats) : tout ce qui représente l’échange de stimulus et de réponse par rapport au système.
 La Machine logique : est définie comme un ensemble de ressources informatique (matériels et logiciels) capables d’exécuter le traitement informatique de façon autonome bien que confondu dans la grande majorité de cas, mais nous pouvons signaler qu’il y’a une machine logique et une machine physique.

 Elaboration Modèle Logique des Traitements

III.3. Conception des Schémas des données
III.3.1. Implémentation du MCD Futur

Figure N° 9 : Model Conceptuel de Donnée
Source : Nos propres investigation

III.3.1.1. Dictionnaire des Données

Nom Format Longueur Nature Règle de gestion
E, CO, CA SIG, M, SIT
Matricul_Ag AN 10 E SIG –
Nom_Ag AN 30 E SIG –
Postnom ag AN 30 E SIG –
Prénom_Ag AN 30 E SIG –
Genre_Ag AN 10 E SIG –
Adresse_Ag AN 10 CO SIG –
Fonction_Ag AN 30 E SIG –
Grade Ag AN 15 E SIG –
Email Ag AN 30 E SIG –
Téléphone_Ag AN 15 E SIG –
Etat-civil Ag AN 20 E SIG –
Photo Ag Mémo 1 E SIG –
Id Sinistre AN 10 E SIG –
Nom_Sin AN 30 E SIG –
Postnom Sin AN 30 E SIG –
Prénom_Sin AN 30 E SIG –
Adresse_Sin AN 10 CO SIG –
Téléphone_Sin AN 15 E SIG –
Email Sin AN 30 E SIG –
Genre_Sin AN 10 E SIG –
Etat-civil_Sin AN 20 E SIG –
Photo Sin Mémo 1 E SIG –
Code-paie AN 10 E SIG –
Motif-paie AN 25 E SIG –
Montant N 6 E SIG –
Date paie AN 25 E SIG –
Source : nôtre propre analyse.
Tableau N° 7 : Dictionnaire de donnée

III.3.1.2. Graphe des dépendances fonctionnelles

Figure N° 10 : Model Conceptuel de Donnée
Source : Nos propres investigation

III.3.1.3. Recensement des règles de Gestion
RG1 : Le processus de paie s’effectue dans la matinée vers 07h30 à 16h00.
L’activité est 24h/24h
RG2 : Le rapport journalier de paie doit être établi et remis à chaque fin de la journée.
RG3 : Les agents sont libérés que si tous les rapports sont jugés conformes.
RG4 : Tous les sinistres devez passer à la comptabilité pour le paiement de leur indemnité. RG5 : La fiche de paie est livrée que si le sinistre se présente à la réception.
RG6 : les sinistres doivent nécessairement être en ordre avec toute le condition d’assurance et document de déclaration pour être indemniser.
RG7 : le réceptionniste fourni la fiche de paie aux sinistres

III.3.1.4. Quantification des données

Entité Identification Propriétés Longueurs Nbr d’occurrence
Agent Matricul Ag Nom_Ag
PréNom_Ag
Téléphone_Ag
Genre_Ag
Grade_Ag
Fonction_Ag
Adresse_Ag
Photo_Ag 136 136100 = 136000 Sinistre Id Sinistre Nom_Sin Post Nom_Sin Pré Nom_Sin Téléphone_Sin Adresse_Sin Photo_Sin 126 126100=12600
Paie Code paie Motif
Montant
Date paie 56 56*100 = 5600
Total 267600
Tableau N° 8 : Dictionnaire de donnée Source : nôtre propre analyse.

III.3.2. Elaboration du Modèle Organisationnel des Données 

Le modèle organisationnel des données se réalise par poste de travail, tout en spécifiant le droit d’accès sur les données. Donc le droit d’accès ici, c’est comme dire : Qui a le droit de supprimer (Supprimer), de lire (Lire), d’ajouter (Ajouter), de modifier (Modifier) dans telles ou telles données de telles ou telles entités.

Le MOD marche de pair avec le MCD mais ce qui le différencie est seulement qu’il s’établi par poste de travail et la signification de droit d’accès qui est défini au niveau du MOD.

Figure N° 11 : Model Organisationnel de Donnée
Source : Nos propres investigation
Legends

  • A : Ajouter – S : Supprimer
  • V : Vérifier – M : Modifier
  • C : Consulter
    III.3.3. Elaboration du MLD et Présentation MPD
     Modèle logique de données
    La modélisation logique de données est une étape qui permet de représenter la
    structure statique du système d’information sous forme d’un modèle de donnés relationnel. Elle a pour but de représenter par un formalisme presse et standardise l’ensemble des tables qu’il faudrait créer pour réaliser le projet décrit dans le MCD.24
     Passade du MOD au MLD relationnel
    Le passage est une opération qui consiste à quitter d’un niveau pour un autre. Pour le MOD au MLD, ce passage se fait à deux niveaux d’une façon résumée :
    o Règle de passage o Changement du vocabulaire
     L’objet se transforme en table ;
     L’identifiant de l’objet devient la clé primaire de table ;
     Les propriétés des objets deviennent les attributs des tables.
    o Règles pour les relations Emmanuel MAYAMONA, MAI2, G3 Info, ISC-KIS 2019-2020
    Les relations dans les sens conceptuel ou organisationnel subissent plusieurs traitements. Ainsi, différents cas se présentent :
    1°. Cas de relation du type Père – fils : La relation disparaisse et les clés de la table père est héritée par le fils, ainsi que les propriétés de la relation si elles existent, Leur cardinalité se présente comme suite (1,1) -(1, n) ;(0, n) -(1,1)
    2°. Cas de relation autre que Père – fils : La relation devient tables de lien, hérite clé des objets qui ont participés à la relation y compris ses propriétés s’il existe. Leur cardinalité se présente comme suite (1, n) -(1, n) ;(0, n)-(1, n) Ainsi, le model organisationnel des données qui subit les règles de passage devient le modèle logique des données Brut (MLD Brut).
    3°. Cas particulier : Le cas particulier concerne les relations portant les cardinalités (1,1) (1,1) ou (0,1) -(1,1) Ces couples de cardinalité constituent des cas particuliers de relations du type père – fils et ne sont traitées rarement dans la méthode Merise.
    Ainsi, le modèle organisationnel des données qui subit les règles de passage devient le modèle logique des données Brut (MLD Brut).25
     Elaboration du MLD
    • T_Agent (Matriculag, Nomag, Postnomag, Prénomag, Fonction Ag, Grade Ag, GrenreAg, Adresseag, Telephoneag, Emailag, PhotoAg)
    • T_Sinistre (Id Sin, NomSin, PostnomSin, PrénomSin, Adresse Sin, Genre Sin,
    TelephoneSin, EmailSin, Etat_civil Sin, Photo Sin, #Matriculag)
    • T_Paie (Id Paie, Motif paie, Montant paie, Date paie, #Id Sinistre)  Modèle logique de donnée relationnel (MLDR)

Figure 12 : Elaboration de MLDR

Source : Nos propres investigations

Emmanuel MAYAMONA, Op cite.
 Modèle Physique de Données
Le modèle physique des données (MPD) est la traduction du modèle logique des données (MLD) dans une structure de données spécifique au système de gestion de bases des données (SGBD) utilisé. Le MPD est donc représenté par des tables définies au niveau du système de gestion de bases des données. C’est donc au niveau du MPD que nous quittons la méthode générale de création d’un MCD et de sa transformation en MLD, pour nous tourner vers la manipulation d’un SGBD spécifique26.

  • Passage du MLD au MPD
    Le passage du MLD au MPD est automatique mais tient compte du SGBD. Les critères du passage sont les suivantes :
     Les tables deviennent des fichiers avec extension du SGBD choisie ;  Les attributs deviennent des champs des fichiers ;
     Les clés primaires ou secondaires deviennent les clés d’accès.
    Donc, ce passage consiste à créer la structure de la base de données suivant le
    schéma relationnel et ce, à partir de l’ordinateur.27 Nôtre MPD se présente de la manière suivante :

²³ KWASSIA ILANGA., Langage de Programmation III (inédit), G3 IG, ISK-KIS, 2019-2020 ²⁴ Emmanuel MAYAMONA, Op cite.
III.4. Présentation de l’Application
III.4.1. Proposition de l’environnement
Pour réaliser ce projet nous avons proposé le WIDEV comme environnement de développement et le Wlangage comme environnement d’implémentation pour la réalisation de notre application.
III.4.2. Proposition de l’environnement d’implémentation
Pour réaliser ce projet nous avons proposé le Wlangage comme environnement
d’implémentation pour la réalisation de notre application.
Le Wlangage est un langage de programmation de 5e génération inclus dans les outils de développement WinDev, Webdev et WinDev Mobile. Il est propriétaire et ne peut être manipulé qu’avec les outils PC SOFT. Le Wlangage est né en 1992 avec la première version de WinDev. Même s’il y a explicitement une première phase précoce de compilation, le bytecode Wlangage est exécuté par une machine virtuelle ou converti en code natif lors de l’exécution par un compilateur à la volée (Just in time, JIT). Le Framework est disponible sous Windows (32bit, 64bit et CE). Sous Ios (iPhone et iPad) et sous Linux.
Les Wlangage peut également s’appuyer sur le Framework Java pour une partie de ses fonctionnalités, ce qui permet une indépendance relative et limitée du fichier exécutable par rapport au système d’exploitation cible. Il en va de même dans Webdev, où le Wlangage peut s’appuyer sur le Framework PHP, sans toutefois permettre d’utiliser toutes les possibilités de ce dernier.
Initialement prévu pour Windows, une partie des fonctions du Wlangage est basée sur
l’API Microsoft Windows. Le Wlangage est disponible sous Windows, Linux, Solaris, Mac OS X ou sous une version indépendante des systèmes d’exploitation.

  • Choix de Base de Donnée
    HFSQL est une base de données relationnelle libre qui a vu le jour en 1995 et très employées sur le Web, souvent en association avec WEBDEV (Langage) et Internet IIS (serveur web).
    HFSQL fonctionne Indifféremment sur tous les systèmes d’exploitation (Windows, Linux, Mac OS notamment). Le principe d’une base de données relationnelle est d’enregistrer les informations dans des tables qui représentent des regroupements de Données par sujets (table des produits, table d’utilisateur par Exemple). Les tables sont reliées entre elles par des relations.
    HFSQL est une base de données à la foi très puissante, très rapide et très robuste. Fonctionne sous Windows et Linux, sur les Mobiles (iOS, Android, Windows), sur les réseaux de toute taille et de tout type, et gère automatiquement plusieurs certaines d’accès simultanés.
    HFSQL est disponible en version Classique et en Client/serveur. La diffusion de HFSQL est libre et gratuite sur vos site Webdev.
    Pour notre travail nous avons utilisé HFSQL classic est un fichier réseaux local ou monopole
    Si votre ordinateur est équipé de Windows 7, l’installation de HFSQL se fait, à l’intérieure de plateforme WEBDEV et l’installation dans le lecteur approprié. Ainsi suivez les instructions d’installation, puis cliquez sur next (suivant), jusque à atteindre finish.
    A la fin une icône en forme qui apparait au centre de menu de Windows7.
    III.4.2. Description de l’environnement de développement
    WinDev 20 : est un atelier de génie logiciel (AGL) édité par la société française PC SOFT et conçu pour développer des applications, principalement Orientées données pour Windows et également pour Linux, NET et Java. Il propose son propre langage : le Wlangage.
    La première version de l’AGL est sortie en 1993.
    Webdev, pour la conception d’application web et WinDev Mobil lui sont apparentés pour la conception d’application mobil.
    III.4.3. Brève Présentation de l’Application
    Notre application s’appelle GesPaie v1.0 dire Système de Gestion de Paie, réalisé dans le souci de faciliter la gestion de paie de sinistre au sein de la SONAS-Kisangani.
    III.4.3.1. Explication Fonctionnelle de l’application
    C’est trop simple de lancer cette application, il suffit qu’aux utilisateurs de respecter le chemin d’accès. Qui fonctionne de la manière suivante :
  1. Fenêtre d’accueils
  • INTERFACE D’ACCUEIL OU DE CHARGEMENT : un message d’accueil qui présente l’application. Capture N° 1 : Fenêtre d’accueil ou chargement
    Source : Notre application
  1. INTERFACE D’AUTENTIFICATION
    Pour sécuriser l’accès au logiciel, Il doit saisir son nom utilisateur et son mot de passe si le système lui reconnaît il aura l’accès à l’application si non, il n’aura pas d’accès. Capture n°2 : fenêtre d’authentification Source : Notre application
  2. INTERFACE MENU PRINCIPAL
  • MENU PRINCIPAL : ensemble de fonctionnalité d’un logiciel. Autrement appelé : Couche applicative ou de distribution : elle représente les fonctionnalités de logiciel.

Capture n°3 : Interface de menu général
Source : Notre application
L’affichage des interfaces à ce niveau est proportionnel au choix de notre utilisateur.
S’il choisit d’enregistrer par exemple les informations sur les sinistres, sur l’agent ou sur une nouvelle fiche de paie et gérer les autres interfaces. Voici les images correspondantes à chaque interface citée précédemment :

  1. INTERFACE AGENT : permet à l’utilisateur de manipuler les données concernant les agents.

Capture n°3 : Interface d’enregistrement de l’agent
Source : Notre application

  1. INTERFACE SINISTRE : permet à l’utilisateur de manipuler les données concernant les sinistres. Capture n°4 : Interface d’enregistrement du sinistre
    Source : Notre application
  2. INTERFACE PAIE : permet à l’utilisateur de manipuler les données concernant les sinistres.

Capture n°5 : Interface d’enregistrement du paie
Source : Notre application

Après la saisie des informations par l’utilisateur dans chacune des interfaces ci-haut, ce dernier peut faire un rapport à la hiérarchie grâce aux états imprimables tels que. La liste de paie générale partant d’une période définie ainsi que le reçu de paie. Ces états sont illustrés par les images suivantes ci-dessous :

 INTERFACE REQUETTE RECU : permet à l’utilisateur de saisir le numéro du reçu auquel il souhaite imprimer.

Capture n°7 : Interface de paramètre de recherche Source : Notre application.

 INTERFACE REQUETTE LISTE DE PAIE PARTANT D’UNE PERIODE BIEN DEFINIS : Cette requête permet à l’utilisateur de saisir la date auxquelles il souhaite imprimer la liste des paies partant d’une période.

Capture n°8 : Interface de paramètre de recherche partant du date début et d’une date de fin Source : Notre application
o RECU DE PAIE : Ceci est l’aperçu d’un reçu de paie à imprimer.

Source : Notre application

o ETAT LISTE DE PAIE PARTANT D’UNE PERIODE : Ceci est l’aperçu de la liste des exploitants à imprimer.

Capture n°8 : Etat liste de paie partant d’une période déterminer
Source : Notre application

CONCLUSION
Nous arrivons au terme de notre travail qui sanctionne la fin de notre premier cycle à l’Institut Supérieur de Commerce de Kisangani en sciences informatiques, option Informatique de gestion. Il est intitulé « Implémentation d’une application informatique pour la gestion de paie de sinistre au sein de la SONAS MAKISO/Kisangani ».
Nous sommes partis d’un constat selon lequel les opérations manuelles dont la SONAS MAKISO/Kisangani fait preuve, Occasionnent des lenteurs dans le traitement de l’information et entraine des conséquences négatives.
De ce constat, notre problématique a été articulée autour des questions suivantes :
 La paie de sinistrés manuellement est-elle vraiment une solution efficace et rentable au sein de la SONAS ?
 Serait-il opportun d’implémenter un système automatisé de gestion des paies de sinistrés au sein de la SONAS ?
 Quels sont les avantages d’utilisation d’un système informatique dans la gestion des paies des sinistrés au sein de la SONAS ?
Eu égard aux questions posées ci-dessus, nous pouvons émettre les hypothèses ci-
après :
• La paie de sinistrés manuellement ne serait pas une solution efficace et rentable au seins de la SONAS.
• Oui, l’implémentation d’une application informatique conviendrait mieux pour assurer l’organisation et la structuration des activités de la paie de sinistrés au sein de la SONAS.
• Les avantages d’utilisation d’un système informatique dans la gestion des courriers seraient la sécurité des données et la cohérence des informations.
Pourtant, nous avons trouvé opportun de mener une étude sur la gestion des paies de sinistre en vue de proposer une solution adéquate, en créant une application avec le langage de programmation Wlangage et HFSQL comme système de gestion de base de données, capable de produire les états ci-après :
• Reçu des paies ;
• Liste de paie générale partant d’une période définis ;
Vue ce qui précède, nous pouvons conclure que nos deux hypothèses sont confirmées.
N’étant pas le premier à aborder ce thème, nous ne prétendons pas avoir épuisé tous les contours du sujet, d’autres chercheurs aborderont certains aspects que nous n’avons pas touchés en réalisant cette étude, dont notamment l’implémentation d’une application informatique pour la gestion de paie des sinistres au sein de la SONAS MAKISO/Kisangani.
Compte tenu de l’imperfection humaine et vu que le travail scientifique ne manque jamais les lacunes nécessitant d’être améliorées après la consultation d’autres chercheurs dans la même thématique, toute suggestion, critique et remarque trouverons en nous une terre fertile.
Le monde étant ouvert à travers les nouvelles technologies de l’information et de la communication, nous restons unis avec les autres chercheurs et scientifiques du domaine pour l’évolution participative de la science.

BIBLIOGRAPHIE

I.  OUVRAGES 
  • Dictionnaire Encarta 2009
  • Dictionnaire le Grand Robert
  • Bruno CLAPARADE, Etude de Recherche Scientifique, UNIKIS 2013, p.45
  • PAILLE, P. et MUCHIELLI, A, 2003, L’analyse qualitative en sciences humaines et sociales, Paris, Arnaud collin, p.16.
  • Peter Drucker, l’art du management, édition Print Hall 2003, p.132
    II. TFC ET MEMOIRE
  • ILONDO EKANGOLAKA Jephté, conception et réalisation d’une application informatique pour la gestion des sinistres « cas de la SONAS MAKISOKISANGANI », TFC, inédit, ULIKIS, 2019-2020
  • SITUNGWO NGOY Pascal, la mise en place d’une application pour la gestion des sinistrés automobile au sein de la SONAS-Kisangani, TFC, inédit, ISC-KIS, 20192020.
    III. COURS
  • KUTUMBAKANA Philémon, Méthodologie d’Analyse Informatique I (inédit), G2 IG, ISC-KIS, 2014-2015.
  • KWASIA ILANGA., Langage de Programmation III (inédit), G3 IG, ISK-KIS, 20192020
  • LOKANGA OTIKEKE F., Méthode de recherche scientifique (inédite), G2 IG, ISCKIS, 2013-2014.
  • MAYAMONA E., Notes du cours de méthodologie d’analyse informatique II, G3 Informatique, ISC/Kisangani, 2019-2020, (inédit).
  • VITAMARA KITAMBALA, Cours de la Méthodes de recherche scientifique, G2 IG, ISP-KIS, 2013-2014.
  • WILIWOLI SIBILONI, Cours de Méthode de recherche scientifique, G2 Informatique, ISC-KIS, 2018-2019.

WEBOGRAPHIE

  • www.wikipedia.com
  • www.commentçamarche.com
  • www.memoireonline.com http://codes-sources.commentcamarche.net/source/52702-gestion-simple- d-une-baseaccess

TABLE DES MATIERE
EPIGRAPHE…………………………………………………………………………………..……….i
DEDICACES…………………………………………………………………………………..……….ii REMERCIEMENTS…………..……………………………………………………………..………..iii
SIGLES ET ABREVIATION.………………………………………………………………………..iv
O. INTRODUCTION ………………………………………………………………………………………………… 1
0.1 ETAT DE LA QUESTION …………………………………………………………………………………… 1 0.2 PROBLEMATIQUE ……………………………………………………………………………………………. 2 0.3 HYPOTHESES ……………………………………………………………………………………………………. 3 0.4 OBJECTIFS DU TRAVAIL ………………………………………………………………………………… 4 0.5 CHOIX ET INTERET DU SUJET ……………………………………………………………………….. 4
0.5.1 CHOIX DU SUJET …………………………………………………………………………………………………. 4 0.5.2 INTERET DU SUJET ……………………………………………………………………………………………… 4
0.6 METHODOLOGIES ET TECHNIQUES UTILISEES …………………………………………. 4
0.6.1 METHODES ………………………………………………………………………………………………………… 4 0.6.2 TECHNIQUES ……………………………………………………………………………………………………… 5
0.7 DELIMITATION DU SUJET ………………………………………………………………………………. 5 0.8 DIFFICULTES RENCONTREES ………………………………………………………………………………….. 5 0.9 SUBDIVISION DU TRAVAIL ……………………………………………………………………………… 6
CHAPITRE PREMIER : PRESENTATION DU MILIEU D’ETUDE ET DEFINITION DES CONCEPTS CLES ……………………………………………………………………… 7
1.1 DEFINITIONS DES CONCEPTES CLES DU SUJET. ………………………………………….. 7 1.2 PRESENTATION DU MILIEU D’ETUDE ………………………………………………………….. 7
1.2.1.1. ORGANISATION DU MARCHER CONGOLAIS D’ASSURANCE ………………. 8
1.2.1.2. HISTORIQUE ………………………………………………………………………………………………. 8 I.2.1.3. SITUATION GEOGRAPHIQUE ……………………………………………………………………. 9 I.2.1.4. OBJET DE LA SONAS …………………………………………………………………………………… 9 I.2.1.5. MISSION SOCIALE DE LA SONAS …………………………………………………………….. 10 I.2.1.6 ORGANISATION ET FONCTIONNEMENT ………………………………………………… 10
1.2.1.7 AU NIVEAU DE LA DIRECTION GENERALE. ……………………………………………………….. 10
1.2.2 ORGANIGRAMME DE LA SONAS AGENCE DE KISANGANI……………………… 12
CHAPITRE DEUXIEME : ANALYSE CONCEPTUELLE DU SYSTEME EXISTANT ….. 13
II.1.1 ANALYSE DE LA COMMUNICATION ……………………………………………………………………. 13 II.1.2 DEFINITION DES CONCEPTS COMMUNICATIONNELS ……………………………………………. 13
DESCRIPTION TEXTUELLE …………………………………………………………………………………………. 15 II.1.3 RECENSEMENT DES ACTEURS ……………………………………………………………………………. 15
II.1.4 ELABORATION DU SCHEMA DE CIRCULATIONS DES INFORMATIONS GLOBALES ……… 16
II.1.5 ELABORATION DU MCC …………………………………………………………………………………… 17 II.1.6 ELABORATION DU MOC …………………………………………………………………………………… 17
II.1.6.1. RECENSEMENTS DE POSTES DES TRAVAILLES ………………………………………………….. 18 II.1.6.2 ETABLISSEMENT DU MOC …………………………………………………………………………….. 18
II.2 ANALYSE DES DONNEES ………………………………………………………………………………………. 18
II.2.1 DEFINITION DE CONCEPTS DONNEES …………………………………………………………………. 18 II.2.2 DICTIONNAIRE DES DONNEES ……………………………………………………………………………. 19 II.2.3 GRAPHE DE DEPENDANCE FONCTIONNELLE ……………………………………………………….. 20 II.2.4 RECENSEMENT DE REGLE DE GESTION (RG) ………………………………………………………. 20 II.2.5 ELABORATION DU MODELE CONCEPTUEL DE DONNEES ……………………………………….. 21
II.3. CRITIQUE DU SYSTEME D’INFORMATION EXISTANT …………………………….. 21 CHAPITRE TROISIEME : IMPLEMENTATION DU NOUVEAU SYSTEME ET………
PRESENTATION DE L’APPLICATION ………………………………………………………………… 24
III.1. ELABORATION DU MODELE LOGIQUE DES COMMUNICATIONS ………… 24 III.2. CONCEPTION DES TRAITEMENTS ……………………………………………………………………….. 24
III.2.1 DEFINITION DES CONCEPTS TRAITEMENTS ……………………………………………………….. 25 III.2.2. FORMALISME DU MCT ET MOT …………………………………………………………………….. 25
III.2.3. ETABLISSEMENT DU MODELE CONCEPTUEL DES TRAITEMENTS ………………………… 26
III.2.4. TABLEAU DE RECENSEMENT DES PROCEDURES FONCTIONNELLES (PF) ………………. 29
III.2.5. ETABLISSEMENT DU MODELE ORGANISATIONNEL DES TRAITEMENTS ……………….. 29
III.2.6. ELABORATION MODELE LOGIQUE DES TRAITEMENTS ……………………………………… 33
III.3. CONCEPTION DES SCHEMAS DES DONNEES …………………………………………………………. 35
III.3.1. IMPLEMENTATION DU MCD FUTUR ………………………………………………………………… 35
III.3.1.1. DICTIONNAIRE DES DONNEES ………………………………………………………………………. 35 III.3.1.2. GRAPHE DES DEPENDANCES FONCTIONNELLES ……………………………………………… 36 III.3.1.3. RECENSEMENT DES REGLES DE GESTION ………………………………………………………. 36 III.3.1.4. QUANTIFICATION DES DONNEES …………………………………………………………………… 37
III.3.2. ELABORATION DU MODELE ORGANISATIONNEL DES DONNEES …………………………. 37
III.3.3. ELABORATION DU MLD ET PRESENTATION MPD ……………………………………………. 38
III.4. PRESENTATION DE L’APPLICATION ……………………………………………………….. 41
III.4.1. PROPOSITION DE L’ENVIRONNEMENT ……………………………………………………………… 41 III.4.2. PROPOSITION DE L’ENVIRONNEMENT D’IMPLEMENTATION ……………………………….. 41 III.4.2. DESCRIPTION DE L’ENVIRONNEMENT DE DEVELOPPEMENT ……………………………….. 42 III.4.3. BREVE PRESENTATION DE L’APPLICATION ……………………………………………………… 42
III.4.3.1. EXPLICATION FONCTIONNELLE DE L’APPLICATION ……………………………………….. 42
CONCLUSION ……………………………………………………………………………………………………….. 47 BIBLIOGRAPHIE ………………………………………………………………………………………………….. 49 I. OUVRAGES ………………………………………………………………………………………………………… 49 II. TFC ET MEMOIRE ……………………………………………………………………………………………. 49 III. COURS …………………………………………………………………………………………………………….. 49 WEBOGRAPHIE ……………………………………………………………………………………………………. 49