CHAPITRE III.

MODELISATION ET MISE E ŒUVRE DE LA SOLUTION

3.1. LE NIVEAU CONCEPTUEL
L'objectif est de représenter l'activité de l'entreprise et de formaliser son "système
d'information" indépendamment de son organisation (DIVINE, 2008). Le MCC formalise les
échanges des informations entre le système fonctionnel et identifie le système en mémoire, il
est la correction du diagramme de flux (MASIVE, 2022)
3.1.1 Modèle Conceptuel de communication

SECRETAIRE

1
RECEPTIONNER
11 2
10 15
8 ELABORER
14
12 16 3 18
17 ENVOYER
9
13
4
CLIENT
DIRECTEUR TECHNIQUE

RECEPTIONNER
5
7
ELABORER
6
ENVOYER

19

DIRECTEUR GENERAL

RECEPTIONNER
Légende de MCC :

1. Demande de devis
2. Réception de la demande de devis
3. Elaboration de devis
4. Envoie de devis
5. Réception de devis
6. Elaboration de facture pro-forma
7. Envoie de facture pro-forma chez le secrétaire
8. Réception de celle-ci
9. Envoie de celle-ci au client
10. Demande de réservation
11. Réception de la demande
12. Elaboration de facture finale
13. Envoie de celle-ci au client
14. Demande de payement
15. Réception de la demande
16. Elaboration de reçu
17. Envoie de celui-ci au client
18. Elaboration de rapport final
19. Envoie de celui-ci au directeur général

3.1.2. Modèle Conceptuel des Données (MCD)

Le modèle conceptuel des données (MCD) permet de représenter de façon
organisée les données qui seront utilisées par le système d’information. Il décrit de façon
formelle les données utilisées par le système d’information. (BAPTISTE, 2018)

a. Règles de gestion

1. Un agent doit avoir un identifiant et a aussi un nom, postnom, prénom, contact, email,
adresse et password ;
2. Un client doit avoir un identifiant et a aussi un nom, postnom, prénom, contact, email,
adresse et password ;
3. Une fonction doit avoir un identifiant et a aussi une description ;
4. Une réservation doit avoir un identifiant et a aussi une description, une date, une
quantité et un prix unitaire ;
 5. Un message doit avoir un identifiant et a aussi une description et une date ;
6. Une facture doit avoir un identifiant et a aussi une quantité, unité et un prix unitaire ;
7. Un payement doit avoir un identifiant et a aussi une date et un montant ;
8. Un service doit avoir un identifiant et a aussi une description ;
9. Un article doit avoir un identifiant et a aussi une description.
b. Dictionnaire des données

N0 Code Description Type Taille M.O

Mnémonique
1 Idserv Identifiant service N 11 Auto
2 Descserv Description service AN 100 Mémorisé
3 Idfonct Identifiant fonction N 11 Auto
4 Descfonct Description fonction AN 100 Mémorisé
5 Idag Identifiant agent N 11 Auto
6 Nomag Nom agent AN 100 Mémorisé
7 Postnomag Postnom agent AN 100 Mémorisé
8 prenomag Prénom agent AN 100 Mémorisé
9 Contactag Contact agent AN 100 Mémorisé
10 Emailag Email agent AN 100 Mémorisé
11 Adresseag Adresse agent AN 100 Mémorisé
12 Passwordag Password agent AN 100 Mémorisé
13 Idcli Identifiant client N 11 Auto
14 Nomcli Nom client AN 100 Mémorisé
15 Postnomcli Postnom client AN 100 Mémorisé
16 Prenomcli Prénom client AN 100 Mémorisé
17 Contactcli Contact client AN 100 Mémorisé
18 Emailcli Email client AN 100 Mémorisé
19 Adressecli Adresse client AN 100 Mémorisé
20 Passwordcli Password client AN 100 Mémorisé
21 Idmess Identifiant message N 11 Auto
22 Descmess Description message AN 100 Mémorisé
23 Datemess Date message D - Mémorisé
24 Idart Identifiant article N 11 Auto
25 Descart Description article AN 100 Mémorisé
26 Idres Identifiant réservation N 11 Auto
28 Descres Description réservation AN 100 Mémorisé
29 Dateres Date réservation D - Mémorisé
30 Qteres Quantité réservation N - Mémorisé
31 Idfact Identifiant facture N 11 Auto
32 Qtefact Quantité facture N - Mémorisé
33 Unitefact Unité facture AN 100 Mémorisé
34 Pufact Prix unitaire facture N - Mémorisé
35 Idpaie Identifiant paiement N 11 Auto
36 Datepaie Date paiement D - Mémorisé
37 Montpaie Montant paiement N - Mémorisé

c. Graphe de dépendance fonctionnelle

Le graphe de dépendance fonctionnelle est une étape intéressante car il épure le

dictionnaire en ne retenant que les données non déduites et élémentaires et il permet une
représentation spatiale de ce que sera le futur modèle conceptuel des données. (BAPTISTE,
2018)
 d. Modèle Entité Association (MEA)
Le modèle Entité association est la reproduction du système que l’on veut décrire, aussi
appelé modèle conceptuel des données. Elle permet à partir de donnée fonctionnelle de
reproduire les données sous-forme d’entité et association.
Règle de passation de Graphe de la donnée fonctionnelle des données au MEA :
- Une entité doit avoir les propriétés qui les caractérisent parmi lesquelles une propriété
pour l’identifier (identifiant) ;
- Toute propriété but de donnée fonctionnelle ayant une seule propriété d’entité ;
- On doit marquer (1, N) du côté des entités des rubriques sources et (1,1) du côté des
buts (BAPTISTE, 2018).
 T_ FERI
3.1.3. Modèle conceptuel de traitement
3.2. NIVEAU ORGANISATIONNEL
3.2.1. Model Organisationnel de Traitement (MOT)
Le modèle organisationnel de traitement complète la description conceptuelle des
traitements en intégrant tout ce qui est d’ordre organisationnel dans le domaine étudié. Il
précise : qui exécute les traitements et la nature des traitements (manuels, automatiques,
Semi-automatique), les lieux où sont exécutés les traitements (poste de travail), quand sont
exécutés les traitements (notion de temporalité). (BAPTISTE, 2018)
3.3. NIVEAU LOGIQUE
3.3.1. Modèle Logique de Données (MLD)
Le modèle Logique de Données est la suite normale du processus Merise. Son but est
nous rapprocher plus près du modèle physique (BAPTISTE, 2018).
En appliquant les règles de passage du MCD au MLD, nous avons obtenu le MLD
suivant :

R_SERVICE(Idserv,descserv)

R_FONCTION(Idfonct,descfonct,idserv#)

R_AGENT(Idag,nomag,postnomag,prenomag,contactag,emailag,adresseag,passwordag,idfon
ct#)

R_CLIENT(idcli,nomcli,postnomcli,prenomcli,contactcli,emailcli,adressecli,passwordcli)

R_ARTICLE(idart,descart)

R_MESSAGE(idmess,descmess,datemess,idag#,idcli#)

R_RESERVATION(idres,descres,dateres,qteres,pures,idcli#,idart#)

R_FACTURE(idfact,qtefact,unitefact,pufact,idres#)

R_PAIEMENT(idpaie,datepaie,montpaie,idfact#)
3.3.2. Modèle Logique de traitement (MLT)