1

INTRODUCTION GENERALE
1. PRESENTATION DU PROJET

Il est nécessaire que l’évolution de nos modes de vie, des techniques de gestion des
méthodes de recherches qui caractérise les divers domaines de la science passe par la décision
de recouvrir l’informatique.1
L’informatique est appelé à prendre une place de choix dans les diverses activités de la
vie humaine ;
Compte tenu de cette place de choix prise par l’informatique dans le monde moderne,
nous pouvons interpeller l’interface à ce double défit ; prendre conscience de la réalité
informatique et comprendre ce qu’elle implique réellement. Par là nous comprenons
l’importance de l’informatique au sein du service de demande et réclamations des abonnés de
la Regideso.

Etant donné que la mise en œuvre et l’exploitation des systèmes informatiques dans une
entreprise représente une tâche complexe et dont l’utilisation demande des compétences
spécialisées, nous allons dans les lignes qui suivent, montrer la démarche d’informatisation.

Il s’agit d’appliquer les méthodes et techniques de développement d’une application

informatique de gestion des réclamations des abonnées au sein de l’Agence de Gombe de la
Regideso.

2. ETAT DE LA QUESTION

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. Il définit le
sujet dans le temps et dans l'espace, en précise les acteurs et les différents aspects (politiques,
économiques, juridiques, etc.), les sources et ressources d'information. Il s'appuie sur une
importante bibliographie de la littérature du domaine.

L'état de la question consiste à examiner les résultats des recherches antérieures existants
dans ce domaine et qui permet aux chercheurs de situer son apport par rapport à ces travaux...
ceci l'aidera de recueillir des informations générales utiles pour sa recherche retenue2.

1
KOLA MASALA, Notes de cours d’initiation à l’informatique, GI info, ISC- Kin, 2002- 2003
2
J.P. FRANGIER, Comment réussir un mémoire, Dunod, Paris, 1986, P.17
 2

Nous tenterons de suivre le modèle précédent de nos prédécesseurs, qui ont réussi à mettre en
place des systèmes d’information capables de gérer les réclamations des abonnés.

3. PROBLEMATIQUE
Dans ce point de notre travail de fin de cycle, il est question de présenter ce qui pose
comme problème dans la gestion des réclamations.
Après avoir eu le temps de sillonner le service de cette organisation, nous avons recensé
les difficultés ci-après :
 La lenteur de traitement des données ;
 La mauvaise conservation des documents ;
 Le risque de perte des documents ;
 Le manque des matériels appropriés pour le traitement des informations.

Poussé par ces raisons nous pouvons résumer notre problématique de la manière suivante
- Est-ce que l’ordinateur peut-il faire quelque chose pour la gestion de réclamations ?
- Si oui alors quelles sont les voies et moyens pour y arriver ?
- Quel est le mal si l’on trouve les voies et moyens pour faire intervenir un outil
informatique dans la gestion de réclamations ?
Ainsi, ces questions trouveront les réponses dans les lignes qui vont suivre.

4. HYPOTHESE
Par sa définition une hypothèse est une réponse provisoire à la problématique3. Dans le cas
d’espèce, nous envisageons que l’informatisation de la gestion de la réclamation des abonnés
apportera un rendement positif. Il y a lieu de souligner que sous d’autres cieux l’enregistrement
de réclamations se fait automatiquement. Raison de plus pour faire intervenir l’ordinateur dans
la gestion de réclamations.

5. METHODOLOGIE DE RECHERCHE
a. Méthode

La méthode est définie comme étant l’ensemble des opérations intellectuelles par
lesquelles une discipline cherche à atteindre les vérités qu’elle poursuit, les démontre et les

3
Hypothèse, http://fr.wikipedia.org/wiki/hypothèse, consulté, le 10/08/2021 à 14h30.
 3

vérifie4. Elle est un chemin, un ensemble de règles ou de procédés à suivre pour atteindre un
objectif dans les meilleures conditions.

Signalons qu’il existe une variété de méthodes de récolte des données dont le choix
dépend des objectifs de la recherche de la nature des informations que l’on veut obtenir.

Pour la rédaction de notre travail, nous allons faire appel à la Méthode MERISE, qui est
une méthode d’étude de réalisation informatique que le système de l’entreprise, nous a permis
de concevoir notre projet informatique.
b. Techniques

Une technique est l’ensemble des procédés qu’on doit méthodiquement employer pour
une recherche dans un métier. Les différentes techniques utilisées pour la récolte des
informations sont les suivantes :

 Technique d’interview : Pour des plus amples précisions et détails relatifs au service
de l’enseignement, nous avons recouru à des interviews auprès des agents de l’institut.

 Technique d’observation : Celle-ci nous a aidé à observer avec attention et curiosité

le processus d’avant et d’après l’étape de la rédaction de diplôme.

 Technique de documentation : Nous nous sommes servies des ouvrages, des cours et
des documents utilisés au sein de l’institution pour une étude approfondie de notre
travail.

6. OBJECTIF PRINCIPAL DU TRAVAIL

Il y a lieu de souligner que nos investigations ses sont effectuées au sein de la

REGIDESO durant la période de 2019 à nos jours et pendant ces investigations, nous avons fait
un constat amer sur l’enregistrement de réclamations dans ce sens, qu’avec le nombre des
personnes à gérer il est inconcevable de les gérés manuellement et suite à cette façon de gérer
les réclamations des abonnés, il se dégage un besoin cruel de l’informatisation. Raison pour
laquelle nous avons porté notre choix et intérêt à ce sujet. L’objectif que nous poursuivons dans
la rédaction de ce travail est celui d’aider la REGIDESO d’avoir un système d’information et
une base de données fiable qui permet une gestion efficace des réclamations des abonnés.

7. STRUCTURE DU TRAVAIL

4
Méthode, http://fr.wikipedia.org/wiki/méthode, consulté, le 10/08/2021
 4

En dehors de l’introduction et la conclusion, notre travail est subdivisé en deux grandes

parties et chacune de parties est subdivisée en chapitres qui sont :

1ère partie : Etude préalable qui comporte deux chapitres dont :

- Chapitre 1 : Présentation de l’entreprise,

- Chapitre 2 : Analyse de l’existant ;
- Chapitre 3 : Critique, diagnostic de l’existant et recherche des solutions.

Dans la 2ème partie de Mise en place du nouveau système d’information, on développera

aussi trois chapitres dont :

- Chapitre 1 : Modélisation du système d’information organisé. (SIO)

- Chapitre 2 : Modélisation du système d’information informatisé. (SII)
- Chapitre 3 : Développement du système d’information informatisé.

PREMIERE PARTIE :
ETUDE PREALABLE
 5

Cette partie consistera à donner l’image de la REGIDESO, de la situation géographique

au diagnostic de l’existant, qui sera composé de deux chapitres comme suit :

- Chapitre I : Présentation de l’organisation

- Chapitre II : Analyse de l’existant
- Chapitre III : Critique, diagnostic de l’existant et recherche des solutions
 6

CHAPITRE I : PRESENTATION DE LA REGIDESO

Introduction
Dans ce chapitre nous présentons notre champ de recherche en commençant par son
historique et son objectif.

I.1. Situation géographique de la REGIDESO S.A.

La REGIDESO est une entreprise publique qui fournit de l’eau et est implantée sur toute
l'étendue de la République Démocratique du Congo. Son siège social est situé à Kinshasa dans
la commune de la Gombe au croisement du boulevard du 30 juin et de l'avenue de la démocratie
(ex huilerie).

I.2. Historique de la REGIDESO S.A.

L'histoire de la REGIDESO comprend trois grandes périodes à savoir :

 Période précoloniale ;
 Période coloniale ;
 Période post coloniale

A. Période précoloniale.

L'histoire de l'eau en République Démocratique du Congo remonte de temps ancien. Elle a

évolué au fil du temps en s'adaptant aux exigences modernes issues de l'évolution de la
technologie.

Avant la colonisation, l'approvisionnement en eau revêtait un caractère rudimentaire, c'est-à-

dire l'eau puisée à la source était directement utilisée en fonction des besoins domestique.
Autrement dit sous cette période, il n'existait aucune organisation s'occupant de l'adduction et
de la stérilisation de l'eau.

B. Période coloniale

Les besoins en eau potable des colonisateurs et le souci d'adapter la colonie aux exigences
modernes d'une part, et la croissance démographique et le progrès techniques d'autre part,
conduit l'autorité coloniale à organiser l'approvisionnement en eau potable en créant le 18
 7

novembre 1929 la société de distribution de Léopoldville dont le siège se situait à

BRUXELLES.

Le 28 mars 1933 par arrêté royale, le ministre Belge des colonies institua une régie de
distribution d'eau de la colonie dont l'exploitation, le développement et la modernisation de la
distribution d'eau était confiée aux autorités urbaines des villes de BOMA, MATADI,
KINSHASA (LEOPOLDVILLE), MBANDAKA (COQUILATEVILLE) et KISANGANI
(STANLEYVILLE).

Le décret royal de 30 décembre 1939 crée une véritable société publique coloniale de
distribution d'eau et d'électricité pour l'ensemble des territoires du Congo-Belge et du Rwanda-
Burundi Abrogeant ainsi l'arrêté royal du 28 mars 1933.

La nouvelle société était dénommée Régie de Distribution d'eau et d'électricité du Congo-Belge

et Rwanda-Burundi. Cette entreprise avait double particularité :

 Elle avait la personnalité juridique. Ce qui lui conférait une autonomie de gestion ;
 Son champ d'action et son objet était élargis.

C. Période post coloniale

Après l'indépendance, la REGIDESO a connu de profondes transformations.

L'ordonnance loi n° 66-460 du 25 août 1966 annula le décret du 30 décembre 1939, et créa une
nouvelle institution publique dénommée « REGIDESO » dont le siège social est fixé à
Kinshasa.

Il sied de signaler que le changement intervenu par cette ordonnance ne concerne que le champ
d'action et le siège social, mais non l'objet social car la nouvelle entreprise devrait exploiter
comme la précédente, pour le compte seulement de la République Démocratique du Congo, le
service de distribution d'eau ainsi que les installations annexes d'adduction d'eau, de pompage,
de stérilisation d'eau, l'exploitation des centrales électriques et de réseaux de distribution de
l'électricité.

Deux ans après la création de la REGIDESO, l'Etat décide de privatiser la gestion de

REGIDESO par l'ordonnance - loi n° 68 - 116 du 29 mars 1968. Il confia la gestion à la société
 8

anonyme de droit Belge « La COMMIERE » pour une durée de cinq ans, mais le contrat n'a
duré que deux ans pour cause d'un procès contre la Co minière à LORHON.

En 1978, le Gouvernement notifie la décision de transférer à la société nationale d'électricité

« SNEL » l'ensemble des exploitations de production et de distribution de l'énergie électrique
avec prise d'effet le 01 janvier 1979. C'est dans l'année 1979 que les douze centrales
d'exploitations de l'électricité sont progressivement cédées à la société nationale d'électricité.
Dès lors, la REGIDESO consacre ses efforts à l'exploitation et au développement du secteur de
l'eau potable.

Statut juridique

Organisme spécial au départ (c’est-à-dire de 1933 à 1939), la REGIDESO est devenue

successivement « institution publique autonome » (de 1939 à 1973) et « entreprise publique à
caractère technique, industriel et commercial » depuis 1978. A l’issue du décret 09/11 du 24
avril 2009 portant mesures transitoires à la transformation des entreprises publiques, la
REGIDESO a été transformé en société Commerciale, en sigle REGIDESO S.A.

I.3 Objet social de la REGIDESO S.A.

Suivant les dispositions de l’Ordonnance n° 78-197 du 05 mai 1978 portant Statuts de la

REGIDESO, telles que revues et complétées à ce jour, la Régie a pour objet :

 Exploitation des distributions d’eau et des installations annexes, de captage, d’adduction

et de traitement des eaux à distribuer ;
 Etude et exécution des travaux d’aménagement de distribution d’eau et des installations
annexes (établissement des distributions nouvelles, ou extension des distributions
existantes).
 Elle peut également effectuer toutes opérations se rattachant directement ou
indirectement à l’objet mentionné ci – dessus.

I.4 Organisation et Fonctionnement

I.4.1 Organisation
 9

Le Conseil d’Administration est aux termes de la loi n° 78 – 002 du 06 janvier 1978,

l’organe de conception et d’orientation de la politique de l’Entreprise.

Conformément à l’arrêté portant mesures transitoires de transformation des entreprises

publiques, les entreprises publiques transformées en sociétés commerciales sont gérées par
leurs Conseils d'administration en leurs compositions et forme actuelles. C’est-à-dire :

 Le Président du Conseil
 Le Directeur Général
 Le Directeur Général Adjoint

Le Comité de Gestion assure la gestion courante de l’Entreprise. Il est composé de :

 Le Directeur Général ;
 Le Directeur Général Adjoint ;
 Et, d’un Représentant du Personnel.

I.4.2 Fonctionnement

La structure de la REGIDESO comprend :

 1 Direction Générale (à Kinshasa) ;

 11 Directions Provinciales ;
 Des Centres d’exploitation ;
 Des Secteurs/Agences et Bureaux auxiliaires.

La Direction provinciale de Kinshasa compte :

 3 Directions urbaines de Kinshasa (Centre, Est et Ouest) ;

 1 Direction de production de Kinshasa ;
 1 Direction de Distribution de Kinshasa.

La Direction Générale comporte les directions suivantes, à savoir :

 Le Secrétariat Général ;
 La Direction centrale des ressources humaines ;
 La Direction centrale des comptabilités et finances ;
 10

 La Direction des Systèmes d’Information ;

 La Direction centrale de développement et réhabilitation ;
 La Direction centrale d’exploitation ;
 La Direction centrale clientèle et marketing ;
 La Direction centrale de l’Audit, Inspection et Qualité ;
 La Direction centrale de contrôle de gestion et Budget.

TUTELLE
Aux termes de la loi en vigueur, celle n° 78 – 002 du 06 janvier 1978 portant dispositions
générales applicables aux Entreprises Publiques, la REGIDESO est placée sous une double
tutelle : technique du Ministère de l’Energie, d’une part et financière du Ministère du
Portefeuille, de l’autre.
 11

I.4.3 Organigramme général de la REGIDESO

Conseil d’administration

Comité de gestion

Administrateur Délégué Source : Secrétariat de la REGIDESO

Général

Administrateur Délégué Général

Adjoint
Secrétariat Général Dir. Cont. Ges.
Organi.
Dir. Audit. Général Dir. Insp. et
surveillance
Collèges des Cons. Dir. Informatique

ADT (Administrateur Directeur ADF (Administrateur Directeur

Technique) Financier)
Dir. D’explo. Dir. Trso.

Dir. Compt
Dir. Dev. Et R.
Dir. Budg
Dir. Appro.
Dir. Ressou
Dir. Comm.
Dir. Form
Dir. Losti.
Dir. Medic.
DTE DCK DDK DP

Centre d’objet
12

CONCLUSION DU CHAPITRE
Ce chapitre nous a permis de connaitre l’organisation sur laquelle nous portons notre
étude sa situation géographique, sa création, son organisation.
 13

CHAPITRE II : ANALYSE DE L’EXISTANT

Introduction
L’analyse de l’existant a pour but de recenser les données du système qui permettent
de préparer et identifier la validité d’une activité à caractère productif et de pouvoir proposer
une solution.

2.1. DEFINITION ET BUT

Selon ROBERT Reix dans son œuvre l’analyse de l’information donne les raisons de
l’importance de l’étude d’opportunité en deux volets : Connaitre les fonctions actuelles système
d’information, sa structure précise, ses conditions de fonctionnements, son adoption aux
besoins. Déceler les principales anomalies (à corriger) à l’évolution du système5 .

But : Recueillir les données qui vont servir à l’élaboration des plusieurs solutions. Elle consiste
notamment à :
 Etudier la structure et le poste concerné,
 Etudier les documents et les fichiers qui sont utilisé,
 Etudier le moyen de traitement de l’information utilisée,
 Etudier la circulation des informations et évaluer le coût de fonctionnement.

2.2. Analyse de la Structure et des activités du système existant

Chef de secteur

Secrétaire

Réception

Source : Secrétariat

5
Robert Reix, Analyse Informatique de gestion, éd. Bandas paitiers Paris 1982
 14

2.3. Analyse des postes de travail

Dans le cadre de nos recherches au sein de la REGIDESO plus précisément au sein du
Service Commerciale par rapport à notre sujet d’étude nous avons recensé trois postes de travail
à savoir :
Tableau n°1 : Description de poste de travail
DOCUMENT
N° POSTE AFFECTIF
RECU EMIS GARDE
1 Chef de -Fiche de -
secteur relance
1 -
-fiche
d’enregistrement
2 secrétaire -Fiche de -Fiche de -Fiche de relance
relance relance -Fiche d’enregistrement
1
-fiche -fiche
d’enregistrement d’enregistrement
3 Réception - - Liste des abonnés
2

2.4 Analyse des flux d’information

2.4.1 Recensement des documents
Dans le cadre toujours de notre sujet sous étude, nous avons recensé deux documents à
savoir :
1. Fiche d’enregistrement ;
2. fiche de relance.

b. Description des Documents

1. La fiche d’enregistrement
a. Rôle : La fiche d’enregistrement est un document qui permet d’enregistrer les
réclamations.
 15

b. Modèle du document

FICHE D’ENREGISTREMENT TECHNIQUE DE RECLAMMATION

Numéro Noms Adresse Date Obs.

C. Description
Tableau n° 2 : Description de la fiche technique
N° Rubriques Code Nature Taille
1 Numéro E_Num AN 10
2 Noms E_Nom AN 50
3 Adresse E_Adresse AN 50
4 Date E_Date Date 10
5 Observations E_Obs AN 255
 16

2. La Fiche de relance
a. Rôle : est un document qui permet d’enregistrer une réclamation reçue mais non traitée

b. Modèle du document

FICHE DE RELANCE
date numéro raccordement Nombre nature Noms de observations
de l’abonné
relance

c. Description
Tableau n°3 : Description de la fiche de relance
N° Rubriques Code Nature Taille
1 Date E_date AN 10
2 Numéro E_Num AN 15
3 Raccordement E_raccord AN 50
4 Nombre de relance E_relance Date 10
5 Nature E_Nature AN 10
6 Nom de l’abonné E_abonné AN 20
7 Observations E_observ AN 255
 17

2.4.3 Dictionnaire des données

Tableau n° 4 : Dictionnaire des données
Rubrique Code Type Taille
Rubrique
Adresse E_adress AN 15
Dates E_date Date 10
Numero E_Num_ab AN 25
Nature E_Nature AN 255
Noms E_Nom_ab AN 25
Numero de la relance E_Numr AN 25
Observations E_observ AN 255

2.5 Etude des moyens de traitement de l’information

2.5.1 Ressources Matérielles

C’est l’ensemble des moyens matériels ou outils nécessaires utilisés pour permettre le
traitement d’information dans la gestion d’une application. Ainsi, nous décrivons les ressources
humaines dans le tableau ci-dessous :
Tableau n°5 : Description de la ressource matérielle
N° Désignation Marque Nombre Etat Année d’acq.
01 Ordinateurs Dell 2 Bon 2014
02 Imprimante HP LaserJet 1 Bon 2014
03 Etagères FNMA 2 Bon 2007
04 Cahier registre - 1 - 2018

2.5.2 Ressources Humaines

C’est l’ensemble d’agents qui sont en charge de la gestion de réclamations.
Tableau n°6 : Description de la ressources Humaines
N° Poste Niveau d’étude Ancienneté
01 Chef de secteur L2 12 ans
02 Secrétaire L2 7 ans
03 Réception G3 5 ans

2.5.3 Ressources Financières

Etant une entreprise publique, les moyens financiers proviennent des factures payées
et du financement du gouvernement.
 18

2.6. Analyse de la circulation de l’information

L’étude des postes de travail et l’analyse des documents dans le traitement des données
conduisent à ce niveau d’analyse. Par circulation des informations, il est question d’un schéma
qui décrit le flux des informations dans le service de perception.
Le schéma dégagé à partir des interviews et des observations donne une vue de la
circulation des documents dans l’espace ou le parcours suivi par ces différents documents
utilisés pour la gestion de réclamations.
Narration :
Pour la réclamation des abonnés, l’abonné se présente pour une réclamation avec sa
fiche auprès du réceptionniste, ce dernier lui reçoit et envoie la requête au secrétaire. Le
secrétariat vérifie et envoie au chef de secteur. Après approbation du chef, la fiche est renvoyée
au secrétariat pour l’enregistrement de la réclamation.
 19

2.6.1. Présentation du schéma de circulation des informations

Abonne 100 Réception 200 Secrétaire 300 Chef de secteur
400
Arrivée de
l’abonné pour
réclamations
101
Réception de la Réception de la Réception et
FE
Fiche pour envoie Fiche et vérification de la
au service vérification pour Fiche pour
concerné envoie au chef validation
201 pour validation
301
401
FE
FR
FR

Réception de la FR
validée pour
enregistrement
302

FR
 20

2.6.2 Légende et abréviations

Légende

: Provenance

: Destination

: Classement

: Document en un exemplaire

: Plusieurs Documents

: Poste de travail/ Tâche

: Code/opération

 Abréviations

- FR : Fiche de relance
- FE : Fiche d’enregistrement
 21

2.6.3. Description du schéma de circulation

Code
Code Description
Opération
Présentation de l’abonné
100 101

201 Réception de la Fiche pour transmission au secrétaire

200

Réception et vérification de la Fiche pour envoie au

301 Chef de service
300 Réception de la Fiche validée pour le classement
302

Réception de la Fiche pour validation

400 401

Conclusion
Dans ce chapitre, nous avons étudié le champ d’investigation de sa création à son
système existant.
 22

Chapitre 3 : CRITIQUE, DIAGNOSTIC DE L’EXISTANT ET RECHERCHES DES

SOLUTIONS
Introduction
Notre critique se fera d’une manière objective et rationnelle afin que les résultats nous
ouvrent les voies et moyens de créer un nouveau système d’information plus fiable qui nous
aidera à résoudre des problèmes sus évoquée.

3.1 Critique et Diagnostic de l’existant

a. Critique d’organisation
Pendant notre phase de recherche scientifique, nous avons remarqué que la gestion de
stagiaire est mal organisée, au niveau que les agents sont débordés par le cafouillage des
documents qui se perdent, comme le travail est assuré par une seule personne. Conséquence
lenteur administrative et fraude dans le traitement de documents selon l’ordre d’arrivée.

b. Critique des documents

Nous avons constaté quelques problèmes du point de vue documents administratifs car,
le service assurant l’encadrement de stagiaires n’est pas informatisé et n’y a pas même de
bonnes armoires pouvant bien conserver les documents, cela cause souvent la perte des dossiers
et des informations.

 Points positifs :

- Utilisation de tous les documents nécessaires ;

- Une bonne structuration des documents ;
- La présence de tous les éléments utiles dans des documents.

 Points négatifs :

- Perte de certains documents ;

- - Recherche difficile des documents ;
- - Peu des documents dans cette gestion.
 23

c. Critique de la circulation des informations

Les postes qui interviennent dans le flux des informations sont bien organisés, mais les
informations arrivent parfois à d’autres postes avec une lenteur.

1. Les points forts du système

Les points forts du système existant dans la gestion de stagiaires : ils sont bien organisés
du point de vue organisationnel. Dans la gestion de réclamations, nous retrouvons les éléments
ci – après :

- Les disponibilités de documents utilisés ;

- La réalisation de tâches est très simple selon la compétence des agents ;
- La motivation des agents.

2. Les points faibles du système existant

Lors de notre passage, nous avons trouvé comme difficultés :

- Le gaspillage du temps pour la réalisation d’un petit travail ;
- Mauvaise conservation des archives ;
- Manque d’un logiciel informatique approprié.

d. Critique de moyens de traitement des informations

Par manque d’une bonne utilisation de matériel informatique les documents de stagiaires
sont élaborés avec une lenteur. Nous pouvons signaler en passant que ledit service n’est pas
doté des bons informaticiens qui peuvent manipuler l’outil informatique.
Pour notre travail nous avons deux propositions, à savoir : le traitement manuel et
l’informatisation.
3.2 Recherche des solutions
Nous proposons deux types de solution qui consiste à revoir le cadre organique dudit
service. Il s’agit de :
 24

L’externalisation de la gestion des réclamations Abonnés de la Regideso Agence de la

Gombe qui sera traitée par les prestataires extérieurs offrant des services d’externalisation qui
sont des spécialistes dans leur domaine. Ils sont ainsi en mesure d’apporter une excellente
valeur ajoutée à l’entreprise.

Il s’agit de créer ou de dédier la gestion de réclamation des abonnés au sein même de

son entreprise. Ceci a comme avantage l’optimisation de traitement dû à l’augmentation du
personnel administratif et a comme désavantage l’augmentation de l’enveloppe salariale car
lorsqu’on va créer des nouveaux postes il faudrait prévoir aussi l’engagement des nouvelles
unités d’une part et l’autre part le fait même de modifier l’ancien cadre organique va demander
la création d’une commission spéciale pour les analyses préalable et cette commission aura un
statut spécial de paiement et de motivation qui constitue des charges de plus pour l’entreprise.

3.2.2 SCENARIO D’INFORMATISATION

Cette dernière solution consiste à faire appel aux matériels et aux consommables
informatiques pour venir booster l’ancien système d’information qui était manuel. Nous
pouvons énumérer les avantages de l’informatisation de la manière suivante :

- Optimisation de traitement des informatisations ;

- Une fois informatisé le service sera doté des matériels et consommables informatiques,
chose dont il ne possédait pas auparavant ;
- La confidentialité car tous les documents traiter au niveau du service par l’ordinateur ne
sont pas divulgué comme c’était le cas dans le traitement manuel ;
- La rapidité ;

Cette solution a comme désavantage le coût élevé de matérielles et consommables

informatiques d’une part et d’autre part les matériels énergétique tel qu’onduleurs, panneau
solaire pour éviter les bruits de moteur de groupe électrogène.
3.3.1 Les besoins Fonctionnels et techniques du projet

Pendant plusieurs décennies, le monde informatique a toujours rêvé d'un processus qui
puisse garantir le développement efficace de logiciels de qualité, valable quel que soit la
grandeur et la complexité du projet, et présentant de bonnes pratiques adaptées à la méthode en
 25

question, surtout que, de nos jours, les logiciels demandés sont de plus en plus imposants et
exigeants qu'auparavant.

Le processus unifié semble être la solution idéale pour remédier à l'éternel problème des
développeurs. En effet, il regroupe les activités à mener pour transformer les besoins d'un
utilisateur en un système logiciel quel que soit la classe, la taille et le domaine d'application de
ce système.

Pour le développement de notre application, nous nous étions basés sur le processus unifié.
Mais, une seule itération de ce processus nous semble suffisante. En effet, dans une première
phase nous avons effectué la spécification des besoins, ensuite dans une seconde phase nous
avons élaboré l'analyse des besoins, puis nous avons effectué la conception dans la troisième
phase et enfin la dernière phase a été consacrée à la réalisation suivie par les tests de
l'application.

Dans ce chapitre, nous présentons la spécification et l'analyse des besoins ainsi que la
conception de l'application. La réalisation est présentée dans le chapitre suivant.

3.3.1.1 Les Besoins fonctionnels

Le système dont la Regideso veut se doter, doit être opérationnel, évolutif, convivial et
offrant les informations nécessaires à temps réel.

Pour ceci, le système à réaliser doit satisfaire les exigences de la totalité des utilisateurs.
Nous présentons dans ce qui suit tous les besoins fonctionnels classés par acteur ainsi que les
besoins non fonctionnels communs à tous ces acteurs.

Besoins fonctionnels :

Un acteur est une personne, un matériel ou un logiciel qui interagit avec le système dans
le but de réaliser une plus-value.

Les acteurs en interaction avec notre système sont :

La Secrétaire
Le chef de secteur : Administrateur
L'informaticien
 26

· La Secrétaire : doit pouvoir assurer les activités suivantes :

· Réception des réclamations

· Annulation des réclamations

· Le chef de secteur « Administrateur » doit pouvoir assurer les fonctions suivantes :

· Gestion les réclamations

· L'informaticien a pour tâches principales :

· Gestion des informations relatives aux réclamations

· Maintenances (ajout des utilisateurs...)

3.3.1.2 Les besoins techniques

Entre les deux solutions, nous optons pour la solution informatique dans ce sens que
pendant notre phase de recherche scientifique, il se fait dégager un besoin d’informatisation au
profit du service de gestion de stagiaires de la REGIDESO d’une part et d’autre part les
connaissances acquises au sein de l’Institut Supérieur de Commerce de Kinshasa ISC –
GOMBE au sein de la section Gestion Informatique nous donne la possibilité d’informatiser
l’ancien système d’information, raison pour laquelle nous avons opté pour l’informatisation.

Conclusion du chapitre
Ce chapitre nous a permis d’analyser et de critiquer le système en place tout en
démontrant les avantages de l’informatique et ses désavantages, afin d’opter pour la solution
informatique qui est la meilleure pour cette gestion.

Conclusion de la partie
Cette partie nous a permis de connaitre l’organisation qui fait l’objet de notre étude,
ainsi que le diagnostic du système d’information en place, en vue de dégager deux points
importants, à savoir, les points faibles et les points forts. Ensuite nous avions proposé deux
solutions : la solution de réorganisation et d’informatisation. La première solution a consisté à
organiser de nouveau le système existant, et la deuxième solution a été consacrée à la mise en
place d’un système d’information informatisé. En fin, dans le souci d’accroitre la production
des résultats, nous avons proposé au comité de gestion la solution informatique.
 27

DEUXIEME PARTIE : CONCEPTION D’UN

NOUVEAU SYSTEME D’INFORMATION

La conception du système d’information nécessite une analyse des données qui

constituent le point de passage de toute application mettant en œuvre un système de gestion de
base de données relationnelles.

La méthode francophone Merise d’analyse et de conception spécifique pour

l’informatisation des systèmes d’informations est adoptée dans le cadre de ce travail dans le but
de mettre en œuvre notre nouveau système d’information.

Cette partie comporte trois chapitres :

 Chapitre I : Modélisation du système d’information organisé (S.I.O)
 Chapitre II : Modélisation du système d’information informatisé (S.I.I)
 Chapitre III : Développement du nouveau système d’information informatisé.
 28

CHAPITRE I : MODELISATION DU SYSTEME D’INFORMATION ORGANISE

(SIO)
Introduction
Ce chapitre traite les questions fondamentales de la conception d’un système
d’information organisé.

Section I : ETAPE CONCEPTUELLE

I.1 Définition et but
L’étape conceptuelle peut se définir comme étant le niveau consistant à structurer le
système indépendamment de tous les besoins et de toutes les technologies de l’entreprise.
(HUBERT, 1998)

I.2 MODELISATION CONCEPTUELLE DE COMMUNICATION (MCC)

I.2.1 Définition et but
La modélisation conceptuelle de communication permet de modéliser les échanges
d’informations entre les différents acteurs.
Définition de l’organisation, 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 externes sont appelés acteurs
externes.
I.2.2 Construction du modèle conceptuel de communication
1.1.2.1 Définition de quelques concepts du Modèle conceptuel de communication
Domaine d’étude : c’est le domaine sur lequel porte l’analyse à réaliser.
Domaine connexe : un domaine connexe appartient à l’entreprise, il interagit avec le
domaine d’étude par échange d’information mais n’en fait pas partie.
Acteur : un acteur est une personne ou un groupe de personnes
 Qui s’échangent des informations (documents et messages) ;
 Qui accomplissent des actions sur ces informations.

Un acteur est modélisé de cette façon :

Nom Acteur
Fig. Représentation de l’acteur externe

Nom Acteur Fig. Représentation de l’acteur interne

 29

Nous avons un acteur externe et interne :

a) Acteur externe représente tout élément à l’organisation et échangeant des flux avec le
domaine d’étude ; il peut être :
o Une personne physique (client, fournisseur) ;
o Une personne morale (banque) ;
o Un autre domaine d’activité de l’entreprise.

b) Acteur interne : personne physique ou morale appartenant au système (organisation),

capable d’échanger des informations avec des partenaires.

Flux : lot d’informations (ou messages), émis par un acteur et reçu par un autre
domaine.

Un flux sera modélisé de cette façon :

Nom du flux
Fig. Représentation du flux
Gestion de réclamations des abonnés

1 Réceptionniste
s 2

Abonnés
3
6
Secrétaire

5 4

Chef de secteur

Commentaires :
Flux 1 : l’abonné se présente à la réception pour besoin de réclamations ;
Flux 2 : Le réceptionniste lui reçoit pour enregistrement et conduite au secrétaire ;
Flux 3 : l’abonné dépose sa réclamation au secrétaire ;
Flux 4 : Le secrétariat reçoit et analyse les dossiers pour envoie au chef de secteur ;
Flux 5 : Le chef de secteur reçoit pour validation et signatures ;
Flux 6 : Le secrétaire contacte l’abonné pour l’entretien.
 30

I.3 Modélisation Conceptuelle de Traitements

L’élaboration de la modélisation conceptuelle de traitement se caractérise par l’abandon
des contraintes organisationnelles (acteurs, ressources utilisées) mises en relief dans le schéma
de circulation des informations. On ne reprend ici que des contraintes liées aux finalités de
l’activité. (KitokoMuanaDuinga, 2019)

I.3.1 Définition et but

Le modèle conceptuel de traitement est un graphique qui définit les opérations à effectuer
dans une application selon l’ordre d’exécution d’une façon logique sans tenir compte de l’outil
informatique.

Elle a pour but de représenter formellement les activités exercées par le domaine.

1.3.2 Construction du Modèle Conceptuel des traitements

1.3.2.1 Définition de quelques concepts du Modèle Conceptuel des traitements

Formalisme du modèle conceptuel de traitement

Le modèle conceptuel de traitement est formalisé par « E-O-R : Evénement-Opération-
Résultats ».

Evénement : c’est le fait (stimulus) qui provoque une action (opération). L’événement est
symbolisé en merise par un cercle ovale.

Nom de l’événement
Figure 7 : Représentation de l’événement

Opération : elle est une tâche ou ensemble des tâches accomplies par le processeur
d’information en relation à l’événement. Une même opération peut regrouper, les tâches de
nature différentes. Autrement dit une opération est une action qui produit un résultat.
Elle est représentée par un rectangle entre coupé :

Nom opération

Règle Règle
d’émission d’émission

Figure 8 : Représentation de l’opération

Résultat : c’est la réponse produite par une opération ou encore la transformation d’événement
par une opération. Il est appelé aussi « Evénement – résultat » parce qu’il peut par la suite
produire une autre opération. Il est symbolisé par un cercle ovale.

Nom du Résultat
Figure 9 : Représentation du Résultat
 31

Règle d’émission : c’est une condition booléenne permettant de traduire les règles de gestion.

Synchronisation : c’est la combinaison (connections) de deux ou plusieurs événements qui

déclenchent à la fois une opération. Nous dirons que la synchronisation correspond à la
condition d’exécution de l’opération.

Cette condition est représentée sous forme de condition booléenne d’événement (and, or).
Formalisme :

Figure 10 : Représentation de la synchronisation

I.3.2.2 : Identification et description du processus

Tableau N° 6 : tableau descriptif du MCT

Opération Action Evénement Sync Règle Résultat
hron d’Emis
isati sion
on
Déposition -réception -Arrivée de l’abonné ET OK Réclamation
réclamation réclamation -Présence reçue
-vérification réceptionniste KO Réclamation
réclamation non reçue
Enregistreme -Enregistrement - Réclamation reçue - Toujou Réclamation
nt d’identité rs enregistrée
Traitement -Enregistrement et -Présence ET OK Réclamation
vérification responsable traitée
-réclamation KO Réclamation
enregistrée non traitée
Edition -Edition rapport de -réclamation traitée ET OK -Liste de
réclamation -fin du dossier réclamation
traitée
- Liste de
réclamation
non traitée
KO Edition
rapport de
réclamation
en attente
 32

I.3.2.3 Présentation du Modèle Conceptuel des traitements

Arrivée de Présence
l’abonné réceptionniste
ET
Déposition réclamation
Réception réclamation
Vérification réclamation
OUI NON

Réclamation reçue Réclamation non reçue

Enregistrement
Ecriture d’identité
Toujours

Réclamation enregistrée
Présence
responsable

ET
Traitement
Enregistrement
vérification
OUI NON

Réclamation traitée Réclamation non traitée

ET
Fin du dossier
Edition
Edition rapport de réclamation

OUI NON

Liste de réclamation Edition rapport de

traitée réclamation en attente

Liste de réclamation non

traitée

Figure 11 : MCT
 33

I.4 Modélisation Conceptuelle de données (MCD)

I.4.1Définition et but

Cette étape qui n’est pas informatique, mais de définition du système de gestion, se base
sur une analyse du monde réel de laquelle une conceptualisation viendra résoudre le problème
de la représentation de la base des données en répondant à la question QUOI ? Sans se
préoccuper des ressources matérielles ou des logiciels à utiliser. (KitokoMuanaDuinga, 2019)

Son but est que toute entité concrète ou abstraite ayant une existence propre, possédant
physiquement ou abstraitement des propriétés qui la caractérise et qui l’identifie de manière
univoque, et présentant un certain intérêt dans le domaine de gestion de l’entreprise.

I.4.2 Construction du Modèle Conceptuel de données

Comme toute méthode de conception, la méthode merise a aussi prévu un formalisme

approprié de présentation du modèle conceptuel de données nommé « Entité-Association ».

Entité : une entité est un concept qui regroupe des données qui sont de même nature, présentant
un intérêt pour le domaine d’étude et dotée d’une existence propre.

Elle est représentée par un rectangle :

Nom de l’entité

Identifiant
Liste de propriétés

Figure 12 : Représentation de l’objet

Association : une association est un lien verbal unissant deux ou plusieurs entités ; son
existence est conditionnée par la présence des entités qui la composent.
Elle est représentée par un cercle ovale :

Relation
Propriété

Figure 13 : Représentation de l’objet

Propriété : une propriété est une donnée élémentaire que l’on perçoit sur une entité ou sur une
relation entre entités.
Cardinalité : une cardinalité représente le nombre maximale et minimale qu’une entité
participe à une relation.

Identifiant : un identifiant est une propriété permettant de désigner une et une seule entité.
 34

I.4.2.1. Règles de gestion

Les règles de gestion sont les contraintes administratives de gestion dont le but est
d’assurer la sécurité. Elles sont donc des consignes à appliquer dans une entreprise ou une
organisation dans le domaine de gestion bien déterminé. Nous avons recensé les règles de
gestion suivantes lors de notre analyse en ce qui concerne la gestion de réclamations :

REGLE 1 : Un Agent travaille dans un et un seul service ;

Dans un service travaillent un et plusieurs Agents.

REGLE 2 : un agent traite une ou plusieurs réclamations

Une ou plusieurs réclamations sont traités par un agent.

REGLE 3 : un abonné dépose une ou plusieurs réclamations ;

Une ou plusieurs réclamations sont déposées par un abonné
 35

I.4.2.2 Dictionnaire des données

Le dictionnaire de données est un document qui permet de recenser, de classer et de tirer
toutes les informations (données) collectées lors des entretiens.

Tableau N° 7 : description du dictionnaire des données

Rubrique Code Type Taille
Rubrique
Numero_abonné Numero_ab AN 15
Nom_abonné Nom_ab AN 25
Postnom abonné Postnm_ab AN 25
Prenom abonné Pren_ab AN 25
Adresse abonné Adresse_ab AN 25
Type abonné Type_ab AN 25

Matricule agent Matri_ag AN 10

Nom agent Nom_ag AN 25
Postnom agent Postnm_ag AN 25
Sexe agent Sexe_ag AN 1
Grade agent Grade_ag AN 10
Fonction agent Fonct_ag N 10
Telephone agent Tel_ag AN 15
Adresse agent Adres_ag AN 25

Numéro réclamation Num_recla AN 10

Objet réclamation objet_recla AN 255
Date réclamation date_recla Date 10
Décision prise decision AN 255

Code service code_serv AN 10

Libellé service libel_serv AN 50
 36

I.4.2.3 Recensement et description des objets

Recensement des objets
Pour la gestion de réclamations, nous avons recensé les objets ci-après :
 Agents ;
 Service ;
 Abonné ;
 Réclamation.

Description des objets

Tableau n°8 : Description des objets
N° Objet Propriété Code Type Taille Identifiant
1 Abonné Numero_abonné Numero_ab AN 5 Id
Nom_abonné Nom_ab AN 25
Postnom abonné Postnm_ab AN 25
Prenom abonné Pren_ab AN 25
Adresse abonné Adresse_ab AN 25
Type abonné Type_ab AN 25

2 Agent Matricule agent Matri_ag AN 10 Id

Nom agent Nom_ag AN 25
Postnom agent Postnm_ag AN 25
Sexe agent Sexe_ag AN 1
Grade agent Grade_ag AN 10
Fonction agent Fonct_ag AN 10
Telephone agent Tel_ag N 15
Adresse agent Adres_ag AN 25
3 Service Code service Code_serv AN 10 Id
Libellé service Libel_serv AN 50

4 Réclamation Numéro réclamation Num_recla AN 10 Id

Objet réclamation objet_recla AN 255
Date réclamation date_recla Date
Décision décision AN
 37

I.4.2.4 Recensement et description des relations

Recensement des relations
Pour la gestion de réclamations, les relations sont les suivantes :
o Travailler ;
o Traiter ;
o Déposer.

Description des relations

Tableau n°9 : Description des relations
N° Relation Dimension Objets associés
1 Travailler Binaire Agents-Document
2 Traiter Binaire Agents-Réclamations
3 Déposer Binaire Abonné-Réclamation

I.4.2.5 Définition des contraintes

Les contraintes
Une contrainte est une obligation, une règle à laquelle on doit se soumettre. Nous en
avons plusieurs mais nous citons quelques-unes : (Diomisi, 1998)

Contrainte de cardinalité

C’est une contrainte qui indique chaque couple d’objet (x, y) qui participe à la
relation. Ces contraintes sont notées (0,1) ;(0,n) ;(1,1) ;(1,n) ;(n,n). La valeur gauche indique le
minimal, la droite indique le maximal. Cette contrainte de cardinalité indique le n fois
d’occurrences de la relation.
 (0,1) : une occurrence de l’objet peut exister sans pour autant participer à la relation ou
ne participe jamais plus d’une fois. C’est-à-dire une occurrence d’objet participe zéro
ou une seule fois.

 (1,1) : une occurrence de l’objet participe au moins et au plus une fois dans une relation.
C’est-à-dire elle participe une et une seule fois dans une relation.

 (1, n) : une occurrence de l’objet participe au moins une fois à la relation et peut sans
limitation. Autrement, elle participe une ou plusieurs fois.

 (0, n) : la cardinalité la plus ouverte, une occurrence de l’objet peut exister sans pour
autant participer dans une relation et peut participer sans limitation. Autrement, elle
participe zéro ou plusieurs fois dans une relation.
 38

Contrainte d’intégrité fonctionnelle (C.I.F)

La contrainte d’intégrité fonctionnelle définit une relation présente le fait que l’un
des objets de sa collection est identifié sans aucun doute par la connaissance d’une ou plusieurs
autres.
La C.I.F permet de mettre en évidence deux associations ou deux entités.
Autrement, elle permet d’optimiser la base de données (MCD brut). La contrainte d’intégrité
existe à partir du moment où une cardinalité de type (1,1) existe. C’est-à-dire lorsqu’une de
patte de la relation porte la cardinalité (1,1) ou (0,1) et que l’autre porte la cardinalité avec n.

Contrainte d’intégrité Multiple (CIM)

C’est une relation du type Père-Père. Ce cas intervient dans le modèle conceptuel de
données, nous retrouvons les couples : (0,n) ou (1,n) d’une part et (0,n) ou (1,n) d’autre part
c’est-à-dire nous pouvons avoir les combinaisons suivantes :
(0,n) et (0,n)
(0,n) et (1,n)
(1,n) et (1,n)

Tableau N° 10 description des contraintes

N° Relation Cardin Cardinali Objet père Objet fils Nature Observation
alité té fils
père

1 TRAVAILLER 1,n 1,1 Agent SERVICE CIF Père-Fils

2 TRAITER 1,n-1,n ---- Agent- Réclamation CIM Père-père

Réclamation

3 DEPOSER 1,n 1,1 Abonné Réclamation CIM Père-père

 39

I.4.2.6 Présentation du Modèle Conceptuel des données (MCD)

SERVICE Abonné
#Numero_ab
Nom_ab
#Code_serv Postnm_ab
Libel_serv Prenom_ab
Tel_ab
Adresse_ab
Type_ab

1,n
1,n

TRAVAILLER

Déposer

1,1
1,1
Agent
Réclamation
# Matri_ag
Nom_ag #num_recla
Postnm_ag objet_recla
Sexe_ag Traiter date_recla
Grade_ag Date_traitée
Fonct_ag 1,n Décision 1,n
Tel_ag
adr_ag

Figure 14 : MCD
 40

ETAPE ORGANISATIONNELLE
La modélisation organisationnelle des données va permettre de prendre en compte des
éléments relevant de l'utilisation des ressources de mémorisation :
- Le choix des informations à mémoriser informatiquement ;
- La quantification (ou volume) et la durée de vie des informations à mémoriser ;
- La répartition des données informatisées entre unités organisationnelles ;
- L'accès aux données informatisées pour chaque unité organisationnelle.
2.1 Modélisation Organisationnelle des traitements (MOT)
2.1.1 Définition et But
Il permet de décrire d'une façon globale, puis d'une façon détaillée le choix effectué en
matière d'organisation et de fonctionnement des services, les modes d'automatisation retenus,
les postes de travail et les tâches associées. Il précise les ressources humaines et matérielles
mobilisées avec leur organisation dans le temps et dans l'espace.
Le MOT va consister à compléter la description du MCT par une prise en considération
des contraintes d'organisation choisies par l'entreprise. Le concepteur doit répondre aux trois
questions :
- Comment : est posé pour déterminer la nature du traitement
- Quand : le moment ou le temps de déroulement de la tâche
- Où : le lieu, l'environnement ou le poste de travail.

2.1.2 Concepts de la modélisation organisationnelle des traitements

o Une tâche en temps réel (TR) : est en partie exécuté par l'homme et la machine ;
o Une tâche manuelle (TM) : est réalisée par l'homme seul ;
o Une tache automatique (TA) : ou tâche informatisée (TI) : est exécutée par la machine
;
o « U » ou mode unitaire signifie traitement un à un ;
o « L » ou lot : traitement en lot ;
o « I » : le délai de réponse est immédiat ;
o « D » : le délai de réponse est différé

2.1.3 Passage du MCT au MOT

Ce passage se fait en ajoutant au MCT trois colonnes suivantes :
" La première colonne est la réponse à a question « Quand » qui moment du déroulement
du traitement de données.
 41

" La deuxième colonne à la question « Qui » qui offrent 3 possibilité de réponse ; quant
à la lecture d'une tâche qui peut être soit manuel (TM), soit totalement informatisée (TA ou TI),
soit réel (TR) selon qu'il s'agit respectivement d'une tâche accomplie soit par l'homme, soit par
la machine, soit par l'homme et la machine.
La réponse à cette question doit aussi précise le délai de réponse qui peut être soit
immédiat (I), soit différé (D) et nous devons aussi préciser le mode de fonctionnement qui peut
être soit unitaire (U), soit en lot (L).
" La troisième colonne est relative à la question où ? Dont la réponse fait référence aux postes
de travail aux quels se déroulent le traitement.
 42

II.1.4 Présentation du Modèle Organisationnel des Traitements

Périodicité Enchainement des tâches Nature Poste de travail

Arrivée de Présence
l’abonné réceptionniste
ET
08H-14H Déposition réclamation TR-M Réceptionniste
Réception réclamation
Vérification réclamation
OUI NON

Réclamation reçue Réclamation non reçue

08H-14H Enregistrement
Ecriture d’identité TA-U-I Secrétaire
Toujours

Réclamation enregistrée
Présence
responsable

ET
Traitement
08H-14H Enregistrement TA-U-I Chef de secteur
vérification
OUI NON

Réclamation traitée Réclamation non traitée

ET Fin du dossier

Edition
08H-14H Edition rapport de réclamation TA-U-I Secrétaire

OUI NON

Liste de réclamation Edition rapport de

traitée réclamation en attente

Liste de réclamation non

traitée
 43

2.2 Modélisation organisationnelle de données (MOD)

2.2.1 Définition et but
C’est un niveau consistant des données, à partir de notre modèle conceptuel, les
informations qui ne seront pas mémorisées dans le support magnétique.
Il a pour but de répartir le choix de données automatisable (MOD) le choix de poste de
traitement est automatisé. Son but est aussi de partager les données par le site de gestion
automatisable. Ceci est possible grâce à l’évolution de la technologie.
2.2.2 Construction du Modèle Organisationnel de Données
2.2.2.1 Concepts du Modèle Organisationnel de Données
Il représente l’ensemble des données à mémoriser utilisable dans le domaine d’activité
étudié. La modélisation organisationnelle des données va également se préoccuper de la
répartition d’utilisation de ces données suivant les différentes unités organisationnelles.
La modélisation organisationnelle des données présente un intérêt certain pour être
orienter ultérieurement la répartition informatique des données, en particulier dans des
environnements client/serveur. MOD local a une entité organisationnelle.
L’unité organisationnelle recouvre généralement un ensemble de poste représentant par
exemple un service ou un site géographique. Les utilisateurs d’une unité locale. Le MOD local
et l’unité organisationnelle sont donc un moyen d’exprimer, du point de vue de l’utilisateur, les
données accessibles par un ensemble de poste. Le MOD local est un sous ensemble du MOD
global.
2.2.2.2 Règles de passage du MCD au MOD
La modélisation organisationnelle des données va permettre de prendre en compte des
éléments relevant de l’utilisation des ressources de mémorisation.
Le choix des informations à mémoriser informatiquement ;
La répartition des données informatisées entre unités organisationnelle ;
L’accès aux données informatisées pour chaque unité organisationnelle.

Ces différentes préoccupations nous conduirons à définir deux niveaux de modélisation

organisationnelle des données : le MOD global, directement dérivé du MCD, et le MOD local,
spécifique chacun à une unité organisationnelle.
Les MODs locaux seront dérivés du MOD global en prenant en compte des choix
d’organisation, en particulier de répartition.
Dans notre nôtre travail le MOD global correspond au MCD.
 44

II.2.2.3 Présentation du Modèle organisationnelle des données global

Service Abonné
#Numero_ab
Nom_ab
#Code_serv Postnm_ab
Libel_serv Prenom_ab
Tel_ab
Adresse_ab
Type_ab

1,n
1,n

Travailler

Déposer

1,1
1,1
Agent
Réclamation
# Matri_ag #num_recla
Nom_ag objet_recla
Postnm_ag date_recla
Sexe_ag
Traiter
Grade_ag
Date_traitée
Fonct_ag 1,n 1,n
Décision
Tel_ag
adr_ag

Figure 16 : MOD Global

 45

II.2.2.4 Présentation du Modèles Organisationnels des Données Locaux

La répartition organisationnelle des données ne peut se faire que lorsque le système
d’information doit être utilisé dans plusieurs sites. Pour notre étude, toutes les opérations du
système d’information se déroulent dans un même site. Ce qui revient à dire que notre MOD
global est considéré comme MOD local, auquel nous ajoutons les restrictions de sécurisation
des données suivantes :
 Accès en lecture ou en consultation : L ;
 Accès en modification ou en écrite : M ;
 Accès en création : C ;
 Accès en suppression : S.

Il revient exclusivement au gestionnaire d’utiliser chacun des accès au moment opportun

pour la sécurité du système d’information.
Profil utilisateur : Agent
Entité Accès Restriction
Abonné CLMS
Service CLMS
Réclamation CLMS

Profil utilisateur : Abonné

Entité Accès Restriction
Agent L
Réclamation L
Service L

CONCLUSION DU CHAPITRE
Dans ce premier chapitre nous avons présenté le système d’information organisé de
notre étude. La première section a fait l’objet de l’étape conceptuel, dans laquelle nous avons
structuré le système indépendamment de toutes les technologies, la seconde section, nous nous
sommes attelés sur l’étape organisationnelle, celle-ci a consisté à décrire les fonctions majeures
du domaine, sans référence aux ressources nécessaires pour assurer le fonctionnement.
 46

CHAPITRE II : MODELISATION DU SYSTEME D’INFORMATION INFORMATISE

(SII)
Introduction
Ce chapitre précisera comment élaborer et exprimer les différents modèles, comment
passé un niveau d’abstraction au suivant et transformer les différents modèles et enfin aborder
toute optimisation. La démarche de l’analyste à ce niveau est de parvenir à l’obtention d’une
base des données valide et d’un modèle logique des traitements cohérents et fiable. Elle exprime
la forme que doit prendre l’outil informatique pour être adapté à l’utilisateur, à son poste de
travail et cela se fait indépendamment du langage de programmation et de système de gestion
de base des données.
Section 1 : Etape logique
L’étape logique c’est une représentation des données issues de la modélisation
conceptuelle puis organisationnelle. Elle est exprimée dans un formalisme général et
compatible avec l’état de l’art technique. Elle a pour but de définir l’organisation des données
à partir du modèle conceptuel compte tenu des traitements à appliquer d’accès nécessaires et
les volumes occupés par la base des données.

1.1 Modélisation logique de traitements (MLT)

1.1.1 Définition et but
Le MLT présente une vue interne des moyens que l’informaticien va utiliser pour
construire le logiciel correspondant aux activités informatisées dans le MOT. On parle
d’enchainement des transactions, de découpage en module, de répartition des données et
traitement informatisé. (KonkfieIpepe, 2019)
1.1.2 Construction du Modèle Logique des Traitements
1.1.2.1 Définition des concepts de base du MLT
Une procédure : est un enchainement de plusieurs unités logiques de traitement.
Une unité logique de traitement (ULT) : c’est l’ensemble d’actions qui dérivent du
MOT et qui seront automatiquement traités. Ces actions ne seront pas homogènes parce
qu’ici les matériels ne seront pas pris en compte.
Interface : c’est un dispositif qui permet le dialogue homme-machine.
Opération : c’est l’ensemble d’action exécutable de manière interruptible.
 47

1.1.2.2 Passage du MOT au MLT

Identification des tâches du MOT qui deviennent des unités de traitement (ULT) :
Enchainement des différents ULT pour obtenir une procédure logique ;
Les ULT consultent et mettent à jour des fichiers informatiques ;
Le formalisme de la procédure commence par un « début » et se termine par une « fin
».

1.2.2.3. Identification des Unités Logiques de traitements

L'unité logique de traitement, ou unité logique (ULT), modélise un ensemble
de traitements informatiques perçus comme homogènes en termes de finalités. L'unité logique
de traitement se définit également par rapport à la cohérence des données du SII.

a) ULT 01 : Création de la Base de données

Présentation Maquette Ecran : MAQ 01 : Agent

ENCODAGE AGENT

Matricule Agent
Nom & Postnom
Grade
Fonction
Téléphone
Adresse

Enregistrer Modifier Supprimer Annuler

b) ULT 02 : Etablissement de document

Présentation Maquette Ecran : MAQ 02
ENCODAGE RECLAMATION
Num_recla
Objet_recla
Date_recla
decision

Enregistrer Modifier Rechercher Quitter

 48

1.1.2.3 Présentation du MLT

Début programme

Page d’accueil

Bienvenue

Boite de connexion
Login :
Mot de passe
Se connecter quitter
BDD

S
i

Menu principal

Mise jour Edition Quitter Fin programme

Retour
Mise à jour

Agent Service Abonnés Réclamation Traiter Fonction

Impression Retour
 Liste des agents
 Liste des abonnés
 Liste des réclamations
 49

1.2 MODELISATION LOGIQUE DE DONNEES (MLD)

1.2.1 Définition et but
La modélisation logique des données est une représentative des données, issues de la
modélisation conceptuelle puis organisationnelle de données. Elle est exprimée dans un
formalisme général et compatible avec l’état de l’art technique et tient compte des aspects coût/
performance liés aux traitements. (DOMINIQUE, 1996)
1.2.2 Construction du Modèle Logique des données
1.2.2.1 Définition des concepts de base du MLD
Il est vrai que le modèle logique des données se fonde sur plusieurs concepts dont un sont
présentés notamment :
 Table : est une structure fondamentale ou représentation de la donnée à l’exploiter dans
une base de données, classer en ligne et en colonne.
 Attribut : est une unité (source) élémentaire d’information d’une table.
 Clé primaire : est un attribut spécial qui permet d’identifier d’une manière univoque
chaque enregistrement de la table. (KonkfieIpepe, 2019)
 Clé étrangère : est un sous ensemble de colonne qui « constitue la clé primaire » d’une
autre table. (KonkfieIpepe, 2019)
 Schéma d’une base de données : c’est l’ensemble des schémas de relations qui la
composent ;
 Intégrité référentielle : est une situation dans laquelle pour chaque information d’une
table A qui fait référence à une information d’une table B.

1.2.2.2 Passage du MOD au MLD

Le passage du MOD au MLD exige le respect d’un certains nombres des critères.
Ainsi, le passage s’effectue selon les règles suivantes :
 Les objets deviennent des tables dans le MLD ;
 Les propriétés de ces objets deviennent des attributs des tables ;
 Les identifiants deviennent les clés primaires des tables.

Ainsi, pour les traitements des relations plusieurs cas sont à signaler :
 50

1er Cas : Relation du type père-fils : contrainte d’intégrité fonctionnelle (CIF)

Ce cas intervient lorsque dans le modèle conceptuel de données, nous retrouvons
les couples : (0,1) ou (1,1) d’une part et (0, n) ou (1, n) d’autre part. C’est-à-dire nous pouvons
avoir les combinaisons suivantes : (0,1) – (0, n); (0,1) – (1, n); (1,1) – (0, n) et (1,1) – (1, n).
Dans ce cas, la relation disparait mais sa sémantique demeure, car l’objet qui a la
cardinalité (0, n) ou (1, n) est considéré comme père et cède sa clé primaire a l’objet qui a la
cardinalité (0,1) ou (1,1) et considéré comme le fils.
Etant donné que le fils possède une clé primaire, celle qu’elle vient d’hériter du
père est une clé étrangère parce qu’elle est clé primaire dans sa table respective. Si la relation
était porteuse des propriétés, elles migrent vers la table fils.
2eme Cas : Relation du type père-père : contrainte d’intégrité multiple(CIM) ou cardinalité
multiple (CM)
Ce cas intervient lorsqu’on a d’une part le couple (0, n) ou (1, n), d’autre part (0, n)
ou (1, n). C’est-à-dire les combinaisons ci-après : (0, n) - (0, n); (0, n) - (1, n) et (1, n) – (1, n).
Dans ce cas, la relation devient une table de lien et aura comme clé primaire la
concaténation des clés primaires de deux tables qu’elle reliait. Si la relation était porteuse des
propriétés, celles-ci deviennent ses attributs.
3eme cas particuliers (élimination des associations fantômes)
Soient les couples (0,1) – (1,1) et (0,1) – (0,1) pour les couples (0,1) et (1,1), l’objet
ayant la cardinalité (0,1) est considéré comme étant le père et on applique la règle de la CIF.
Cependant lorsqu’il s’agit des couples (0,1) et (0,1), choisissez librement le père et appliquez
la CIF.
Après avoir traité ces deux points, le concepteur pourra tracer le MLD Brut que nous présentons
ci-dessous. Nous l’appelons Brut parce qu’il n’est pas encore normalisé.
 51

Présentation du Modèle Logique des données Brut (MLDB)

Service Abonné

#Numero_ab
#Code_serv Nom_ab
Libel_serv Postnm_ab
Prenom_ab
Adresse_ab
Telep_ab

Agents
Réclamation
# Matri_ag #num_recla
TRAITER
Nom_ag objet_recla
l #num_Trait
Postnm_ag date_recla
Libel_trait numéro_ab
Sexe_ag
Date_trait
Grade_ag
Decision
Fonct_ag
Matri_ag
Tel_ag
Num_recla
adr_ag
Code_serv

Figure 18 : MLDB
 52

1.2.2.3 Normalisation de la base de données

a. Définition et but
La normalisation est une opération intellectuelle permettant de supprimer les
dernières redondances et les valeurs nulles afin d’obtenir un modèle logique de données valide.
La normalisation est un processus qui consiste à éliminer les dernières redondances et
les valeurs nulles. Son objectif est d'éviter les anomalies dans les bases de données
relationnelles :
Problèmes de mise à jour ;
Suppression de redondances d'informations ;
Simplification de certaines contraintes d'intégrité.

Il existe cinq formes normales, les deux dernières ne sont que les cas particuliers
de trois premières.
b. Les formes normales
1ère Forme normale (1FN) : une table est en première forme normale (1FN), si elle a
une clé primaire et que ses attributs non clés sont atomiques (élémentaires).

2ème Forme normale (2FN) : une table est en deuxième forme normale (2FN), si elle
déjà en première forme normale et que ses attributs non clés dépendent totalement de la clé
primaire. Cette 2 FN s’appliquent aux tables à clé primaire composée.
Ainsi, sortir tout attribut non clé qui dépendrait en partie de la clé primaire.

3èmeForme normale (3FN) : une table est en troisième forme normale (3 FN), si elle
est déjà en deuxième forme normale et que ses attributs non clés ne dépendent pas
transitivement de la clé primaire. Garder dans la table initiale les attributs dépendant
directement de la clé primaire. Regrouper dans une autre table, les attributs dépendant
transitivement de la clé primaire.
 53

1.2.2.4 Présentation du Modèle Logique des données valide (MLDV)

Service Abonné

#Numero_ab
#code_serv Nom_ab
Libel_serv Postnm_ab
Prenom_ab
Tel_ab
Adresse_ab

FONCTION

#code_fonc
Libel_fonc

Agents
# Matri_ag Réclamation
Nom_ag TRAITER #num_recla
Postnm_ag #num_Trait objet_recla
Sexe_ag Libel_trait Date_recla
Tel_ag Date_trait Numero_ab
adr_ag Decision
Code_fonc Matri_ag
Code_gra Num_recla
Code_serv

GRADE
#code_gra
Libel_gra

Figure 18 : MLDV
 54

Schéma relationnel associé au Modèle Logique de Données valide

T_AGENT : ((# Matri_ag, text (10) ; Nom_ag, text (15) ; Postnm_ag text (10) ; Sexe_ag, text
(1) ; tel_ag, num (15) ; adresse_ag text (25) ; Code_Gra, text (15) ; Code_Fonc, text (15)).

T_FONCTION : ((# Code_fonc, text (10) ; Libel_Fonc, text (25)).

T_GRADE : ((# Code_Gra, text (10) ; Libel_Gra, text (25)).

T_DOCUMENT : (( # Code_Doc ; text 10 ; libel_doc ; text 25 ; Expedit_doc text (10) ;

Destin_doc text (10) ; date_liv ; date/heure 10 ; Matr_ag ; text 10 ;)).

T_ABONNE : (#Numero_ab, text (10) ; Nom_ab, text (15) ; Postnm_ab, text (15) ;
Adresse_ab, text (50) ; Matri_ag, text (10)).

T_RECLAMATION : (#num_recla, text (10) ; objet_recla, text (255) ; date_recla, text

(255) ; Numero_ab, text (10)).

T_TRAITER : (#num_Trait, text (10) ; Libel_trait, text(255) ; Date_trait,

Date/Heure(10), Decision, text (255), Matri_ag, text (10) ; Num_recla, text (10)).
 55

ETAPE PHYSIQUE
a. Définition et but
Le niveau physique de description du système d’information est la dernière étape de la
conception. Elle permet de résoudre le problème d’implémentation de la base de données ainsi
que le programme sur le support magnétique.
Cette étape comprend le modèle physique des traitements (MPT) et le modèle physique de
données (MPD).
II.1 Modélisation Physique de traitements (MPT)
II.1.1 Définition et but
Le MPT constitue l’ensemble des programmes informatiques qui assureront l’exécution
des traitements des informations informatisées du système Informatique. Il est la solution
technique de conception du logiciel. C’est une architecture technique des programmes qui
traduit concrètement la logique des traitements définis dans le MLT en fonction des possibilités
et des moyens de programmation. (DOMINIQUE, 1996)
II.1.2 Construction du MPT
La méthode merise n’a pas prévu une procédure permettant de schématiser un modèle
physique des traitements.
Le schéma du MPT représente l’articulation et l’enchainement possible entre les
différents programmes. (DOMINIQUE, 1996)
Nous le présenterons ci-dessous sous forme d’une structure arborescente.
 56

II.1.2.3 Présentation du Modèle Physique des traitements (MPT)

ECRAN D’ACCUEIL

BOITE DE CONNEXION

BARRE DES MENUS

FICHIER EDITION QUITTER

ENREGISTREMENT DES LISTE DES RECLAMATIONS

RECLAMATIONS
LISTE DES ABONNES

ENREGISTRER MODIFIER SUPPRIMER

BDD

Figure 23 : MPT
 57

II.2 Modélisation Physique de données (MPD)

II.2.1 Définition et but
La modélisation physique de données est donc la traduction du modèle logique de
données dans un langage de description spécifique au Système de gestion de base de données
(SGBD) retenu pour la réalisation du système d’information.
La finalité ici, est de créer la structure de la base des données qui n’est que la traduction
du modèle logique des données dans un langage de description des données spécifique ou
SGBD retenu pour la réalisation du système.

II.2.2 Construction du Modèle Physique de données

II.2.2.1 Définitions des concepts de base du MPD
Le modèle physique de données (MPD) est une représentation de l’organisation des
données tenant compte d’un système de gestion des données retenu, la plupart du temps un
SGBDR sous forme de TABLES comportant des champs (ou attribut).

La structure en tables et colonnes du MLDR est conservé, mais on va y ajouter les types
de données de chacune des colonnes (origine : dictionnaire de données).

Ces types de données vont varier et pourront être différent d’un SGBD à un autre. Les
clefs primaires sont représentées par PK (Primary Key). Elles matérialisent les contraintes
d’intégrité d’identité des tables, que le SGBDR devra contrôler.

Les clefs étrangères sont représentées par FK (foreing Key), Elles matérialisent les
contraintes d’intégrité référentielles que le SGBDR devra contrôler.

II.2.2.2 Passage du MLD au MPD

Le passage du MLD Relationnel au MPD associé à un SGBD relationnel ne présente pas
de difficultés majeures. Il s’agit de créer simplement le schéma relationnel de la Base de
Données par des requêtes en tirant profit au maximum de la fonctionnalité offerte par le SGBD
en matière d’organisation de chemin d’accès et de contrainte d’intégrité. (KonkfieIpepe, 2019)
Dans le passage du MLDR au MPD, il est important d’utiliser les vocabulaires appropriés.
 Les tables deviennent des fichiers ;
 La clé primaire devient la clé d’accès aux données ;
 Les attributs deviennent des champs ou rubriques.
 58

II.2.2.3 Présentation du MPD

Conclusion
Ce chapitre nous a permis de modéliser notre système d’information futur faisant une
description détaillée des objets fonctionnels du service de gestion de stock de produit finis en
utilisant la méthode de modélisation MERISE.
 59

CHAPITRE 6 : DEVELOPPEMENT DU SYSTEME D’INFORMATION

INFORMATISE
Introduction

VI.1 Définition et but

Le développement de logiciel consiste à étudier, concevoir, construire, transformer,
mettre au point, maintenir et améliorer des logiciels.

Différentes activités permettent de prendre connaissance des attentes de l'usager, créer

un modèle théorique du logiciel, qui servira de plan de construction, puis construire le logiciel,
contrôler son bon fonctionnement et son adéquation au besoin. La planification et la répartition
des travaux permettent d'anticiper le délai et le coût de fabrication.

VI.2 Présentation de la structure du logiciel

Notre logiciel est composé d’une base de données et d’une interface développée pour la
manipulation aisée de données.

VI.3 Choix et description de la plate-forme de développement

WinDev est un AGL (Atelier de Génie Logiciel). Il permet le développement des
applications dans tous les domaines.

WinDev permet de créer des applications accédant à des bases de données

HyperFileSQL Client/serveur. Une application HyperFileSQL Client/serveur consiste à
exécuter l'application sur différents postes utilisateur (appelés machines clientes) et à déporter
la ou les bases de données et les traitements sur un poste serveur. Ce mode de fonctionnement
permet des temps de réponses plus rapides et plus fiables, ainsi qu'une maintenance de la base
des données facilitée. Il permet de Créer entièrement une application HyperFileSQL
Client/serveur, de Modifier une application WinDev existante en une application
HyperFileSQL Client/serveur.

WinDev est un outil de développement complet qui intègre tous les outils nécessaires
au cycle de réalisation d’une application. Contrairement à d’autres langages de développement
traditionnels, il n’est pas nécessaire de chercher et de rajouter des modules pour pouvoir
concevoir, tester et installer une application.

Le L5G (Langage de 5ème Génération) de WinDev, le WLangage, par sa simplicité

permet de l’appréhender le langage, et de maîtriser toute sa puissance. Il est en français et est
aussi disponible également en anglais.

Système de Gestion de Base de Données (SGBD)

WinDev inclut un puissant moteur de base des données HyperFileSQL, ce moteur est
disponible en version réseau et Client/serveur. Afin d’optimiser le traitement de nos fichiers de
données, notre choix est porté sur HyperFileSQL Client/serveur.

Les principaux avantages que présente une application en mode HyperFileSQL

Client/serveur sont :
 60

 La sécurité de son utilisation (usage d’un login, d’un mot de passe, et définitions de
droits associés aux utilisateurs).
 Pas de gestion de répertoires : tous les fichiers de la base de données sont regroupés au
même endroit.
 Les clients finaux ne voient pas les fichiers de données dans leur explorateur et ne
peuvent pas y accéder directement.
 Les bases de données en mode Client/serveur peuvent être utilisées par une connexion
Internet.

III.4 Création des interfaces

61
 62

III.5 Ecriture des codes

HLitRecherche(Malades,Numero_mal,SAI_Numero_mal)
SI HTrouve ALORS
Info("Ce code a été attribué a un autre malade, veuillez saisir un autre")
SAI_Numero_mal=""
DonneFocus(SAI_Numero_mal)
SINON
EcranVersFichier(FEN_Enregistrement_des_malades,Malades)
HAjoute(Malades)
RAZ(Vrai)
DonneFocus(SAI_Numero_mal)
FIN
TableAffiche(TABLE_Malades,taDébut)

HLitRecherche(Malades,Numero_mal,SAI_Numero_mal)
SI PAS HTrouve ALORS
Info("Ce code n'a pas été attribué a un malade, veuillez saisir un autre")
SAI_Numero_mal=""
RAZ(Vrai)
DonneFocus(SAI_Numero_mal)
SINON
FichierVersEcran(FEN_Enregistrement_des_malades,Malades)
FIN
TableAffiche(TABLE_Malades,taDébut)

HLitRecherche(Malades,Numero_mal,SAI_Numero_mal)
SI PAS HTrouve ALORS
Info("Ce code n'a jamais été attribué a un malade, veuillez saisir un autre")
SAI_Numero_mal=""
RAZ(Vrai)
DonneFocus(SAI_Numero_mal)
SINON
EcranVersFichier(FEN_Enregistrement_des_malades,Malades)
HModifie(Malades)
RAZ(Vrai)
DonneFocus(SAI_Numero_mal)
FIN
TableAffiche(TABLE_Malades,taDébut)
 63

VI.6 Jeu d’essai-erreur

Conclusion du chapitre
Dans ce chapitre nous avons présenté le nouveau système d’information conçu avec la
méthode Merise, réalisé avec l’atelier de génie logiciel WinDev et la base des données et créée
avec le système de gestion de base de données Hyperfiles SQL.

Conclusion partielle
Dans la deuxième partie de notre travail, nous nous sommes concentré sur la mise en
place du nouveau système d’information en recourant à la méthode merise et ses différentes
étapes qui aboutissent à un model physique de base de données nous permettant ainsi de créer
une base de donnée, enfin une interface a été développé dans un atelier de génie logiciel
WinDev permettant ainsi de manipuler la base de données en toute simplicité.
 64

CONCLUSION GENERALE
Nous voici à la fin de notre travail de fin de cycle qui a consisté à informatiser la gestion
de réclamations au sein de la REGIDESO. Ce travail comprend deux grandes parties dont la
préparation du projet et la prise en compte des aspects techniques du projet.

La première partie, nous a donné la possibilité de connaitre et décrire l’organisation qui

a fait l’objet de notre travail qui est la REGIDESO au terme desquelles nous avons proposé des
solutions après une critique objective du système.

La deuxième partie, a fait l’objet de la conception et réalisation d’un nouveau système

d’information informatisé capable de gérer automatiquement les informations relatives à la
gestion de réclamations.

Ainsi, nous demandons aux responsables de la REGIDESO d’opter ce logiciel, car il

facilitera beaucoup de choses dans leur gestion.

En somme, l’œuvre humaine ne sera jamais parfaite dans son entièreté et sa perfectibilité
est continuelle, nous restons ouverts à toutes les critiques objectives que tout chercheur devra
bien nous adresser après la lecture de ce travail. Voilà d’une manière générale, la quintessence
de l’étude que nous avons menée.
 65

BIBLIOGRAPHIE

CASTELLANI, X. (2002). Méthode générale d’une application. paris: Ed. FoucheTome II. r,
.
Dictionnaire Petit ROBERT de poche, p. 5. (s.d.).
DOMINIQUE. (1996). ngénierie des systèmes d’information. PARIS: MERISE 2ème
génération.
GRAWITZ. (2001). Méthodes de recherche en sciences sociales. Paris: Dalloz.
IKUMA. (2015). Essai méthodologique sur la rédaction d’un travail scientifique. CRIGED.
IPEPE. (2018). Technique de base de données .
JACQUES, P. (1990). Initiation à la micro-informatique. Paris: EYROLLES.
KALUYIT, M. (2009-2010). cours de technique de base de données. Kinshasa: Criged.
KOLA. (2012-2013). Note de cours Informatiques Général. Kinshasa.
KonkfieIpepe. (2019). note des cours TBDD. KINSHASA: CRIGED.
LAUBET. (2000). Initiation aux méthodes de recherche en sociales. Paris: L'Harmattan.
NDOLO. (2013-2014). note de cours initiation à la recherche scientifique. Kinshasa: UCCM.
Reix, R. (1982). Analyse Informatique de gestion. Paris : éd. Bandas paitiers .
ROZSOHAZY. (1973). théories des critiques des faits sociaux. Bruxelles: La renaissance du
livre.
TARDIEU HUBERT. (1998). La méthode meris. Paris : DUNOD.
 66

TABLE DES MATIERES

EPIGRAPHE ............................................................................................................................................i
DEDICACE ............................................................................................................................................. ii
REMERCIEMENTS .............................................................................................................................. iii
INTRODUCTION GENERALE .............................................................................................................. 1
Problématique et Hypothèse ..................................................................................................................... 1
Choix et intérêt du sujet............................................................................................................................ 2
Délimitation du sujet ................................................................................................................................ 2
Etat de la question .................................................................................................................................... 2
Méthodes et techniques utilisées .............................................................................................................. 2
Canevas du travail .................................................................................................................................... 3
PREMIERE PARTIEETUDE PREALABLE .......................................................................................... 4
CHAPITRE I : PRESENTATION DE LA REGIDESO .......................................................................... 5
I.1 HISTORIQUE ................................................................................................................................. 5
I.2 SITUATION GEOGRAPHIQUE ................................................................................................... 5
I.3 MISSIONS ...................................................................................................................................... 5
I.4 OBJECTIFS .................................................................................................................................... 5
I.5 ORGANIGRAMME ....................................................................................................................... 6
Conclusion du chapitre ............................................................................................................................. 8
CHAPITRE 2 : ANALYSE DE L’EXISTANT ....................................................................................... 9
II.1. Définition et but ............................................................................................................................ 9
II.2 Description de la structure organisationnelle................................................................................. 9
II.2.1 Etude des postes de travail ...................................................................................................... 9
II.2.2 Etude documents utilisés ...................................................................................................... 10
II.2.3 Etude des Moyens utilisés..................................................................................................... 11
II.3 DESCRIPTION DE LA STRUCTURE FONCTIONNELLE ..................................................... 12
II.3.1 SCHEMA DE CIRCULATION DES INFORMATIONS .................................................... 12
II.3.2 LEGENDE ET ABREVIATIONS........................................................................................ 13
III.4 CRITIQUE DE L’EXISTANT ...................................................................................................... 14
III.4.1. Critique d’ordre général ......................................................................................................... 14
III.4.2. critique d’ordre spécifique...................................................................................................... 14
III.4.3 Propositions des solutions ....................................................................................................... 14
III.4.4. Choix de la meilleure solution.................................................................................................... 16
Conclusion du chapitre ........................................................................................................................... 16
CONCLUSION DE LA PREMIERE PARTIE ...................................................................................... 16
DEUXIEME PARTIEMISE EN PLACE DU NOUVEAU SYSTEME D’INFORMATION ............... 17
 67

CHAPITRE I : MODELISATION DU SYSTEME D´INFORMATION ORGANISE (S.I.O) ............. 17

SECTION 1 : ETAPE CONCEPTUELLE ......................................................................................... 17
I.1. Définition et but ....................................................................................................................... 17
I.2. Modélisation conceptuelle de communication (MCC) ............................................................ 17
I.3. Modélisation Conceptuelle des Traitements (MCT) ................................................................ 19
I.4 MODELISATION CONCEPTUELLE DES DONNEES (MCD) ............................................ 22
SECTION 2 : ETAPE ORGANISATIONNELLE ............................................................................. 29
2.1. Modélisation Organisationnelle des traitements (MOT) ......................................................... 29
2.2. Modélisation organisationnelle des données (MOD) .............................................................. 31
Conclusion du chapitre ........................................................................................................................... 33
CHAPITRE II : MODELISATION DU SYSTEME D’INFORMATION INFORMATISE (SII) ........ 34
Section 1 : Etape logique .................................................................................................................... 34
1.1 Modélisation Logique des traitements (MLT).......................................................................... 34
1.2 MODELISATION LOGIQUE DES DONNEES (MLD) ........................................................ 36
Section II : ETAPE PHYSIQUE ........................................................................................................ 43
II.1 Modélisation Physique des traitements (MPT) ........................................................................ 43
II.2 Modélisation Physique des Données (MPD) ........................................................................... 47
Section III : DEVELOPPEMENT DU SYSTEME D’INFORMATION INFORMATISE ............... 51
III.1 Définition et but.......................................................................................................................... 51
III.2 Présentation de la structure du logiciel ....................................................................................... 51
III.3 Choix et description de la plate-forme de développement ......................................................... 51
III.4 Création des interfaces ............................................................................................................... 51
III.5 Ecriture des codes........................................................................................................................... 51
III.6 Test et jeu d’essaie ..................................................................................................................... 54
Conclusion du chapitre ........................................................................................................................... 64
Conclusion de la partie ........................................................................................................................... 65
CONCLUSION GENERALE ................................................................................................................ 65
REFERENCES BIBLIOGRAPHIQUES ........................................................................................... 66