Cours de MERISE G2 Jour ISC 2021 - 2022-1

REPUBLIQUE DEMOCRATIQUE DU CONGO
ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE
INSTITUT SUPERIEUR DE COMMERCE

I.S.C.
B.P : 67 GOMA
COURS DE METHODE D’ANALYSE DES

SYSTEMES INFORMATIQUES
« M.A.I. 1 »
Cours Conçu et dispensé par

l’Assistant2 KAKULE MUSUBAO
Jean
Tél : 0998707246
0853110733
0896480535
e‐mail : kakulemusub@yahoo.fr
jkmusubao@gmail.com
ANNEE ACADEMIQUE 2021‐2022

‐2‐
Chap I : NOTIONS PRELIMINAIRES SUR LA METHODE MERISE
I.1.‐ INTRODUCTION
La conception d'un système d'information n'est pas évidente car il faut réfléchir à l'ensemble
de l'organisation que l'on doit mettre en place. La phase de conception nécessite des méthodes permet-
tant de mettre en place un modèle sur lequel on va s'appuyer. La modélisation consiste à créer une
représentation virtuelle d'une réalité de telle façon à faire ressortir les points auxquels on s'intéresse.
Ce type de méthode est appelé analyse. Il existe plusieurs méthodes d'analyse, la méthode la plus utili-
sée en France et en RDC étant la méthode MERISE.
Qu'est-ce qu'une méthode ?
Une méthode comporte trois axes indispensables pour obtenir ce label « méthode » :
 une démarche, ensemble coordonné d'étapes, de phases et de tâches indiquant le chemin à
suivre pour conduire un projet, ici, la conception d'un SI,
 des raisonnements et des techniques nécessaires à la construction de l'objet projeté, traduits ici
par des modélisations,
 des moyens de mise en œuvre, en l'occurrence une organisation de projet et des outils.
Seule la réunion de ces trois dimensions permet une utilisation opérationnelle. Dès le début,
Merise s'est voulu une méthode. Avec un effet induit : dès que l'un des axes est remis en cause, l'en-
semble en pâti…C'est en effet la lourdeur de la démarche, dénoncée dans les années 90, qui a « plom-
bé » Merise.
Qu’est-ce que MERISE ?
MERISE (prononcer « Meurise » et non « Mérise »). Ce sigle signifie Méthode d’Etude et
de Réalisation Informatique pour les Systèmes d’Entreprises. C’est donc une méthode d'ana-
lyse, de conception et de gestion des projets informatiques.
Le but de cette méthode est d'arriver à concevoir un système d'information. La méthode ME-
RISE est basée sur la séparation des données et des traitements à effectuer en plusieurs modèles con-
ceptuels et physiques. La séparation des données et des traitements assure une longévité au modèle. En
effet, l'agencement des données n'a pas à être souvent remanié, tandis que les traitements le sont plus
fréquemment.
La méthode Merise apporte une formalisation éclairant les choix à effectuer. Elle est un lan-
gage commun de référence centré sur le système d’information et non sur l’informatique appliquée.
Elle permet une authentique communication entre le responsable de la stratégie d’entreprise, celui de
son informatisation et les utilisateurs finals.
Elle structure les vœux du dirigeant et de l’utilisateur sous formes de dessins pour une com-
préhension facile et de dossiers pour une explication complète permettant au responsable de
l’informatique de choisir ou d’écrire les programmes. Le choix final d’informatisation sera conforme
aux désirs de l’utilisateur et aux possibilités informatiques. Les dessins illustrent la syntaxe du lan-
gage. En découleront l’agencement des informations et l’ensemble des taches à réaliser. Ainsi, le pro-
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Cours conçu et dispensé par l’Ass2. Kakule Musubao , ISC-GOMA , G2 JOUR I.G. mail : kakulemusub@yahoo.fr, jkmusubao@gmail.com, Tél : 0998707246 ,
0853110733 , Année Académique 2021-2022
‐3‐
jet sera mené avec rigueur et cohérence afin d’obtenir les objectifs de fiabilité des données et
d’évolution des applications.
Les programmes seront documentés et l’entreprise en sera rendue moins fragile : plus de pa-
nique son programme écrit en langage machine !
En fin, Merise est une méthode qui conduit à une réflexion sur l’entreprise et peut aider à mo-
difier son organisation, voire d’en créer une nouvelle.
Ce cours sur l’analyse des systèmes d’information des organisations revêt un caractère obliga-
toire pour tout étudiant ayant des ambitions d’obtention d’un diplôme de graduat dans l’option
Informatique de gestion. C’est un cours qui est à la base de la conception des applications de ges-
tion. Toute conception d’une base de données doit passer par cette étape d’analyse du système
d’information de l’organisation dont on a l’ambition d’automatiser certaines tâches.
En fait, c’est grâce aux concepts que les étudiants auront appris dans ce cours qu’ils seront
capables de concevoir, de rédiger et de soutenir leurs travaux de fin de cycle. Les modèles et les for-
malismes que contient ce cours permettront aux étudiants de concevoir des applications informatiques
fiables et qui respectent les normes de programmation. C’est pourquoi les étudiants devraient suivre
ce cours avec beaucoup de sérieux et se disponibiliser pour participer aux travaux pratiques tout au
long de la dispensation de ce cours.
I.2.‐ OBJECTIFS DU COURS

A la fin de ce cours, l’étudiant qui aura suivi attentivement et régulièrement ce cours sera
capable de :
 Concevoir et d’organiser le système d’information d’une organisation.

 Comprendre les notions essentielles sur le SI ;
 Concevoir un modèle conceptuel des données (MCD) ainsi que sa construction ;
 Construire un modèle conceptuel de traitement (MCT) et comprendre les concepts liés à sa
conception ;
 Comprendre les concepts de base du modèle organisationnel de traitement (MOT) et arriver à
être capable de le concevoir ;
 Produire le modèle logique des données (MLD)
 D’utiliser et de concevoir les différents modèles de la méthode MERISE ;
Nous précisons toutefois que dans le cadre de ce cours, nous nous sommes limités aux notions impor-
tantes et indispensables de MERISE. L’Etudiant consciencieux, courageux et soucieux de connaître est
appelé à faire d’autres recherches (sur Internet, lecture des livres sur MERISE…)
I.3.‐ MODELISATION :
 Un modèle est une représentation artificielle de ce que l'on pense avoir compris du monde en-
vironnant. Il possède trois propriétés :
- la figuration : les figures sont mises à la place de concepts généraux
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐4‐
- l'imitation : il copie sur un support des relations perçues sur l'environnement

- la formalisation : il propose de mettre de l'ordre dans la diversité observée ;
-sert :
- à communiquer : voir si on a bien compris la même chose que les utilisateurs
- à préparer la réalisation. Un modèle peut dire deux choses :
- ce que l'application devra faire (une spécification)
- comment elle est organisée du point de vue de l'ordinateur (une réalisation).
 Un modèle est une abstraction de la réalité. L'abstraction est un des piliers de l'approche objet.
 Il s'agit d'un processus qui consiste à identifier les caractéristiques intéressantes d'une
entité, en vue d'une utilisation précise.
 L'abstraction désigne aussi le résultat de ce processus, c'est-à-dire l'ensemble des ca-
ractéristiques essentielles d'une entité, retenues par un observateur.
 Un modèle est une vue subjective mais pertinente de la réalité
 Un modèle définit une frontière entre la réalité et la perspective de l'observateur. Ce
n'est pas "la réalité", mais une vue très subjective de la réalité.
 Bien qu'un modèle ne représente pas une réalité absolue, un modèle reflète des aspects
importants de la réalité, il en donne donc une vue juste et pertinente.
 Caractéristiques fondamentales des modèles
Le caractère abstrait d'un modèle doit notamment permettre :
 de faciliter la compréhension du système étudié

Un modèle réduit la complexité du système étudié.
 de simuler le système étudié
Un modèle représente le système étudié et reproduit ses comportements.
 Un modèle réduit (décompose) la réalité, dans le but de disposer d'éléments de travail
exploitables par des moyens mathématiques ou informatiques : modèle / réalité ~ digi-
tal / analogique
Pourquoi modéliser ?
Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionne‐
ment du système. C’est également un bon moyen de maîtriser sa complexité et d’assurer sa cohé‐
rence. Un modèle est un langage commun, précis, qui est connu par tous les membres de l’équipe
et il est donc, à ce titre, un vecteur privilégié pour communiquer. Cette communication est essen‐
tielle pour aboutir à une compréhension commune aux différentes parties prenantes (notamment
entre la maîtrise d’ouvrage et la maîtrise d’œuvre informatique) et précise d’un problème donné.
Dans le domaine de l’ingénierie du logiciel, le modèle permet de mieux répartir les tâches et
d’automatiser certaines d’entre elles. C’est également un facteur de réduction des coûts et des délais.
Par exemple, les plateformes de modélisation savent maintenant exploiter les modèles pour faire de la
génération de code (au moins au niveau du squelette) voire des allers-retours entre le code et le modèle
sans perte d’information. Le modèle est enfin indispensable pour assurer un bon niveau de qualité et
une maintenance efficace. En effet, une fois mise en production, l’application va devoir être mainte-
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐5‐
nue, probablement par une autre équipe et, qui plus est, pas nécessairement de la même société que
celle ayant créée l’application.
Le choix du modèle a donc une influence capitale sur les solutions obtenues. Les systèmes
non triviaux sont mieux modélisés par un ensemble de modèles indépendants. Selon les modèles
employés, la démarche de modélisation n’est pas la même.
I.4.‐ HISTORIQUE DE LA METHODE MERISE JUSQU’AUX METHODES OBJET
La méthode MERISE date de 1978-1979, et fait suite à une consultation nationale lancée en
1977 par le ministère de l'Industrie dans le but de choisir des sociétés de conseil en informatique afin
de définir une méthode de conception de systèmes d'information. Les deux principales sociétés ayant
mis au point cette méthode sont le CTI (Centre Technique d'Informatique) chargé de gérer le projet, et
le CETE (Centre d'Etudes Techniques de l'Equipement) implanté à Aix-en-provence.
Avant de mettre au point la méthode MERISE les chercheurs ont d’abord essayé d’autres mé-
thodes telles que :
1. Les premières méthodes d'analyse (années 70)

 Découpe cartésienne (fonctionnelle et hiérarchique SA/SD, SADT [Structured Ana-
lysis and Design Technique]) d'un système.
2. L'approche systémique (années 80)
 Modélisation des données + modélisation des traitements (Merise, Axial, IE...).
3. L'émergence des méthodes objet (1990-1995)
 Prise de conscience de l'importance d'une méthode spécifiquement objet : comment
structurer un système sans centrer l'analyse uniquement sur les données ou uniquement
sur les traitements (mais sur les deux) ?
4. Premiers consensus (1995)
 OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles d'un système
 OOD (GradyBooch) : vues logiques et physiques du système
 OOSE (Ivar Jacobson) : couvre tout le cycle de développement
5. L'unification et la normalisation des méthodes (1995-1997)
 UML (Unified Modeling Langage), la fusion et synthèse des méthodes dominantes.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐6‐
Chap II : SYSTEMES D’INFORMATION

II.1.‐ NOTION DU SYSTEME
II.1.1.- Définitions d'un système
 Une définition courante mais excessivement vague est celle d'un ensemble d'éléments en inter-
relation les uns avec les autres.
 Un système est aussi un ensemble d’éléments matériels ou immatériels (homme, machine, mé-
thodes, règles,…) en interaction transformant par un processus des éléments (les entrées) en
d’autres éléments (les sorties).
L’entreprise est donc un système complexe dans lequel transitent de très nombreux flux
d’informations. Sans un dispositif de maîtrise de ces flux, l’entreprise peut très vite être dépassée et ne
plus fonctionner avec une qualité de service satisfaisante. L’enjeu de toute entreprise qu’elle soit de
négoce, industrielle ou de services consiste donc à mettre en place un système destiné à collecter, mé-
moriser, traiter et distribuer l’information (avec un temps de réponse suffisamment bref). Ce système
d’information assurera le lien entre deux autres systèmes de l’entreprise : le système opérant et le sys-
tème de pilotage.
Une entreprise est donc un système décomposable en trois sous‐systèmes : le sous‐

système opérant (SO) ; le sous‐système de pilotage (SP) et le sous‐système d’information (SI).
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐7‐
Le sous‐système opérant ou technologique active les processus métier de l’entreprise pour créer la
valeur ajoutée; le sous‐système de pilotage ou de décision coordonne l’ensemble de l’activité en
fonction des objectifs ; le sous‐système d'information ou de mesure décrit, mémorise et capte l'en‐
semble des événements et des transformations caractéristiques à la fois du sous‐système de décision
et du sous‐système d'opération (base d'information, entrée, sortie, traitement).
Par ailleurs, un système de gestion (SG) ou système pilotage (SP) procède au pilotage (à la ré-
gulation et au contrôle) du système opérant en décidant du comportement de celui-ci en fonction des
objectifs fixés. Ce système se compose par exemple de la direction financière, de la direction com-
merciale, de la direction de la production,… il reçoit du SO des informations sur l’état du système
(dont certaines, les variables essentielles, lui permettent de mesurer l’écart avec les objectifs) et réagit
par des décisions (commandes) sur le processus du SO par régulation des flux (fixation des cadences
de production, décision de lancer une nouvelle gamme de produits ou de modifier le prix de vente de
tel article,…).
En interface entre le SO et le SP (SG), toute organisation évoluée doit se doter d’un SI.
information-représentation : in-
Système de pilotage formation qui donne une représentation du
réel ; ce réel pouvant être soit le système
opérant (états discrets) soit le système
d’information lui-même.
Système d’information information‐décision
information‐intéraction :
Système opérant
information nécessaire au système opérant
pour qu’il fonctionne
 Le système de pilotage décide des actions à conduire sur le système opérant en fonction des objec-
tifs et des politiques de l’entreprise,
 Le système opérant englobe toutes les fonctions liées à l’activité propre de l’entreprise : facturer
les clients, régler les salariés, gérer les stocks, …
Une telle décomposition prend bien en compte :
- la différence de besoin en matière d’information des modules opérants et pilotes,

- la nécessité pour le système d’information de ne pas se contenter de transmettre les infor-
mations mais d’en changer le niveau de synthèse.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐8‐
II.1.2.- LE SYSTEME D’INFORMATION D’UNE ENTREPRISE OU ORGA-

NISATION (SI)
Le système d’information est la mémoire de l’entreprise ; il sert d’interface entre le système
décisionnel (SP) et le système opérationnel (SO) cfr la figure ci-dessous:
SCHEMA DU S.I. D’UNE ENTREPRISE
Le SI est composé d’éléments divers (employés, ordinateurs, règles et méthodes…) chargés de

stocker et de traiter les informations relatives au SO afin de les mettre à la disposition du SP (système
de pilotage). Il peut en outre recevoir de celui-ci des décisions destinées à son propre pilotage. Enfin, il
peut émettre vers le SO des informations interactions, c'est-à-dire qu’il peut réagir sur le SO (par
exemple le SO ne pourra livrer le produit au client que s’il obtient du SI l’information que le produit
est en stock).
Le SI comprendra donc des images formalisées, des flux du SO (bon de commandes, de livrai-
son, factures,…) et des données comptables utilisées par exemple par le contrôle de gestion. Il est en
liaison d’une part avec un environnement interne (SO et SP) et d’autre part avec un environnement
externe (client, fournisseurs,…). Ces deux environnements constituent l’univers extérieur (l’UE) du
SI.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐9‐
II.1.3.- ARCHITECTURE ET CONCEPTION D’UN SYSTEME

D’INFORMATION
Le système d’information doit décrire (on dit encore représenter) le plus fidèlement possible le
fonctionnement du système opérant. Pour ce faire, il doit intégrer une base d’information dans laquelle
seront mémorisés la description des objets, des règles et des contraintes du système opérant. Cette
base étant sujette à des évolutions, le système d’information doit être doté d’un mécanisme (appelé
processeur d’information) destiné à piloter et à contrôler ces changements. Le schéma suivant synthé-
tise l’architecture d’un système d’information.
Base d’information
Faits et événements
Processeur d’information
Etats de la base
d’information
Le processeur d’information produit des changements dans la base d’information à la réception

d’un message. Un message contient des informations et exprime une commande décrivant l’action à
entreprendre dans la base d’information. Le processeur d’information interprète la commande et effec-
tue le changement en respectant les contraintes et les règles.
Si le message exprime une recherche sur le contenu de la base d’information, le processeur inter-
prète la commande et émet un message rendant compte du contenu actuel de la base d’information.
Dans tous les cas, l’environnement a besoin de connaître si la commande a été acceptée ou refusée.
Le processeur émet, à cet effet, un message vers l’environnement.
Relativement à la conception d’un système d’information, l’architecture présentée ci-dessus induit

une double conception :
- celle de la base d’information (aspect statique)

- celle du processeur de traitement (aspect dynamique)
Le SI est donc la mémoire de l’organisation.
Il contrôle à ce titre un aspect statistique :
 Enregistrement des faits survenus dans l’univers extérieur dans un ensemble mémorisé
qu’on pourrait qualifier de base d’informations (H. Tardieu parle de « l’univers du dis-
cours »).
 Enregistrement de structures de données, règles et contraintes de l’univers extérieur de
manière formalisée dans un ensemble mémorisé qu’on pourrait qualifier de modèle de
données (base de données). Définir la structure selon les règles et les contraintes et y en-
registrer les données.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 10 ‐
Le SI comporte un aspect dynamique :
 Possibilité de mise à jour de données mémorisées dans la base d’informations

 Possibilité (pour le système adaptable) de changer les structures, règles et contraintes du
modèle de données suite à des changements survenus dans l’Univers Extérieur et en reflet
de ceux-ci.
Cette partie active du SI constitue le processeur d’informations (autrement dit le sous-

système qui traite l’information).
Chaque fait ou événement survenu dans l’UE constitue un message pour le processeur
d’informations, message contenant une commande ou des informations.
A l’aide de règles qu’il trouve dans le modèle, le processeur d’information interprète les messages et
procède à des modifications dans la base d’informations (ou dans le modèle même) et ou restitue un
message donnant des informations sur la base ou le modèle. Le processeur d’informations peut-être
constitué d’hommes et des machines
REMARQUE :
Dans certaines organisations, on peut trouver des formes plus intégrées du système d’information.
Cette intégration peut se faire soit au niveau du système opérant, soit au niveau du système de pilo-
tage.
- Un système d’information intégré au système opérant ne décrit plus le fonctionnement du

système opérant mais il est intégré à ce fonctionnement. Par exemple dans un système de
GPAO (Gestion de Production assistée par Ordinateur), les décisions de pilotage sont di-
rectement traduites en des décisions d’exécution de règles incluses dans une gamme opé-
ratoire.
- Un système d’information intégré au système de pilotage doit permettre d’engranger les
décisions prises lors de diverses situations afin de rendre le pilotage plus intelligent. Ces
Systèmes Interactifs d’Aide à la Décision (S.I.A.D) ont une architecture proche de celle
des systèmes experts et font donc largement appel pour leur conception aux techniques de
l’intelligence artificielle.
Pour aider le concepteur dans ces deux tâches, la méthode Merise propose un ensemble de
formalismes et de règles destinées à modéliser de manière indépendante les données et les trai-
tements du système d’information. Ces modèles ne sont qu’une base de réflexion pour le concep-
teur et un moyen de communication entre les divers acteurs du système d’information dans
l’entreprise. Seule la validation de l'ensemble se fera en commun.
II.1.4.- ACTIONS ROGRAMMEES ET DECISIONS

Dans un système des actions programmées (avec ou sans ordinateur) sont des actions qui dé-
terminent de manière unique les sorties à partir des entrées.
Exemple : la connaissance écritures comptables détermine de manière unique la nouvelle balance.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 11 ‐
Il existe une règle unique parfaitement explicitable (formalisable) permettant de déduire la

nouvelle balance de l’ancienne à partir des écritures passées. Autrement dit la nouvelle balance (les
sorties)) est déterminée par la connaissance des entrées (les écritures). Nous disons alors que le sys-
tème est déterminé. Dans ce cas, les entrées E déterminent les sorties S de manière unique. S= f(E)
E S
Système sans décisions
Quantité x PV PTV
Mais un système peut se trouver en situation d’informations incomplètes. Dans ce cas, une même
entrée E peut conduire à plusieurs sorties possibles, S, S1, S2, S3, etc. Le choix de la sortie effective-
ment réalisée se fait par une décision.
Exemple : la connaissance du niveau de stock ne détermine pas les quantités à commander au fournis-
seur. (Intuition, intérêt personnel, expérience, habitude,…) qui peuvent intervenir dans un choix ou
une décision. Le processeur qui, dans un système transforme les entrées E en sorties S peut compor-
ter :
 Des actions programmées

 Des choix (décisions)
II.2.- SYSTEME D’INFORMATION AUTOMATISABLE

On peut se poser la question de savoir à quelles conditions un SI est automati‐
sable (informatisable), autrement dit à quelle condition un SI peut être pris en charge
par des ordinateurs.
Pour qu’un SI soit automatisable, il doit être formalisable. La connaissance des

entrées doit permettre de déterminer les sorties par des règles de transformation expli‐
citables. Seules seront automatisables les parties du SI qui ne contiennent que des ac‐
tions programmées (les sous systèmes formalisables).
Les choix ne sont pas formalisables et donc ils sont non automatisables. Les
choix appartiennent à l’homme. Il est toute fois possible de transformer les choix en
actions programmées en ayant recours à un modèle.
Par exemple : les décisions de réapprovisionnement peuvent s’effectuer par l’utilisation

d’un modèle de gestion des stocks tel que : si stock alors commander 2000.
Dans ce cas, la décision est prise une fois pour toutes (par l’homme) à l’avance et
chaque fois que le stock tombera en dessous de 500, on appliquera le modèle en com‐
mandant 2000, ce qui n’est autre chose qu’une action programmée puisque la connais‐
sance du stock détermine de manière unique la quantité à commander (0 si stock
si stock
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 12 ‐
II.3‐ SYSTEME AUTOMATISE D’INFORMATION (SAI)
II.3.1.- DEFINITION
Un SAI est un sous‐système d’un SI dans lequel toutes les transformations signifi‐
catives d’informations sont effectuées par des machines de traitement automatique des
informations (ordinateurs). Il permet la conservation et le traitement automatique des
informations.
Deux raisons justifient l’automatisation d’un SI :
 Simplification et amélioration du travail administratif (comptabilité, facturation,
paie,…) par l’automatisation des procédures répétitives et fastidieuses de simple
exécution.
 Aider à la décision : la décision appartient à l’homme et non à l’ordinateur.
L’ordinateur peut donc fournir à l’homme des éléments qui lui permettront de
faire ses choix en disposant du maximum d’informations possibles ; l’ordinateur
pouvant sélectionner à grande vitesse parmi une grande masse de données mé‐
morisées. Les décisions utiles à la prise de décisions aident au pilotage.
II.3.2.- LES TROIS NIVEAUX D’ABSTRACTION D’UN SI

Revenons maintenant à la notion la plus générale du SI.
Lors de la conception d’un SI, on serra amené à considérer trois niveaux d’études :
 Le niveau conceptuel
 le niveau organisationnel
 Le niveau opérationnel
Le niveau conceptuel consiste à penser le SI sans envisager aucun concept lié
à l’organisation, tant du point de vue des données que de celui de traitement.
Il consiste à se poser la question QUOI ? (c’est‐à‐dire quoi faire ? et avec
quelles données ?).
On ne préjuge en aucune manière du matériel utilisé ni de l’organisation du
travail.
Le niveau organisationnel consiste à intégrer, à analyser les critères liés à
l’organisation (notion de lieux, notion de temps, d’acteurs et donc de postes de travail).
Du point de vue traitement, on se pose des questions : qui ?, ou ? et quand ? et on
n’envisage le partage des taches entre l’homme et la machine. Du point de vue de don‐
nées, on commence à étudier leur organisation, compte tenu de la méthode de stockage
et d’accès, c’est‐à‐dire en gardant l’optique de l’utilisateur sans ignorer les contraintes
du matériel et du logiciel (fichiers logiques).
Le niveau opérationnel consiste à apporter des solutions techniques aux
problèmes. Il consiste à se poser la question comment ?
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 13 ‐
Du niveau de vue des données, on effectue des choix sur les méthodes de
stockage et d’accès (fichiers physiques).
Pour les traitements automatiques, on étudie les découpages en programmes.

D’une manière générale, on envisage les contraintes d’utilisation des ressources phy‐
siques.
NIVEAU TRAITEMENT DONNEES CHOIX

CONCEPTUEL Modèle conceptuel Modèle conceptuel De gestion
ORGANISATIONNEL Modèle organisa‐ Modèle logique D’organisation
tionnel
OPERATIONNEL Modèle opération‐ Modèle physique Techniques
nel
II.3.3.‐ Cycle d'abstraction de conception des S.I.
La conception du système d'information se fait par étapes, afin

d'aboutir à un système d'information fonctionnel reflétant une
réalité physique. Il s'agit donc de valider une à une chacune
des étapes en prenant en compte les résultats de la phase pré-
cédente. D'autre part, les données étant séparées des traite-
ments, il faut vérifier la concordance entre données et traite-
ment afin de vérifier que toutes les données nécessaires aux
traitements sont présentes et qu'il n'y a pas de données super-
flues.
Cette succession d'étapes est appelée cycle d'abstraction pour

la conception des systèmes d'information:
L'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et
le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à
prendre en compte.
Le modèle organisationnel consiste à définir le MLD (Modèle logique des données) qui
représente un choix logiciel pour le système d'information et le MOT (Modèle organisa‐
tionnel des traitements) décrivant les contraintes dues à l'environnement (organisa‐
tionnel, spatial et temporel).
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 14 ‐
Enfin, le modèle physique reflète un choix matériel pour le système d'information.
Niveau Statique (données) Dynamique (traite‐

ments)
Conceptuel MCD MCT Indépendant du sys‐
tème:
QUOI ?
Organisationnel MLD MOT Choix du SGBD:
ou logique (OU ?) (QUI ? QUAND ?) QUI ? QUAND ? OU ?

Opérationnel MPD MOPT Haute connaissance du
SGBD: COMMENT ?
ou physique
II.3.4.‐ Système d’Information et Système Informatique
Il ne faut toutefois pas confondre un système d'information avec un système informa‐

tique. En effet, les systèmes d'information ne sont pas toujours totalement informatisés
et existaient déjà avant l'arrivée des nouvelles technologies de l'information et des
communications dont l'informatique fait partie intégrante.
Parmi les informations qui appartiennent au système d’information, certaines doivent

ou peuvent faire l’objet d’un traitement automatisé grâce aux outils informatiques. Pour
assurer la cohérence du système d’information, la méthode Merise propose une dé‐
marche d’informatisation comportant les étapes suivantes :
- le schéma directeur : dont le rôle est de définir, de manière globale, la politique

d’organisation et d’automatisation du système d’information. Pour ce faire, il est nécessaire de
répertorier l’ensemble des applications informatiques existantes à modifier et à développer.
Pour rendre contrôlable et modulable ce développement, il est nécessaire de découper le sys‐
tème d’information en sous‐ensembles homogènes et relativement indépendant. Ces sous‐
ensembles sont appelés domaines. Par exemple, on peut trouver le domaine « Approvisionne‐
ment », le domaine « Personnel ». Les résultats attendus à la fin de cette étape sont une définition
précise des domaines, une planification du développement de chaque domaine et un plan détail‐
lé, année par année, des applications qui doivent être réalisées.
- l’étude préalable par domaine: qui doit aboutir à une présentation générale du futur
système de gestion (modèles des données et des traitements) en indiquant les principales nova‐
tions par rapport au système actuel, les moyens matériels à mettre en œuvre, les bilans coût –
avantage. Cette étude est réalisée en 4 phases :
 une phase de recueil qui a pour objectif d’analyser l’existant afin de cerner les dys‐
fonctionnements et les obsolescences les plus frappantes du système actuel.
 une phase de conception qui a pour objectif de formaliser et hiérarchiser les orien‐
tations nouvelles en fonction des critiques formulées sur le système actuel et d’autre
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 15 ‐
part des politiques et des objectifs de la direction générale. Cela revient à modéliser
le futur système avec une vue pertinente de l'ensemble.
 une phase d’organisation dont l’objectif est de définir le système futur au niveau
organisationnel: qui fait quoi ?
 une phase d’appréciation dont le rôle est d’établir les coûts et les délais des solu‐
tions définies ainsi que d’organiser la mise en œuvre de la réalisation. A cet effet un
découpage en projets est effectué.
- l’étude détaillée par projet qui consiste d’une part à affiner les solutions conçues lors
de l’étude préalable et d’autre part à rédiger, pour chaque procédure à mettre en œuvre, un
dossier de spécifications détaillé décrivant les supports (maquettes d’états ou d’écran) ainsi que
les algorithmes associés aux règles de gestion… A l’issue de cette étude, il est possible de définir
le cahier des charges utilisateurs qui constitue la base de l’engagement que prend le concepteur
vis à vis des utilisateurs. Le fonctionnement détaillé du futur système, du point de vue de
l’utilisateur, y est entièrement spécifié.
- la réalisation dont l’objectif est l’obtention des programmes fonctionnant sur un jeu
d’essais approuvés par les utilisateurs.
- la mise en œuvre qui se traduit par un changement de responsabilité : l’équipe de réa‐
lisation va en effet transférer la responsabilité du produit à l’utilisateur. Cette étape intègre en
particulier la formation des utilisateurs. Après une période d’exploitation de quelques mois, la
recette définitive de l’application est prononcée.
- la maintenance qui consiste à faire évoluer les applications en fonction des besoins
des utilisateurs, de l’environnement et des progrès technologiques.
Le schéma suivant, extrait de l’ouvrage « La méthode Merise » reprend les étapes décrites ci‐
dessus.
Globalement Schéma directeur
Par domaine
Etude préalable
Par projet Etude détaillée
Par application
Réalisation et mise en œuvres
Cette démarche lourde et parfois complexe est adaptée à l’automatisation de « gros

systèmes d’information ». Pour des informatisations plus modestes, elle peut être perçue
comme un carcan, et il convient donc de l’adapter afin de retenir uniquement les con‐
cepts et/ou les étapes appropriées aux besoins.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 16 ‐
CHAPITRE III : LE MODELE CONCEPTUEL DE COMMUNICATION (MCC)

III.1.- Notion
 Le modèle de communication est un dessin qui représente les flux d'information (messages) ou non
informationnels échangés entre les intervenants internes de l'entreprise et les intervenants externes.
 Le modèle conceptuel de communication MCC représente les échanges de messages entre intervenants.
Les messages décrits sont conceptuels et indépendants de l'organisation.
 Le Modèle Conceptuel de Communication (MCC) représente les systèmes fonctionnels externes et
internes à l’entreprise. A chaque fonction correspond un objectif de l’entreprise. Les échanges
d’informations entre ces fonctions sont répertoriées et les informations recensées.
 Le modèle conceptuel de communication représente les échanges de flux de produits, d'énergie, de
personne, de valeur ou d'information entre systèmes. Ces systèmes fonctionnels appelés intervenants
sont,
o soit externes à l'entreprise (partenaires),
o soit internes (domaine, sous-domaine). Un domaine de l'entreprise a un système d'information
propre à tous ses sous-domaines.
a) Caractéristiques du MCC :
 Ce modèle se contente de décrire les flux et non de les ordonner.
 Les opérations internes aux acteurs ne sont pas décrites : on utilise le principe de la «boîte
noire». Par exemple, on n’explique pas comment le service facturation effectue la facture.
 Ce qui se passe entre partenaire extérieur est ignoré.
 Un acteur externe peut être un acteur interne à l’entreprise.
b) Intérêts du MCC
 Il permet de décrire les bornes du système à étudier. Le modèle permet en effet de bien définir
les acteurs internes au système. C’est particulièrement utile lorsque l’organisation est mal
connue. Il permet de faire la part entre ce qui relève du projet (domaine) et ce qui n’en relève
pas (extérieur).
 Il permet de définir une liste d’événements. En effet, si on considère que les flux de données
entrant sont des événements qui conduisent le système d’information à effectuer des actions,
le modèle nous fournit la liste exhaustive de tout ce qui doit déclencher une action sur le
système.
Quelques concepts
Acteur : C’est une entité organisationnelle identifiable par les missions qu’elle remplit dans le cadre du
champ d’étude défini et capable d’échanger des informations avec les autres acteurs.
 Un acteur qui se trouve dans le champ d’étude est un acteur interne.
 Un acteur qui se trouve hors du champ de l’étude est un acteur externe. On parle aussi de partenaire.
Intervenant : L'entreprise est considérée comme un système. L'extérieur, avec qui l'entreprise
effectue ses échanges est aussi perçu comme un ensemble de systèmes. L'entreprise est découpée en
systèmes fonctionnels ou conceptuels. Systèmes externes et internes sont appelés intervenants. Du général au
particulier et décomposition en systèmes. Les INTERVENANTS sont soit EXTERNES (PARTENAIRES), soit
INTERNES (DOMAINES) à l'entreprise.
Un partenaire est un intervenant extérieur à l'entreprise. Il peut être perçu de manière

FONCTIONNELLE et décrit par un verbe : client (qui paye), fournisseur (qui...), courtier (qui sert
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 17 ‐
d'intermédiaire), associé (qui partage les risques ou les profits) ou PHYSIQUE, société, Banque, personne
morale, personne physique, Etat. La perception fonctionnelle est préférable à la perception physique : ne voir
que le payeur dans le client, ce qui n'empêche pas d'avoir tous les égards pour sa personne. Un partenaire
physique est perçu sous plusieurs vues fonctionnelles : si la société “SNEL” est à la fois fournisseur et cliente
d'une même entreprise, elle sera vue "fonctionnellement" de cette entreprise de deux manières différentes,
fournisseur (d'énergie) et client (payeur).
Domaine : La notion de domaine au sens de “domaine de gestion” correspond à une division du cas
que l’on traite en sous-ensembles cohérents (domaine financier et comptable, domaine commercial, domaine
gestion du personnel, ...).
Ils sont l'application du troisième principe de systémique : l'existence de systèmes d'information

homogènes. Un découpage trop fin de l'entreprise entraînerait une perte de cohérence de la fonction. Un
niveau de ce découpage est identifié, représentant un "tout homogène". Un domaine est un système de
l'entreprise qui a la caractéristique d'avoir une mémoire, un système d'information. Le système d'information
sera construit par domaine. L'entreprise est décomposée en domaines décomposés en sous-domaines, somme
de fonctions élémentaires. Exemple : l'entreprise est entourée des systèmes tels que Client, Etat... les
partenaires. Elle est découpée en domaines : vendre, produire, assurer la vie sociale, qui dépendent de son
activité. Ces domaines sont décomposés en systèmes appelés sous-domaines. "Produire" peut être découpé en
"Maintenir", "Assurer l'approvisionnement des chaînes de production"...
Un sous-domaine est fonctionnel, joue un rôle. Si la vue est physique et le nom donné à un sous-domaine
un signe d'organisation (back office ou gestion administrative, front office ou négociateurs, piloter ou chef), il
faut en dégager la vue fonctionnelle. Un verbe peut définir un domaine ou un sous-domaine. Il représente une
fonction, un nom représente plus une entité physique ou morale (organisation, personne). Exemples de
domaines et de verbes associés : Trésorerie (optimiser les flux financiers), Ventes (vendre, connaître les souhaits
des clients), Comptabilité générale (se conformer à la législation, assurer la sortie des documents comptables
dans les délais impartis), Pilotage (décider et suivre les budgets, décider et suivre la planification). Toutes les
définitions sont sujettes à remaniement suivant le contexte. A chaque domaine ou sous-domaine, des objectifs
ou des critères d'appréciation du résultat peuvent être définis : trésorerie, comparaison avec un taux standard
du marché monétaire ; ventes, nombre de clients conservés ou nouveaux, chiffre d'affaires ; comptabilité
générale, observations du commissaire aux comptes ou délai de remise des documents. Dans le cas de petits
services où les mêmes personnes effectuent plusieurs fonctions, cette étape de définition des sous-domaines
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 18 ‐
doit être limitée dans le temps. En général, il existe plus de fonctions que de personnes et l'utilisateur a beaucoup
de peine à s'affranchir de l'organisation. La définition des différentes fonctions est alors effectuée par rapport à
la définition des postes de travail actuels, portant préjudice à une définition correcte des fonctions
Pour identifier les domaines, deux approches sont possibles :
 soit ne voir directement que les fonctions majeures qui répondent à la question pourquoi ?
 soit, si la première démarche n'aboutit pas à un accord général, énumérer des fonctions élémentaires en
réunion de "brain storming" et les regrouper en sous-domaines, puis en domaines. Pour cela, répondre
toujours à la question pourquoi ? Pourquoi gérer des stocks, pourquoi tenir une comptabilité, pourquoi
enregistrer une commande ? Ainsi sousdomaines et domaines seront découverts. Exemple : soit les fonctions
analyser la production, produire, gérer les stocks, maintenir, gérer les pièces détachées, suivre les pannes et
gérer les reparations.
Plusieurs découpages... Nous allons recomposer ces fonctions en les réunissant en ensembles ou systèmes
fonctionnels en posant la question pourquoi ? L'exercice pourrait s'intituler "Manger pour vivre ou vivre pour
manger ?" La règle à appliquer est : lorsque ceci explique cela, mettre cela dans le cercle de ceci.
L'entreprise est donc découpée en domaines, sous-domaines et fonctions élémentaires afin de bien cerner le
domaine à automatiser.
Flux : C’est la représentation de l’échange des informations entre deux acteurs, ou entre une activité
et un partenaire extérieur à l’entreprise.
Un flux est caractérisé par :
 Son nom (commande, facture, contrat de travail …)
 La liste des données qui le compose ( n°,date)
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 19 ‐
Seuls les flux acteurs internes / acteurs externes et acteurs internes /acteurs internes sont matérialisés. En effet,
les flux acteurs externes/acteurs externes sont hors du champs d’étude donc non étudiés.De plus, les flux
internes à même acteur ne sont pas formalisés car les acteurs sont vus de l’extérieur.
Les intervenants définis, intéressons-nous aux échanges entre ceux-ci. Suivant la systémique, ces
échanges sont plus importants que les intervenants. Des flux sont échangés entre des émetteurs et des
récepteurs, les intervenants. Ils peuvent être réels (produit, énergie, argent) ou d'information, les messages. Le
modèle de communication représente tous les flux et toute l'activité de l'entreprise. Un dessin ne représentant
que les messages est un sousensemble du modèle de communication. Seul, ce sous-ensemble est détaillé par la
suite. En effet, non seulement les flux physiques sont suivis par des messages porteurs d'informations, mais
encore, l'informatique ne traite que des informations.
Message : Un flux est appelé message quand il est ensemble d'informations. Le modèle conceptuel de
communication MCC représente les échanges de messages entre intervenants. Les messages décrits sont
conceptuels et indépendants de l'organisation.
Projet : Le terme de projet est employé pour définir le travail spécifiquement informatique lié à
l’informatisation d’un domaine.
Processus/Application : Dans un même domaine et particulièrement lors d’un cas de champs très vaste,
on divise ce domaine en “ Processus ” ou “ Applications ” (Par exemple le domaine commercial peut être
subdivisé dans les processus suivant : suivi des représentants, prise de commande, suivi des commandes).
III.2.- Représentation de l’activité
Le modèle de communication formalise les échanges d'informations entre systèmes fonctionnels et

identifie les systèmes "à mémoire".
L'objectif est de représenter l'activité de l'entreprise et de formaliser son "système d'information"
indépendamment de son organisation.
Le compte rendu de cette étude est matérialisé sous la forme de dessins normalisés, de modèles
complétés par un dossier explicatif. Le but de ce chapitre est d'expliquer comment décrire l'entreprise
concernée en respectant les normes de chaque modèle.
Une approche théorique est faite avec l'étude des systèmes, la systémique. Celle-ci repose sur les principes
suivants :
1 - Une approche du général au particulier. Tout système se décompose en systèmes.
2 - La méthode s'attache à identifier les échanges entre systèmes.
3 - La systémique amène à décomposer l'entreprise en systèmes homogènes d'information appelés
domaines.
III.3.- Etapes de Construction du MCC.
L'entreprise est considérée comme un système. L'extérieur, avec qui l'entreprise effectue ses échanges est aussi
perçu comme un ensemble de systèmes. L'entreprise est découpée en systèmes fonctionnels ou conceptuels.
Systèmes externes et internes sont appelés intervenants.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 20 ‐
La construction d'un graphe des flux réels (physiques ou financiers) est conseillée. Bien différencier les flux
physiques et d'informations : un catalogue imprimé, vu de l'imprimeur, est un flux physique. Il s'apparente à un
produit. Le même catalogue, envoyé au client, est perçu comme un message. Exemple : produit livré, virement
bancaire... L'entreprise donne le produit à livrer à un livreur qui livre le même produit au client. Les flux
physiques de "produits" sont entre entreprise et livreur et livreur et client. Si le client apporte de l'argent
liquide à sa banque, le flux financier "liquidité" existe entre Client et Banque. Enfin l'entreprise est payée par
un virement, flux financier, de la Banque.
1.- La première étape de ce modèle est d’arriver à isoler le système. Il s’agit donc de définir le système et les
éléments externes avec lesquels il échange des flux d’information. Ces éléments extérieurs sont appelés
acteurs externes (ou partenaires)
Cfr image ci-dessous :
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 21 ‐
2.- La seconde étape consiste à découper l’organisation en entités appelées acteurs internes (ou domaines).
Du général au particulier et décomposition en systems. Lorsque les domaines d'une organisation sont trop
importants, ils peuvent être décomposés eux-mêmes en sous-domaines. Cfr image ci-dessous :
Schéma de principe de l’analyse d’un domaine
Domaine non
étudié
Pré-Analyse du domaine
Domaine et des intersections avec
étudié les autres domaines
Circuits d'informations
Domaine non étudié
et
Documents analysés
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 22 ‐
3.- La dernière étape est l’analyse des flux d’information, c’est-à-dire la définition des processus.
Formalisme
Un acteur est une entité, humaine ou matérielle, intervenant dans le système d’information. Les acteurs se
divisent en deux catégories, internes et externes, selon leur appartenance ou non à l’entreprise.
Il peut être source (producteur) de flux de données ou consommateur (puits) d’un flux.
Les acteurs fonctionnent comme des bornes du système.
Exemple d’acteurs du système d’information d’une bibliothèque :
Code acteur Acteur

A1 Responsable de la Bibliothèque
A2 Le Service de catalogage
A3 Le Fournisseur
A4 Le Service de Comptabilité de la bibliothèque
A5 Les Utilisateurs (Lecteurs)
 Un flux est appelé message quand il est ensemble d'informations. Le modèle conceptuel de
communication MCC représente les échanges de messages entre intervenants. Les messages décrits
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 23 ‐
sont conceptuels et indépendants de l'organisation. Si un document physique est analysé, les questions
sont "quels sont les messages conceptuels de ce document ?", "quels sont les messages qui donneront
lieu à une réaction ou une action de l'entreprise ?" Pourquoi ce message et non qui traite le message ?
ENTREPRISE Réparer Optimiser flux financiers Acheter Filiale Etat des équipements : équipements à
réparer et à remplacer sous un même "DOCUMENT PHYSIQUE"...
Exemple : le document "état des équipements" est envoyé par une filiale en plusieurs exemplaires. Il
correspond à plusieurs messages conceptuels différents selon chaque récepteur. Pour l'un, le message est une
demande de réparation, pour un autre, un flux de trésorerie à prévoir pour payer la réparation et pour un
troisième, une demande d'achat des équipements. Le message organisé ou "physique" comprend trois
messages conceptuels : ENTREPRISE Réparer Optimiser flux financiers Acheter Filiale Demande de réparation
d'équipements Demande de liquidités Demande d'achat d'équipements
...existent plusieurs messages conceptuels.
III.4.- Diagramme de contexte

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:
 l'organisation est représentée par un rectangle
 les acteurs externes sont représentés par des
ellipses en pointillés
 les flux d'information sont représentés par des
flèches dont l'orientation désigne le sens du flux
d'information
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 24 ‐
III.5.- Diagramme conceptuel de flux
Ce diagramme (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. Dans ce diagramme la
représentation standard est la suivante:
 Les acteurs internes sont représentés par des
ellipses,
 Les messages internes sont représentés par des
flèches
Il y a deux façon de formaliser les échanges ( flux) entre les acteurs de chaque domaine d’activité :
a) sous la forme d’un diagramme
b) sous la forme d’une matrice
c) Le diagramme
Acteur Flux Acteur

interne externe
Exemples :
Ordre de livraison
magasin transporteur
Bon de livraison
facture
facturation client
III.6.- LA MATRICE DE FLUX
Les acteurs sont disposés en ligne pour leur rôle d’émetteur, en colonne pour leur rôle de récepteur.
Les flux sont représentés dans l’intersection ligne/colonne.
L’intérêt est de visualiser l’inventaire exhaustif de la combinatoire possible : il facile de vérifier que rien n’a été
oublié.
Exemple :
Vers Magasin Transporteur

Depuis
Magasin Ordre de livraison
Transporteur Bon de livraison
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 25 ‐
La matrice des flux est une représentation matricielle des acteurs et des flux échangés. Les acteurs
forment les lignes et les colonnes du tableau.
En ligne, l’acteur a un rôle d’émetteur de flux tandis qu’en colonnes il a un rôle de destinataire de flux.
Les flux sont indiqués dans les cases du tableau, à l’intersection de la ligne de l’acteur émetteur et de la colonne
de l’acteur destinataire.
La matrice affiche tous les échanges entre les différents acteurs sous forme d’un tableau dans lequel
chaque cellule représente le trafic d’un acteur A vers un acteur B. Le trafic entre des acteurs identiques est
hachuré en noir (de l’acteur A vers l’acteur A) et le trafic entre des acteurs différentes est représenté par une
couleur différente. Plus le trafic est important plus la couleur affichée dans la cellule sera intense.
NB : Les noms des messages peuvent être remplacés par leurs numéros ou codes dans la matrice des flux.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 26 ‐
CHAPITRE IV : LE MODELE CONCEPTUEL DES DONNEES (MCD)
IV.1.‐ FORMALISATION DU MCD
 L'élaboration du modèle conceptuel des données (MCD) qui est une représentation
graphique et structurée des informations mémorisées par un SI. Le MCD est basé sur deux
notions principales : les entités et les associations, d'où sa seconde appellation : le schéma
Entité/Association.
 Le modèle conceptuel des données est une représentation de l’ensemble des données
du domaine, qui ne tient pas compte des aspects techniques et économiques de
mémorisation et d’accès et sans se référer aux conditions d’utilisation par tel ou tel
traitement. Il a pour but d’écrire de façon formelle les données qui seront utilisées par le
système d’information. Préalablement à la construction de ce modèle, il convient de faire
l’inventaire des données dont on élimine les redondances, les synonymes et les polysémies
(Polysèmes).
 Le modèle conceptuel des données (MCD) est une représentation statique du système
d’information de l’entreprise qui met en évidence sa sémantique. Il a pour but 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éhensible. Cet aspect recouvre
les mots qui décrivent le système ainsi que les liens existants entre ces mots. Le
formalisme adopté par la méthode Merise pour réaliser cette description est basé sur les
concepts « entité‐association ».
IV.2.‐ LA CONSTRUCTION DU MCD
IV.2.1.- INTRODUCTION
L'élaboration du MCD passe par les étapes suivantes :

• la mise en place de règles de gestion (si celles-ci ne vous sont pas données) ;
• l'élaboration du dictionnaire des données ;
• la recherche des dépendances fonctionnelles entre ces données ;
• l'élaboration du MCD (création des entités puis des associations puis ajout des cardinalités).
Lors de l’analyse du SI existant, on rassemble des exemplaires de tous les
documents utilisés ainsi que les descriptions de divers fichiers en usage actuellement. C’est la
recueille des informations. On explicite alors clairement les règles de gestion :
- Exemple1 : SI contient essentiellement des propriétés figurant sur les Bons de commandes et
les factures pour une maison de vente des produits ou articles par exemple. Les règles de
gestion pourraient être :
REGLE DE GESTION N° 1 : un client peut passer une ou plusieurs commandes ou aucune commande
REGLE DE GESTION N° 2 : une commande peut concerner un ou plusieurs produits
REGLE DE GESTION N° 3 : une commande est passée à un fournisseur qui n’est pas toujours le même pour un client donné.
Les règles de gestion précisent les contraintes qui doivent être respectées par le modèle.
- Exemple 2 : Dans le MCD d’une école les règles de gestion peuvent être les suivantes :
o RG1 : Tout professeur enseigne en principe au moins une matière, mais certains
d’entre eux peuvent être dispensés d’enseignement en raison de leurs travaux de
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 27 ‐
recherche.
o RG2 : Toute matière est enseignée dans au moins une classe.
o RG3 : Toute classe a au moins trois enseignants.
On établit alors la liste des propriétés à partir des documents et fichiers.

Dans le cas où il s’agit d’un système manuel, il n’existe pas forcement des codifications. On
imagine dans ce cas qu’il y a des codes pour identifier les entités évidentes. Ex : CodeClient
pour CLIENT et CodeFourn pour FOURNISSEUR. On les marque d’une étoile pour indiquer
qu’ils n’existaient pas encore.
IV.2.2.- CONSTITUTION D’UN DICTIONNAIRE DE DONNEES
Le dictionnaire des données est un document qui regroupe toutes les données que vous
aurez à conserver dans votre base (et qui figureront donc dans le MCD).
C'est une étape intermédiaire qui peut avoir son importance, surtout si vous êtes plusieurs à
travailler sur une même base de données, d'un volume conséquent.
Pour chaque donnée, il indique :
 Le code mnémonique : il s'agit d'un libellé désignant une donnée (par exemple «titre_l» pour le titre
d'un livre)
 La désignation (Signification) : il s'agit d'une mention décrivant ce à quoi la donnée corres‐
pond (par exemple «titre du livre»)
 Le type de donnée :
o A ou Alphabétique : lorsque la donnée est uniquement composée de caractères al‐
phabétiques (de 'A' à 'Z' et de 'a' à 'z')
o N ou Numérique : lorsque la donnée est composée uniquement de nombres (entiers ou
réels)
o AN ou Alphanumérique : lorsque la donnée peut être composée à la fois de carac‐ tères
alphabétiques et numériques
o Date : lorsque la donnée est une date (au format AAAA‐MM‐JJ)
o Booléen : Vrai ou Faux
 La taille : elle s'exprime en nombre de caractères ou de chiffres. Dans le cas d'une date au
format AAAA‐JJ‐MM, on compte également le nombre de caractères, soit 10 caractères. Pour ce qui
est du type booléen, nul besoin de préciser la taille (ceci dépend de l'implémentation du SGBDR).
 Et parfois des remarques ou observations complémentaires (par exemple si une donnée est
strictement supérieure à 0, etc).
Exemple d’un dictionnaire de données pour un système d’information de gestion des

commandes :
NOM (de la SIGNIFICATION TYPE LONGEUR NATURE REGLE DE CALCUL OU

propriété) ou A N AN (Taille) INTEGRITE
Code mné- (1) (Remarques ou Observa-
monique tions)
(4)
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 28 ‐
E M
Co SIG
CA SITU
(2) (3)
NOBON N° Bon de commande N 4 E M
DATE Date commande N 6 E M Forme jjmmaa
jj : 01 à 31
mm : 01 à 12
*COCLI Code client ? 2 E SIG A créer
Nomcli Nom client A 30 E SIG
Adree Adresse client AN 60 Co SIG Rue + ville
Rucli Rue client AN 30 E SIG
VILCLI Ville client A 30 E SIG A créer
*COREP Code représentant ? ? E SIG
NOMREP Nom représentant A 30 E SIG
REF Référence produit AN 5 E SIG Une lettre+Trois chiffres
DESIG Désignation A 30 E SIG
QTE Quantité commandée N 3 E M Entier
PU Prix unitaire N 7 E SIG Forme : 9999,99
MONTANT Montant ligne N 8 CA M PU, X Qté
TOTAL Total commande N 8 CA M Somme des montants
(1) A= Alphabétique
N=Numérique
AN=Alphanumérique
(2) E=Elémentaire
Co=Concaténée
CA=Calculée
(3) M=Mouvement
SIG=Signalétique
SITU=Situation
(4) Règle de calcul pour les propriétés calculées ou contraintes d’intégrité de forme
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 29 ‐
IV.2.3.- EPURATION DU DICTIONNAIRE DE DONNEES

 Les données qui figurent dans le MCD (et donc dans le dictionnaire des
données) doivent être, dans la plupart des cas, élémentaires :
o Elles ne doivent pas être calculées : les données calculées doivent être
ob‐ tenues, par le calcul, à partir de données élémentaires qui, elles, sont
con‐ servées en base. Cependant, il existe quelques cas où il s'avère
pertinent
de conserver
o Elles ne doivent pas être composées : les données composées doivent
être obtenues par la concaténation de données élémentaires conservées
en base. Par exemple une adresse est obtenue à partir d'une rue, d'une
ville et d'un code postal : ce sont ces trois dernières données qui sont
con‐ servées et donc qui figureront dans le MCD (et dans le dictionnaire
des données).
o Dans le modèle conceptuel des données figurent toutes les propriétés,
identifiées par un nom, qui présentent un intérêt pour le domaine à
étudier. Ce nom doit être le plus explicite possible : à sa seule lecture
on doit donc pouvoir se faire une idée de ce que représente la
propriété. En outre, l’identification de chaque propriété consiste à
garantir une bijection entre l’ensemble des noms et l’ensemble des
propriétés à gérer.
o On devra donc exclure les synonymes qui correspondent à deux noms
différents pour identifier la même propriété et les polysèmes qui
représentent deux propriétés différentes ayant le même nom. Des
difficultés peuvent apparaitre entre les signifiants et les signifiés. Un
signifié est un objet abstrait ou concret qu’on veut qualifier.Un signifiant
est un mot employé pour représenter ce signifié. Il faut éviter les cas sui‐
vants dans votre DD :
 Synonymes : deux signifiants pour un même

signifié : Ex : - N° CLIENT et CODE CLIENT
‐ JOUER et FOOTBALLEUR
- TVA et TAXE
 Poly sèmes : un signifiant pour deux signifiés différents.
Ex : - Nom pour Nom client et pour nom du fournisseur
-Quantité pour quantité commandé et quantité livrée.
Remarque :
 Dans le DD (dictionnaire de données), un nom sera donné une fois pour toute à
chaque type de donnée.
 Lorsque l'on n'effectue jamais de calcul sur une donnée numérique, celle‐ci doit
être de type AN (c'est le cas par exemple pour un numéro de téléphone)
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 30 ‐
IV.3‐ CONCEPTS DE BASE
1.- ENTITE
- Une entité ou individu est la représentation dans le SI d’un objet matériel ou
immaté‐ riel de l’univers extérieur (UE).
- L’individu doit :
•  être d’intérêt pour l’entreprise;
•  avoir une existence propre. Il est concevable sans hypothèse sur l’existence
d’autres éléments perçus dans le champ d’étude;
•  être doté d’un ensemble de propriétés.
- Les entités sont des regroupements d’informations. Les informations contenues dans les
entités (informations que l'on appelle "attributs") doivent être des informations va‐
riables, mais communes à une même classe d'objets.
- Une entité est un regroupement bien pensé, donc sensé, de plusieurs propriétés. Par
exemple, on considère l’entité ARTICLE qui regroupe les propriétés : Référence, Désignation
et PrixUnitaire.
Les classes d'entités sont représentées par un rectangle. Ce rectangle est séparé en deux champs:
 le champ du haut contient le libellé. Ce libellé est généralement une

abréviation pour une raison de simplification de l'écriture. Il s'agit
par contre de vérifier qu'à chaque classe d'entité correspond un et
un seul libellé, et réciproquement.
 le champ du bas contient la liste des propriétés de la classe d'entité.
Le formalisme d'une entité est le suivant :
Ainsi, si on schématise par exemple l’entité « Auteur » on aura :
On appelle classe d'entité un ensemble composé d'entités de même type, c'est‐à‐dire dont la définition est la
même. Le classement des entités au sein d'une classe s'appelle classification (ou abstraction). Une entité est
une instanciation de la classe. Chaque entité est composée de propriétés, données élémentaires permettant de
la décrire.
Prenons par exemple une Pajero, une Prado et une Land Cruiser. Il s'agit de 3 entités faisant partie
d'une classe d'entité que l'on pourrait appeler « voiture ». La Prado est donc une instanciation
(élément) de la classe voiture. Chaque entité peut posséder les propriétés couleur, année et modèle.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 31 ‐
CLASSIFICATION DES ENTITES
a).‐ Entités permanentes
Les entités permanentes sont des entités que l’on conserve en permanence
dans la base d’informations mais qu’on peut mettre à jour à tout moment.
Elles correspondent à la structure mais ne représentent pas des faits.
Exemple : Client est une entité permanente car, on conserve les propriétés
d’un client en permanence tout en ayant la possibilité de les modifier à tout moment.
Les propriétés d’une Entité permanente peuvent changer mais l’entité est stable.
Les propriétés d’une Entité permanente peuvent être de deux types :
 Les propriétés signalétiques

 Les propriétés de situation
Les propriétés signalétiques correspondent à la « fiche d’Etat civil » de

l’entité et à sa description.
Exemples :
Nom, rue, ville,… sont des propriétés signalétiques de l’entité client.
Désignation, prix,… sont des propriétés signalétiques de l’entité produit.
Intitulé est une propriété signalétique de l’entité compte.
Les propriétés de situation expriment dans quelle situation se trouve

l’entité permanente à un instant donné, situation qui représente en général un cumul
ou une position.
Exemple :
ENTITE PERMANENTE PROPRIETES DE SITUATION

CLIENT C.A du mois M
CA du mois M‐1
PRODUIT Stock au 15 du mois
CA du mois M
COMPTE CUMUL débit ou crédit au jour J
CUMUL débit ou crédit au jour J‐1
Solde débiteur ou créditeur à J
On pourra distinguer la situation actuelle d’une entité représentée par des

propriétés de situation à l’instant présent, et les situations en historique,
représentées par des propriétés des situations de l’entité à des instants passés.
Exemple :
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 32 ‐
Pour l’entité produit, la propriété CAM (chiffre d’affaires au mois actuel

M) représente la situation actuelle si on fait la mise à jour du CA tous les mois. Les
proprié‐ tés CAM‐1, CAM‐2,… représentent l’historique des situations du produit.
La situation à une date T peut être mémorisée ou calculée à partir d’une si‐
tuation antérieure et des mouvements concernant cette entité depuis cette situation
an‐ térieure.
Exemple :
Le solde d’un compte au 04 mars peut se calculer à partir du dernier

solde mémorisé (par exemple au 28 février ; date de dernier MAJ des comptes) et
des écri‐ tures (mouvements) enregistrées depuis cette dernière MAJ (depuis le 28
février).
On a donc deux méthodes pour déterminer la situation d’une

entité à l’instant T :
 Calculer une fois pour toute cette situation et la mémoriser

 Rechercher à chaque fois cette situation à partir de la dernière situation mé‐
morisée et des mouvements enregistrés depuis. Cette méthode n’est envisa‐
geable qu’avec un ordinateur ayant assez de mémoire externe pour
conserver tous les mouvements au calcul.
b).‐ Entités de type Mouvement
Il s’agit des mouvements mémorisés. Ces entités sont des images des événe‐
ments qui ont porté sur ces mouvements. Elles sont liées à la conjoncture (elles repré‐
sentent des faits conjoncturels).
Une entité de type mouvement est le souvenir d’un événement, dans le SI.
Exemple : l’entité commande (N° de commande, date) mémorisée dans le système est
issue de l’événement passation de commandes. Il existe un moment où on ne peut plus
mettre à jour une entité mouvement (on ne peut plus modifier une commande une fois
qu’elle est passée)
2.- LES PROPRIETES (Rubrique ou Attribut)

 La propriété est une information élémentaire, c’est‐à‐dire non déductible en
d’autres informations, qui présentent un intérêt pour le domaine étudié. Par
exemple, si l’on considère le domaine de gestion des commandes d’une société de
vente par correspondance, les données : « référence article », « désignation ar‐ ticle
», « prix unitaire HT », « taux de TVA » sont des propriétés pertinentes pour ce
domaine. La donnée « prix unitaire TTC » n’est, d’après la définition, pas une pro‐
priété car ses valeurs peuvent être retrouvées à partir des propriétés «prix unitaire
HT » et « taux de TVA ». (HT=hors taxes ; TTC=toutes taxes comprises).
 Chaque valeur prise par une propriété est appelée occurrence. Des occurrences de la ru‐
brique « désignation article » sont par exemple : « râteau », « bêche », « scie », …
 Une propriété est dite simple ou encore atomique si chacune des valeurs qu’elle
regroupe n’est pas décomposable. La propriété « Adresse », dont des exemples
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 33 ‐
d’occurrences sont donnés ci‐dessous, n’est pas élémentaire car elle peut être dé‐
composée en trois propriétés : la rue, le code postal et la ville.
Adresse
310, rue de la gare 16000 Angoulême
45, avenue de la Plage 17000 La Rochelle
La décomposition d’une propriété en propriétés plus simples ne doit pas être sys‐
tématique et doit surtout tenir compte de son exploitation dans le système. Si cette
exploitation est toujours globale, l’atomisation n’est pas nécessaire, dans les autres
cas il faut procéder à l’isolement de chacune des composantes de la propriété et
donc introduire de nouvelles propriétés.
Propriété Occurrences
Prénom J‐Philippe, Laurent, Jean
 Une propriété paramètre est une propriété qui, à un instant donné, contient une seule
valeur. Un des exemples les plus classiques pour illustrer les paramètres est la rubrique
« ValeurEuro ».
CARACTERISTIQUES DES PROPRIETES :
 Une propriété peut être élémentaire.
L’événement « entrées en stock » est porteur des propriétés : référence des

produits entrés en stock, quantité en stock,…
 Une propriété peut être concaténée si elle est décomposable en d’autres pro‐
priétés.
Exemple :
Adresse peut‐être une rubrique concaténée décomposable en rue, code pos‐
tal et ville.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 34 ‐
 Une propriété peut être mémorisée dans la base d’information du SI, c’est‐à‐
dire, stockée sur un support destiné à la conserver.
Exemple : le nom du client peut être mémorisé sur une fiche en carton.
Certaines propriétés peuvent ne pas être mémorisées mais se déduire de propriétés
mémorisées pour l’obtention d’un résultat. Ce sont des Propriétés Calculées.
Exemple : le solde d’un compte peut se calculer à partir de données mémori‐
sées : cumul débit et cumul crédit par la différence entre ces deux données.
Exemple : PT=Qté*PU
 En fin, une propriété peut être portée par un événement sans être mémorisée
par le système.
Exemple : l’événement “demande de consultation du stock’’ porte la réfé‐

rence du produit à consulter. Cette propriété peut ne pas être mémorisée si l’on ne désire
pas conserver le souvenir de consultations effectuées. Bien entendu rien n’empêche de
mémoriser les propriétés liées à des événe‐ ments si l’on souhaite conserver la trace de
ces événements (on peut très bien vouloir noter toutes les demandes de consultation du
stock).
On distingue trois sortes de propriétés :

 LES CODES
 LES LIBELLES
 LES MONTANTS
Les CODES sont des informations synthétiques représentatives d’objets ma‐

tériels, immatériels de l’UE, selon une loi de correspondance rigoureuse (le système de
codification) qui à tout objet existant associe une valeur et une seule du code et telle qu’à
deux objets différents corresponde deux valeurs distinctes de ce code.
Exemple : tel client se verra attribué le code A01 et aucun autre code. Aucun
autre client ne pourra avoir le code A01.
Un code pourra servir d’identifiant d’une entité, c’est‐à‐dire la propriété carac‐

téristique de cette entité (ou clé d’identification si l’entité en question représente l’objet
correspondant au code).
Exemple : Le numéro de BC est un code qui représente l’objet commande de l’UE. Il

pourra servir d’identifiant (de clé) à l’entité Bon de commande.
Les LIBELLES sont des données alphanumériques, quantitatives, des simples

chaînes de caractères qui pourront simplement être restituées par le système ou sur
lesquelles on pourra faire de tris ou comparaisons mais qui ne pourront participer à au‐
cun calcul.
Ex : Nom du client
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 35 ‐
Les MONTANTS sont des données numériques, quantitatives, qui pourront

participer à des calculs.
Ex : prix, poids, taille, date,…

Enfin, le principe de non‐redondance impose que chaque propriété,
correctement identifiée, n’apparaisse qu’une seule fois dans le modèle.
Nous venons de voir que le concept propriété correspond à la notion de rubrique,
attribut d’une entité ou d’une relation. Il peut aussi correspondre à la notion de
données (rubriques) portées par un événement.
3.- Identifiant :
- Parmi l’ensemble des propriétés caractérisant l’individu, on sélectionnera une

propriété telle que, à chaque valeur de cette propriété correspondante une et une seule
occurrence de l’individu. Cette donnée est l’identifiant de l’individu. Dans certains cas ,
l’identifiant peut être constitué par le regroupement de plusieurs propriétés. Chaque
entité est unique et est décrite par un ensemble de propriétés encore appelées attributs ou
caractéristiques. Une des propriétés de l'entité est l'identifiant.
- Cette propriété doit posséder des occurrences uniques et doit être source des dépendances
fonctionnelles avec toutes les autres propriétés de l'entité. Bien souvent, on utilise une
donnée de type entier qui s'incrémente pour chaque occurrence, ou encore un code unique
spécifique du contexte.
4.- CARDINALITES
La notion de cardinalité minimum/maximum permet d’exprimer la fonction‐
nalité et la totalité/partialité d’une relation. C’est grâce à la cardinalité que l’on exprime
le MCD.
Cardinalité minimum :
La cardinalité minimum d’une relation est le nombre minimum des fois où

chaque occurrence d’une entité‐type participe à la relation.
 La cardinalité minimum 0 correspond à une relation PARTIELLE.

 La cardinalité minimum 1 signifie qu’une occurrence d’entité‐type ne peut
exister sans participer à une occurrence de la relation.
 La cardinalité minimum n implique que toute occurrence d’entité‐type parti‐

cipe obligatoirement à n occurrences de la relation. Les cardinalités mini‐
mum non nulles correspondent à des relations TOTALES.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 36 ‐
Cardinalité maximum :
La cardinalité maximum d’une relation est le nombre maximum des fois où

chaque occurrence d’entité‐type peut participer à une occurrence de la relation.
 La cardinalité maximum 1 signifie que toute occurrence de l’entité‐type ne

peut participer qu’à une occurrence de relation au plus.
 La cardinalité maximum n signifie qu’une occurrence de l’entité‐type peut
être impliquée dans un maximum de n occurrences de la relation.
REPRESENTATION GRAPHIQUE :
Exemple 1 : HOMME Départ Inverse

EST FILS DE FEMME
1,1 0,n
Card min, card max card min, card max
La relation est : un homme est fils d’au moins une femme (1) et d’au plus une femme ;
c’est‐à‐dire une femme peut ne pas avoir d’enfant (0 enfant) ou au contraire avoir plu‐
sieurs enfants (n enfants)
Enfant Mère
1 a
2 b
3 c
1,1
On ne peut pas avoir un homme qui n’est pas de fils d’une femme. Est‐ce qu’une femme
peut ne pas mère d’un enfant ? Oui ; c’est 0 ; mais elle peut être mère de plusieurs en‐
fants.
Ex : exemple 2
MATIERE
(1.1)
PROFESSEUR ENSEIGNE
(1.n)
CLASSE
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 37 ‐
Prof Matière
Enseigne
Prof 1 Anglais
Prof 2 Inform
Prof 3 Math
Géo
Explication :
Un prof fait au moins un enseignement, il peut en faire plusieurs
P1 C1
Une matière peut ne pas être enseignée ; si elle l’est, elle peut être plusieurs fois.
P2 C2
P3 C3 Une classe a au moins un enseignement et peut en avoir plusieurs.
P4 C4
Les cardinalités les plus répandues sont les suivantes : 0,N ; 1,N ; 0,1 ; 1,1 . On peut tou‐
tefois tomber sur des règles de gestion imposant des cardinalités avec des valeurs parti‐
culières, mais cela reste assez exceptionnel et la présence de ces cardinalités imposera
l'implantation des traitements supplémentaires.
L'identifiant d'une association ayant des cardinalités 0,N/1,N de part et d'autre, est ob‐
tenu par la concaténation des entités qui participent à l'association. Imaginons l'associa‐
tion suivante :
Ici un auteur rédige au moins un ou plusieurs livres et pour chaque livre, on connaît le
nombre de chapitres rédigés par l'auteur (on connaît aussi le nombre total de chapitres
pour chaque livre).
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 38 ‐
L'association «rédiger» peut donc être identifiée par la concaténation des propriétés
id_a et id_l. Ainsi, le couple id_a, id_l doit être unique pour chaque occurrence de l'asso‐
ciation. On
On dit que nb_chapitres (nombre de chapitres rédigés par un auteur, pour un livre) est
une donnée portée par l'association «rédiger». Cette association est donc une associa‐
tion porteuse de données.
Pour une association ayant au moins une cardinalité de type 0,1 ou 1,1 considérons dans
un premier temps que cette dernière ne peut être porteuse de données et qu'elle est
identifiée par l'identifiant de l'entité porteuse de la cardinalité 0,1 ou 1,1.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 39 ‐
IV.4.- TYPE ET OCCURRENCE

Un type est un ensemble d’éléments ayant les mêmes caractéristiques.
Ex : les étudiants de l’ISC faisant l’informatique à partir de la deuxième année.
Une occurrence d’un type est un élément particulier d’un type appartenant à cet
ensemble. Ex : l’étudiant NDUMVIRIYE est l’occurrence de l’ensemble des étudiants de l’ISC fai‐
sant l’informatique.
Entité‐type : un type d’entité ou entité type est une classe d’entités particulières
ayant des propriétés analogues.
Occurrence d’entité‐type : une occurrence d’entité type est une entité particulière
appartenant à ce type.
Ex : En considérant que Client est une entité type, alors
Le Client PASCAL et le Client ROGER sont des occurrences de cette entité –type
D’après la définition d’une entité, on sait que la connaissance d’une valeur de la rubrique identifiante
détermine la connaissance des valeurs des autres rubriques de l’entité. L’ensemble de ces valeurs est
appelé occurrence d’entité. Le tableau suivant présente des exemples d’occurrences de l’entité AR‐
TICLE.
ARTICL 134ER 354TY

E
Rateau Bêche
Référence
452GT
Désignation
Scie
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 40 ‐
Une propriété particulière d’une entité l’identifiant (ou clé d’identification) per‐
met de distinguer cette entité particulière de tout autre entité du même type.
L’identifiant est une propriété qui caractérise chaque occurrence de l’entité‐type.
Identifiant : propriété qui permet de distinguer de l’entité‐type les occurrences d’une

manière unique.
Exemple : le code client est l’identifiant (la clé) de l’entité‐type client.
 Les clients de code A01 et A02 constituent des occurrences distinctes des clients.
 Le N° de l’étudiant qui a été donné au début du cours constitue l’identifiant de

l’entité‐type Etudiant.
Relation‐type est une relation (association) entre plusieurs entités types.
La collection est la liste des entités‐types qui participent à cette relation.
Chaque ensemble d’occurrences des entités‐types composants la relation‐type.

Exemples :
1. Collection de la relation « donne cours » en classe ; la collection est ensei‐

gnant, classe
2. AFFECTE A est une relation‐type définie sur la collection des entités types
personne et service.
Les occurrences PAUL de l’entité PERSONNE et service COMPTABLE de ser‐

vice peuvent définir une occurrence de la relation‐type si PAUL travaille dans le service
comptable. Jean « est marié » à Denise exprime que les occurrences JEAN et DENISE de
l’entité PERSONNE vérifie la relation‐type « EST MARIE A » et définit une occurrence de
cette relation. La relation type « EST MARIE A » est définit sur la collection PERSONNE et
chaque occurrence de cette relation met en jeu deux occurrences de PERSONNE (entité)
Propriétés‐type : une propriété type est une classe des propriétés sem‐
blables.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 41 ‐
Une occurrence d’une propriété‐type est une valeur prise par cette pro‐
priété. Ex : nom client est une propriété‐type de l’entité‐type CLIENT et représente la
classe des noms de tous les clients. Les occurrences PIERRE et ROGER de cette
proprié‐ té‐type sont des valeurs prises par cette propriété pour deux clients
particuliers (2 oc‐ currencs de l’entité‐type). KAVIRA=occurrence de la propriété‐type
“Etudiant’’.
Une propriété type peut être de type Code, Libellé ou Montant ; elle peut être
élémentaire ou concaténée, mémorisée ou calculée. Elle est (propriété) caractérisée par
une certaine structure :
LA CLASSE : numérique (chiffres).
Alphabétique : lettre ou espaces
ALPHA NUMERIQUE : tous les caractères
Pour les propriétés servant d’identifiant, la valeur d’un identifiant identifie de

manière unique une entité.
IV.5.- NOTION DE RELATION (ASSOCIATION)

a).‐ Une relation est la prise en charge par le SI du fait qu’il existe une association entre
les objets de l’UE et prendra la forme d’une association entre les entités correspon‐
dantes.
Exemple 1: « Pierre est marié à Françoise » exprimé par la relation « est marié », une
association entre les entités Pierre et Françoise.
Exemple 2 :
Entre l’entité Bon de commande (N° du BC, date) et l’entité produit (réfé‐
rence, désignation, PU) peut exister la relation concerne exprimant l’association qui
existe entre l’objet commande et certains objets de type produit.
Par exemple, la commande N° 123 peut concerner les produits X01 et X25.
A une relation peuvent également être attachées des propriétés, exactement comme
pour les entités.
Exemple : la relation concerne peut être porteuse de la propriété quantité

exprimant pour chaque produit commandé la quantité commandée.
BON DE COMMANDE (N° BC, date)
CONCERNE (quantité)
PRODUIT (référence, désignation, prix)
Par exemple : le BC N° 123 date du 12/11/2011 concerne pour une quantité de deux
unités ; les produits X01, chemises, 30$. Les deux entités BC et PRODUIT sont reliées par
la relation « concerne » si le produit est commandé sur le BC pour une certaine quanti‐
té.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 42 ‐
b).‐ CARACTERISTIQUES D’UNE RELATION ‐ TYPE
La collection d’une relation‐type est la liste des entités‐types sur laquelle la

relation est définie. Ex : la relation AFFECTE A est définie sur la collection : (SALARIE,
SERVICE).
Dimension : la dimension d’une relation type est le nombre d’occurrences

d’entités concernées par une occurrence de la relation‐type. Elle est supérieure ou égale
au nombre d’entités de la collection.
LIVRE ECRIT PAR AUTEUR
Collection : livre, auteur (deux entités types)
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 43 ‐
Dimension : 2
PERSONNE EST MARIE A

(Relation réflexive)
Collection : personne (une entité‐type)
Dimension : 2 (2 )
Il faut deux occurrences de l’entité PERSONNE pour une occurrence de la re‐

lation EST MARIE A. (il faut être deux pour se marier). Une relation de dimension 2 est
une relation binaire. Une relation de dimension 3 est une relation ternaire. Ex : Jean A
VENDU CHEMISE A PAUL (fait intervenir 3 occurrences : deux occurrences de personnes
et une occurrence de produit)
PERSONNE A VENDU PRODUIT
Une relation de dimension n est une occurrence n‐aire.
La fonctionnalité :
On définit la fonctionnalité d’une relation‐type par rapport à 2 entités‐types X

et Y. On distingue les relations :
Un à un (1‐1) : à tout occurrence de X ne correspond qu’une seule occur‐

rence de Y et vice versa.
Ex : HOMME EST MARIE A FEMME
C’est‐à‐dire un homme est marié à une seule femme et une femme à un homme.
A B
Fonctionnalité de 2 cotés
a 1
Une flèche qui part et une flèche
b 2
c 3 qui rentre (retour)
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 44 ‐
 Un à plusieurs (1‐n)
A toute occurrence de X correspond une ou plusieurs occurrences de Y et à
toute occurrence de Y une seule de X
LIVRE ECRIT PAR AUTEUR
A B un élément de l’ensemble A est en relation avec un ou

1 plusieurs éléments de l’ensemble B, mais un élément de
2 B n’est pas en relation qu’avec un élément de A. Ex : pro‐
3 fesseurs qui donnent cours.
 Plusieurs à plusieurs (m‐n)
A toute occurrence de X correspond une ou plusieurs occurrences de Y et réci‐

proquement.
Client Commande Produit
Un client peut commander plusieurs produits et chaque produit peut être commandé
par plusieurs clients.
Martin a 1 Viande
jacques b 2 Saucisse Ex : livres et lecteurs à la bibliothèque
Honoré c 3 Riz
Totalité/Partialité
Une relation mettant en jeu les entités X et Y est dite :
 Totale : si aucune occurrence de X et aucune occurrence de Y ne peuvent

exister sans participer à une occurrence de la relation.
 Partialité : si certaines occurrences de X ou certaines occurrences de Y peu‐
vent n’être impliquées dans aucune occurrence de la relation.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 45 ‐
Ex : partielle Ex : totale
x. y.
x. Y
x. y.
x. y
x.
X. y
.x y
Il y a une ou deux occurrences qui ne participent Toutes les occurrences

interviennent pas à la relation. dans la relation
Ex : la relation « livre lu par » dans une bibliothèque
Il existe plus au moins des relations entre les objets, mais on ne peut pas imposer la
règle de gestion de ces derniers.
Une association (relation) définit donc un lien sémantique entre une ou plu‐
sieurs entités. En effet, la définition de liens entre entités permet de traduire une
partie des règles de gestion qui n'ont pas été satisfaites par la simple définition des
entités.
Le formalisme d'une association est le suivant :
Généralement le nom de l'association est un verbe définissant le lien entre les entités qui
sont reliées par cette dernière. Par exemple :
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 46 ‐
Ici l'association «être né» traduit les deux règles de gestion suivantes :
 Un auteur est né dans un et un seul pays,
 Dans un pays, sont nés aucun, un ou plusieurs auteurs.
Vous remarquerez, que cette association est caractérisée par ces annotations 1,1 et 0,N
qui nous ont permis de définir les règles de gestion précédentes. Ces annotations sont
appelées les cardinalités.
c).- CLASSEMENT DES RELATIONS
1.‐ Relations permanentes

Ce sont des relations entre les entités permanentes qu’on conserve en per‐
manence et dont on peut modifier des propriétés à tout moment. Ce sont des relations
structurelles.
Exemple :
Soit la relation affectée entre les entités permanentes employés et services

employés (matricule, nom)
Affecté à (heure début, heure fin)
Service (code, intitulé)
Par exemple l’employé A25, JOSEPHINE est EFFECTEE (tous les jours ou‐
vrables de 8h°° à 17h°°) au SERVICE 18, COMPTABILITE.
Depuis l’affectation de JOSEPHINE et jusqu’à la fin de cette affectation, cette

relation (cette AFFECTATION) sera conservée mais on pourra modifier les horaires à
tout moment.
2.‐ Relation de type Mouvements

Ce sont des relations entre entités permanentes ou de mouvements qui re‐
présentent le souvenir d’un événement (relation conjoncturelle).
Exemple :
Relation SE COMPOSE DE entre l’entité mouvement COMMANDE et l’entité

permanente PRODUIT :
COMMANDE (N° BC, date)
SE COMPOSE DE (quantité)
PRODUIT (référence, désignation, prix)
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 47 ‐
La commande 125 du 15 novembre 1998 SE COMPOSE DE trois produits,

(X01, chemise, 1000 FC ) et de deux produits (X 25, pantalons, 2000 FC)
SE COMPOSE DE est le souvenir dans le SI (mémorisation dans le SI) du détail

de l’événement commande N° 125 à savoir que celle‐ci concernait trois unités du pro‐
duit X 01et 2 unités du produit X 25.
3.- CLASSIFICATION DES MOUVEMENTS

Qu’ils soient mémorisés (sous forme d’entité conjoncturelle) ou non, les
mouvements (propriétés portées par les événements) peuvent se classer en :
 Mouvements de maintenance des propriétés signalétiques ou des entités

ou relations permanentes.
 Mouvements d’opérations courantes
Les mouvements de maintenance des propriétés signalétiques correspon‐

dent à la MAJ (ajout, modification ou annulation) des propriétés signalétiques des enti‐
tés ou relations permanentes.
Ils correspondent à l’entretien des ces dernières (l’intendance).
Exemple :
A propos de l’entité permanente Client (code, nom, adresse, CA), tous les
mouvements visant à changer le nom ou l’adresse (propriétés signalétiques) du client
constituent des mouvements de maintenance. Il en va de même de l’ajout ou de
l’annulation du client.
Les mouvements d’opérations courantes correspondent aux événements

quotidiens qui sont traités par le système et qui visent à mettre à jour la situation des
entités ou relations permanentes.
Exemples :
 Les commandes des clients sont des événements courants traités par le SI com‐
mercial et visent à mettre à jour les CA des clients (situations des entités perma‐
nentes) de type CLIENTS et le CA des produits.
 Les écritures servent à mettre à jour la situation des comptes ; entrées‐sorties en

magasin servent à mettre à jour le niveau de stock du produit.
On peut classer les mouvements des opérations courantes par rapport à une pé‐
riode de traitement de référence en :
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 48 ‐
Mouvements nouveaux : mouvements qui n’ont pas encore participé au

traitement de la période (dans le cas des traitements quotidiens des commandes, les
commandes de la journée qu’on vient d’enregistrer en vue de livrer le client) ;
 Mouvements en cours : mouvements nouveaux des périodes précédentes

dont le traitement n’est pas encore terminé (ex : commandes des jours
précédentes qui n’ont pas pu être honorées faute des stocks insuffisants)
 Mouvements historiques : mouvements des périodes précédentes dont
le traitement est terminé (ex : commandes des jours passés ayant donné
lieu à la livraison).
Par rapport à la période de référence d’un autre traitement, les mouve‐

ments historiques peuvent redevenir des mouvements nouveaux.
Ex : à la fin du mois, l’historique des commandes livrées servira des mouvements nou‐
veaux pour l’établissement des statistiques mensuelles des ventes. Les mouvements
nouveaux ne sont pas obligatoirement mémorisés. Les mouvements historiques ou en
cours le sont nécessairement.
Les mouvements opérations courantes permettent soit de MAJ directe‐

ment les situations en permettant les calculs des nouvelles valeurs des propriétés de
situation ; soit de les MAJ indirectement par la MAJ des mouvements mémorisés qui
permettront (à l’ordinateur) de calculer à tout moment la nouvelle situation à partir de
l’ancienne et à partir de ce mouvement.
IV.6.-
IV.7‐ REGLES DE GESTION

Les règles de gestion du MCD précisent les contraintes qui doivent être respec‐
tées par le modèle. Ex : dans le MCD d’une école, les règles de gestion peuvent être les
suivantes :
 Règle de gestion 1 : tout professeur enseigne en principe une matière mais

certains d’entre eux peuvent être dispensés d’enseignement en raison de
travaux de recherche.
 Règle de gestion 2 : toute matière est enseignée au moins une fois
 Règle de gestion 3 : toute classe a au moins trois (3) enseignants ; le MCD de‐
vient alors :
(1, n) Matière
PROFESSEUR ENSEIGNE
(3, n) Classe
Les règles de gestion expriment les contraintes d’intégrité du modèle. Ces contraintes
d’intégrité représentent les lois de l’univers réel modélisé dans le SI. On distingue :
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 49 ‐
(a) Les contraintes (règles de gestion) statiques. Elles peuvent porter :

 Sur une propriété (forme, liste des valeurs possibles, fourchettes des va‐
leurs admissibles)
 Sur diverses propriétés d’une même relation ou entité. Ex : commande (N°
commande, date commande, date livraison). On doit avoir date
commande date livraison.
 Sur des propriétés d’occurrences distinctes d’une relation ou entités. Ex :
ligne‐écriture (N° écriture, libellé, montant, sens)
 Sur des propriétés d’entités/relations différentes. Ex : la somme de CA des
produits doit être égale à celle de CA des clients.
 Sur des cardinalités.
 Sur les dépendances fonctionnelles.
(b) Contraintes dynamiques :
Les contraintes d’intégrité dynamiques expriment les règles de gestion et portent
directement sur les passages du SI d’un état dans un autre ; voire une situation
dans une autre situation. Ex : le salaire d’un employé ne peut pas diminuer.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 50 ‐
IV.8.- DEPENDANCE FONCTIONNELLE
IV.8.1.‐ DEPENDANCE FONCTIONNELLE ENTRE PROPRIETES

Dépendance fonctionnelle : on dit que deux propriétés a et b sont reliées par
une dépendance fonctionnelle et on note : a‐df‐b si la connaissance de la valeur a déter‐
mine une et une seule valeur de b.
Ex : nous pouvons dire que :
1. Num prof‐df‐Age, sexe…

2. Code client‐df‐nom client
La connaissance du code client détermine une et une seule valeur du nom client,
la réciproque n’est pas vraie.
La dépendance fonctionnelle peut porter sur la concaténation de plusieurs pro‐

priétés. Ex : N° Bon de commande + réf‐df‐Qté commandée. La référence seule, le numé‐
ro de BC ne suffit pas non plus il faut les deux informations pour trouver la quantité
commandée.
Dépendance fonctionnelle élémentaire
On dit qu’il y a dépendance fonctionnelle élémentaire entre les propriétés a et b

et on note a‐df‐ b (a dépendance fonctionnelle b) si a‐df‐b et si aucune partie de a ne
détermine b. ex : code client+Nom client –df‐Adresse client n’est pas élémentaire
puisque la connaissance de CODE CLIENT (partie de code client+ Nom du client) suffit à
déterminer l’adresse.
En effet, code client‐df‐Adresse client ou code client adresse client.
Par contre, nous avons : N° Bon de CDE+REF Qté ; vraie parce que le N° Bon de cde
seul ne peut pas déterminer la qté, même chose pour REF seul. Il faut absolument les
deux (N°Bon de cde+Réf).
Dépendance fonctionnelle élémentaire directe :
On dit que la propriété b dépend fonctionnellement de a par une dépendance fonction‐

nelle élémentaire directe si cette dépendance est élémentaire, a b et s’il n’existe pas
de propriété c telle que a df c et C df b (c’est la transitivité), autrement dit
on élimine toute TRANSITIVITE.
Ex : N° professeur code‐matières
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 51 ‐
Code‐matière Nom‐matière
N° professeur Nom‐matière
La transitivité n’est pas autorisée, il faut l’éliminer dans le MCD. Les deux pre‐
mières dépendances sont directes mais la 3ème ne l’est pas en raison de la transitivité.
Une des solutions pouvait être :
N° prof code‐matière Nom matière.
CLE (D’IDENTIFICATION) D’IDENTITE : une clé d’une entité est une pro‐
priété ou une concaténation des propriétés de cette entité telle que toutes les autres
propriétés de l’entité dépendent d’elle fonctionnellement et telle que ceci ne soit plus
vrai pour aucune des ses parties.
Notons qu’une entité peut avoir plusieurs clés. Ex : le numéro d’ordre et le numéro ma‐
tricule. Le modèle devra prévoir celle de clé qui sera retenue comme identifiant. Les dé‐
pendances fonctionnelles entre propriétés sont à considérer par rapport aux entités et
aux relations.
Exemple :
CLIENT
Code client, Nom
0,n Un client peut passer plusieurs commandes=card n mais

un client peut n’avoir pas passé de cde=card 0
Passer commande
1,1 Une commande appartient à un et un seul client il peut y avoir une

commande qui n’appartient pas à un client=card 1
COMMANDE CONCERNE PRODUIT

N° commande, date QUANTITE Réf, désignation
1,n 0,n
Une commande peut concerner plusieurs produits : card 1

On ne peut pas avoir une commande sans produit : card n
Un produit peut se trouver dans plusieurs commandes : card n
Dans l’entité produit, on a la dépendance fonctionnelle REF DESIGNATION.
Par la relation concerne, on a la dépendance fonctionnelle
N° COMMANDE + REFPROD Quantité.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 52 ‐
Les DF qui existent entre les données sont parfois évidentes et ne nécessitent pas toujours une
modélisation mais celle-ci peut s'avérer utile car elle permet, entre autres, de distinguer les
futures entités du MCD et leur identifiants.
IV.8.2.‐ DEPENDANCE FONCTIONNELLE ENTRE ENTITES

Une DF inter-individus est un cas particulier de relation . Elle traduit le fait
que connaissant un ou plusieurs individus de la collection , on connaît directement un
ou plusieurs autres individus de cette collection . Le premier sous-ensemble est
appelé le sous-ensemble source de la DF , le second le sousensemble cible ou but. Les
cardinalités sont 1,1 ou 0,1pour les individus-sous et sont quelconques ( 1,1ou 0,1 ou
0,n ou 1,n ) pour les individus-cible . Ceci traduit le fait qu’à partir d’une occurrence
de l’individu source on pointe sur une et une occurrence de l’individu cible.
La DF est dite forte lorsque la cardinalité minimale de l’individu source est
de 1. Le lien existe alors à tout moment pour l’ensemble. Elle est faible lorsque cette
cardinalité est de 0. Le lien n’existe alors pas pour l’ensemble des individus à tout
moment.
CONTRAINTES D’INTEGRITE FONCTIONNELLE INTER-INDIVIDU (CIF)
Définition : Une CIF est un cas particulier de la DF forte inter-individu. En effet, pour
qu’il ait CIF il faut que la cardinalité source soit obligatoirement 1,1.Ce qui traduit le
fait que le lien existe pour toutes les occurrences de l’individu source .De plus la
dépendance doit être stable , c’ est à dire qu’une fois le lien établi entre deux
occurrences il ne peut être modifié dans le temps . Unetelle dépendance, forte et
stable à la fois , est dite totale.
CONTRAINTE D’INTEGRITE
Si deux entités (individu ou relation ) sont reliées par différents chemins constitués
exclusivement de CIF, il existe alors une contrainte d’intégrité indiquant que les
associations établies entre les occurrences des deux entités , lorsqu‘elles existent ,
doivent être les mêmes quel que soit le chemin.
On dit qu’il existe une dépendance fonctionnelle entre 2 entités A et B et on

note A B si toute occurrence de A détermine une et une seule occurrence de B.
Les cardinalités (1,1) des commandes dans cette relation expriment que tout Bon de
commande détermine un et un seul client. Il s’agit bien entendu d’un client ayant passé
la commande. Ex : COMMANDE CLIENT.
La cardinalité maximum 1 correspond toujours à une dépendance fonctionnelle entre

deux entités.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 53 ‐
PROPRIETES DES DEPENDANCES FONCTIONNELLES
L’étude mathématique des dépendances fonctionnelles dans une relation permet de

donner les règles suivantes :
REFLECTIVE: a df a
Exemples:
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 54 ‐
IV.9.‐ REGLES RELATIVES AU MCD
IV.9.1.- NORMALISATION DES ENTITES

La normalisation consiste, à partir d’une relation dite universelle, à faire éclater celle-ci en
plusieurs tables plus réduites grâce aux formes normales, qui sont basées sur les dépendances
fonctionnelles.
L’objectif de la normalisation est de limiter le nombre de redondances et les anomalies lors de
la mise à jour de la base de données.
La normalisation permettra bien évidement lors de la mise en oeuvre du système
d’information d’éviter certaines anomalies lors de la manipulation des données (création,
suppression, modification).
Première Forme Normale (1FN)
 Les propriétés d’un individu ou d’une relation doivent être atomique (élémentaires)
 Une table est dite en 1FN si chacun de ses attributs dépend fonctionnellement de la clé et est non
répétitive pour une occurrence de celle-ci.
Deuxième Forme Normale (2FN)

 Les propriétés d’une relation doivent dépendre élémentairement de l’ensemble des individus
composant la relation.
 Une table est dite en 2FN si chacun de ses attributs non-clé dépend complètement de la clé.
Troisième Forme Normale (3FN)

 Toute propriété appartenant à un individu ou à une relation doit dépendre directement
de l’identifiant, et de lui seul.
 Une table est dite en 3FN si elle est en 2FN et s’il n’a pas de dépendances fonctionnelles entre les
attributs non-clé.
FORME NORMALE DE BOYCE-CODD (BCNF)

 Un individu déterminé de manière unique par une relation, ne peut déterminer à son tour
d’une manière unique l ‘un des individus appartenant à la collection de la relation; Lorsque
cette règle est vérifiée ,le modèle est alors en BCNF .
 Une table est dite en BCFN si elle est en 3FN et si elle ne contient pas de dépendances
fonctionnelles autres que celles pour lesquelles un attribut clé détermine un attribut non-clé.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 55 ‐
QUATRIEME FORME NORMALE (4FN)

Pour toute relation d ‘ordre n, les relations d’ordre n-1 construites sur sa collection
doivent avoir un sens .
Cinquième Forme Normale (5FN)

Une relation de degré n doit être décomposée en relations de degré n-1 si l’ensemble de
ses occurrences est retrouvé à tout moment par application d’une opération de jointure
naturelle sur les occurrences des relations partielles prises deux à deux . Dans ce cas ,
relation viole la 5FN .
NB : Les normalisations ci‐dessus ont pour but d’éliminer les anomalies de MAJ (si on
annule un client, on veut sans doute conserver la catégorie de ce client).
IV.9.2.- RESPECT DES CONTRAINTES D’INEGRITE

----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 56 ‐
Le MCD doit respecter les règles de gestion qui expriment ses contraintes
d’intégrité. Ex : un professeur enseigne une ou plusieurs matières.
PROFESSEUR
code‐professeur
0, n
FAIT COURS
1, n 1, n
MATIERE CLASSE
matière N° Classe
Ce MCD ne respecte pas la règle de gestion car il admet de professeur qui n’enseigne pas,
ce qui contredit la règle de gestion.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 57 ‐
IV.9.3.- VERIFICATION
Dans toute occurrence d’entité ou de relation‐type, il ne doit y avoir qu’une seule
valeur de chaque propriété (non répétitivité). Pour les entités, cette règle résulte de la
première FN. Elle doit rester vraie pour les relations.
Ex : soit le MCD suivant :
CLIENT 0, n PASSER COMMANDE 1, n REPRESENTATION

code client, Nom Bon cde, date, Qté code repr, Nom repr
Ici les clés code client et code repr, ne permettent pas de trouver la quantité. La relation
PASSE COMMANDE n’est pas vérifiée car il peut y avoir plusieurs valeurs de la quantité
dans une commande passée par un client à un représentant. La quantité ne dépend pas
seulement du CLIENT et du REPRESENTANT mais aussi du produit commandé.
Autrement dit : dans une relation, les propriétés doivent dépendre fonctionnelle‐
ment des entités concernées par la relation. La concaténation de ces identifiants
constitue l’identifiant de la relation. Tentons d’améliorer le MCD ci‐dessus :
CLIENT PASSER COMMANDE REPRESENTANT

code client, nom N° Bon cde, Date code Repr, Nom repr
0, n 0, n
0, n
Commande produit PRODUIT

Quantité 1,n Réf, Design, PV
Dans la relation COMMANDER PRODUIT, la quantité ne dépend pas seulement du

CLIENT et du PRODUIT, mais aussi N° Bon de cde (un client peut passer plusieurs com‐
mandes du même produit). Le N° de commande n’est pas connu si on connait CLIENT,
PRODUIT et REPRESENTANT car il peut y avoir plusieurs Bons des commandes pour un
client donné, un représentant donné et un produit donné. La règle de vérification n’est
pas respectée. Il faut en fait créer l’entité COMMANDE.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 58 ‐
D’où le MCD devient :

code client, Nom DATE code repr, Nom
0, n 0, n
0, n
COMMANDER PRODUIT 1, n
COMMANDE
Quantité N° bon de cde
0, n
Ici, la connaissance de code client, N° Bon de cde,
Réf permet de connaitre le nom du produit

PRODUIT
Réf, Design, PU
IV.9.4.- NORMALISATION DES RELATIONS.

Chaque propriété de la relation doit dépendre fonctionnellement de
l’ensemble des identifiants des entités qui participent à la relation, mais d’aucun
sous‐ensemble de cet ensemble. Il doit y avoir une dépendance pleine des propriétés
de la relation par rapport aux entités.
Ex : dans la MCD ci‐dessus, on a : N° Bon de commande, Date car, la date de la

commande peut être connue si l’on connait N° Bon de commande.
La propriété DATE dépend du N° Bon de commande et il n’y a pas dépen‐

dance pleine par rapport à l’ensemble des entités CLIENT, REPRESENTANT, COM‐
MANDE qui participent à la relation PASSER COMMANDE. La DATE est une propriété qui
doit migrer vers l’entité COMMANDE. Notre MCD dévient alors :
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 59 ‐
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 60 ‐
Mais, la quantité commandée est connue si on connait le N° Bon de commande et la réfé‐
rence du produit commandé. On a :
N° Bon CDE + REF Qté et la quantité est vérifiée sur les sous‐
ensembles commande et produit de la collection Client X Commande X Produit de
la relation COM‐ MANDER PRODUIT. Celle‐ci ne respecte donc pas la règle de
normalisation.
IV.9.5.- DECOMPOSITION D’UNE RELATION

La décomposition consiste à remplacer une relation de dimension n en plusieurs
relations de dimensions plus petites en utilisant les dépendances fonctionnelles qu’on
peut détecter sur la relation. Ex : Dans la relation COMMANDER PRODUIT du MCD pré‐
cédent, on a la dépendance fonctionnelle COMMANDE CLIENT.
En effet, une Cde est passée par un et un seul client. On ne peut décomposer que
quand on a la relation 1, 1. (Dans des entités, c’est une relation totale). On peut donc
éclater cette relation en deux relations :
1, n 0, n
COMMANDE CONCERNE CLIENT
1, n 0, n
COMMANDE COMMANDER PRODUIT PRODUIT
La décomposition n’est pas possible qu’à deux conditions :
1. La cardinalité des entités à gauche dans la dépendance fonctionnelle doit être

égale à 1.
2. Si la dépendance fonctionnelle provient d’une autre relation que la relation à
décomposer ; il faut qu’elle concerne les mêmes occurrences d’entités que la rela‐
tion à décomposer.
Dans notre exemple, la dépendance fonctionnelle qui a permis la décomposi‐

tion est COMMADE CLIENT.
Cette dépendance s’applique sur la relation COMMANDER PRODUIT et la car‐

dinalité minimum COMMANDE dans cette relation est bien 1, ce qui assure le respect de
la règle 1.
La dépendance provient de PASSER COMMANDE. La relation PASSER COM‐

MANDE et la relation à décomposer COMMANDER PRODUIT mettent bien en jeu les
mêmes occurrences de CLIENT et COMMANDE car ce sont les mêmes clients qui passent
des commandes et qui commandent les produits car les produits commandés par les
clients correspondent aux mêmes commandes que les commandes passées par les
clients. La condition 2 est donc remplie.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 61 ‐
Dans le MCD, la relation COMMANDER PRODUIT peut être décomposée en

PASSER COMMANDE et une nouvelle relation COMMANDER PRODUIT ci‐dessus. Celle‐ci
faisant double emploi avec SE COMPOSE DE, elle peut être supprimée. De la même ma‐
nière, les dépendances fonctionnelles (dues aux cardinalités 1, 1de COMMANDE dans
PASSER COMMANDE) :
COMMANDE CLIENT
et
COMMANDE REPRESENTANT permettent de composer PASSER COMMANDE en

deux relations binaires : PASSER COMMANDE (entre client et commande) et
OBTIENT COMMANDE (entre représentant et commande).
Le MCD suivant résulte de ces compositions :
0,n
Codeclient, Nom CodeRep, Nomrep
1,1 0,n
1,1
COMMANDE OBTENIR CDE
N°BonCde, Date
1,n
SE COMPOSE DE
Quantité
0,n
PRODUIT
Ref, Design, PU
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 62 ‐
IV.10.- GRAPHE DE DEPENDANCE FONCTIONNELLE

Le graphe de dépendances fonctionnelles (GDF) est la représentation
graphique des dépendances fonctionnelles entre les différents attributs du dictionnaire
de données épuré.
Exemple :
On extrait du DD la liste des propriétés qui ne sont ni concaténées ni calcu‐

lées. Dans notre exemple, on retient toute les propriétés sauf adresse qui est concaténée
et montant et total qui sont calculés. Il faut enlever les propriétés concaténées et celles
calculées dans les tables, cela est le rôle des requêtes en Access.
On établit la liste des dépendances fonctionnelles dont le domaine de

départ ne contient qu’une seule propriété non concaténée à partir de l’examen du
document et de l’identifiant évident. Cette liste de df peut se visualiser sur un graphe
comme celui‐ci :
NOBON REF
Quantité
DATE COREP COCLI Désignation Prix unitaire
NOMREP
NOMCLI RUCLI VICLI
La propriété quantité est isolée. S’il reste des propriétés isolées, on cherche des DF
qui conduisent à ces propriétés à partir des propriétés concaténées. Si on n’en
trouve pas pour une propriété, celle‐ci reste isolée. On utilise ici la dépendance
fonctionnelle (DF) NOBON+REF Qté et on obtient :
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 63 ‐
NOBON REF
QTE
DATE COREP COCLI DESIGN PU
NOMREP
NOMREP RUCLI VICLI
On cherchera toute fois à connaitre et à assurer que les propriétés isolées ne

correspondent à des entités isolées pour lesquelles il faudrait imaginer un identifiant permettant
d’ajouter les dépendances qui faisaient défaut. Si le graphe obtenu comporte des cycles, on élimine
cette anomalie en supprimant une dépendance fonctionnelle.
Ex : cycle anormal
c e
b g
d f
Le cycle e, f, d, e n’est pas admissible, on peut supprimer par exemple d e.
On établit ensuite la liste de toutes les DF qui découlent du graphe obtenu par le
jeu des propriétés des DF.
On utilise en particulier la transitivité et la pseudo‐transitivité. Cette étape permet de

s’assurer qu’on n’a oublié aucune dépendance. On obtient la fermeture des dépen‐
dances fonctionnelles.
REF
NOBON
DATE COREP COCLI QTE DESIGN PU
NOMREP NOMCLI RUCLI VICLI
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 64 ‐
On vérifie qu’il n’y a toujours pas de cycle. On élimine donc la transitivité, on obtient
la structure d’accès théorique (SAT) en ouverture minimale qui représente les di‐
vers chemins d’accès aux données. Il faut que toutes les dépendances fonctionnelles soient
élémentaires et directes.
NOBON REF
QTE
DATE COREP COCLI DESIGN PU
NOMREP
NOCLI RUCLI VICLI
En pratique, on travaille souvent non pas sur le graphe lui‐même, mais sur la
matrice de ce graphe.
Ex :
a b c d
A 1 1 1
B 1 1
C 1
D 1
a
b d
Un 1 en ligne a, colonne b, signale la Df a b
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 65 ‐
IV.11.- QUANTIFICATION DU MCD

On compose en fin le DD par des fichiers signalétiques des entités et des relations in‐
cluant des éléments chiffrés recueillis lors des interviews. Exemple :
ENTITE IDENTIFIANT PRROPRIETE LONGEURR Nombre

d’occurrences
COMMANDE NOBON NOBON 10 1000
PRODUIT REF REF De‐ 42 5000
sign, PU
RELATION COLLECTION CARDINALITE PROPRIETE LONGEUR NB MOYEN

PASSER COM‐ COMMANDE 1, 1 0 1000
MANDE CLIENT
SE COMPOSE DE COMMANDE 1, n Qté 3 5000
PRODUIT 0, n
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 66 ‐
CHAPITRE V : MODELE LOGIQUE DE DONNEES (MLD)
V.1.‐ INTRODUCTION
 Le modèle logique des données (MLD) se situe entre le modèle conceptuel de données (MCD) et le
modèle physique des données. (MPD) Il représente l’univers des données décrit dans le MCD en
tenant compte du type de base de données choisi : relationnel ou navigationnel.
 Le modèle logique des données MLD fournit une description des données tenant compte des
moyens informatiques mis en œuvre. Il complète le MCD en introduisant la notion d’organisation. Il
indique donc comment les données seront organisées. Tandis que le modèle physique des données
décrit la base des données où l’ensemble des fichiers correspond aux données gérées par le système
d’information. Le MPD prépare le système de gestion des données.
 La description conceptuelle a permis de représenter le plus fidèlement possible les réalités de
l’univers à informatiser. Mais cette représentation ne peut pas être directement manipulée et accep‐
tée par un système informatique. Il est donc nécessaire de passer du niveau conceptuel à un second
niveau plus proche des capacités des systèmes informatiques.
Des SGBD relationnels, tels que ORACLE ou SQL Server, permettent à un utilisateur
d’exploiter les données ainsi mémorisées.Dans ce chapitre, seul le modèle relationnel sera étudié. Il
est conseillé de se référer au cours de bases de données afin de revoir tous les concepts qui se rapportent à
ce modèle.
Le choix dépend en général du logiciel dont on dispose et le nouveau modèle MLD (mo‐ dèle logique de
données) devra rendre compte des limites et des possibilités de ce logi‐ ciel ; sans toutefois entrer dans les
détails des méthodes de stockage et d’accès qui révè‐ lent du niveau opérationnel. En ce qui concerne les
bases de données, on peut les classer comme suit :
 Base des données navigationnelles
 Base de données relationnelles
Dans les BD navigationnelles, il y a un chemin d’accès préétablis, ce qui n’est pas le

cas dans les BD relationnelles.
V.2..‐ PASSAGE DU MCD « ENTITE RELATTION » AU MLD RELATIONNEL
Le passage du modèle conceptuel de données au modèle logique de données se fait par

une opération de traduction. Ce dernier est une représentation du système tel qu'il sera
implémenté dans des ordinateurs.
Règle 1 : une propriété du modèle conceptuel de données devient un attribut de la
relation (table) càd Les propriétés portées par les individus du MCD deviennent attributs des
tables du MLD.
Règle 2 : Chacun des individus du MCD devient une table relationnelle du MLD en d’autres termes
les entités deviennent des tables (relations)
Règle 3 : L’identifiant des individus du MCD devient la clef primaire des tables relationnelles du
MLD. Les identifiants des entités deviennent des clés primaires des relations ;
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Cours conçu et dispensé par l’Ass. Kakule Musubao , ISC-GOMA , G2 JOUR I.G. mail : kakulemusub@yahoo.fr, jkmusubao@gmail.com, Tél : 0998707246 ,
‐ 67 ‐
Règle 4 : Cardinalités (1,1)-(X,N)
L’identifiant de l’individu qui a la cardinalité (X, N) devient une clé étrangère de la table générée par
l’individu ayant la cardinalité (1,1) L’association hiérarchique se traduit en ajoutant dans la
table ayant la cardinalité (X,N) l'identifiant de la table ayant la cardinalité (1,1).
Règle 5 : Cardinalité de type (X, N) – (X, N)

 Une association multiple se traduit par la création d'une table intermédiaire reliant
les tables correspondantes aux entités associées. La clé de la table intermédiaire est
le couple formé par les deux clés de la table liée. La clé de la relation est l'identifiant
de l'association, donc la concaténation des identifiants des entités qui concourent à
l'association. Ces identifiants sont aussi précédés du signe # puisqu'ils sont clés
primaires d'autres relations.
 La relation liant les individus du MCD devient une table relationnelle du MLD. Sa clef est
constituée des identifiants des individus du MCD que la relation reliait au niveau du MCD. Si la
relation liant les individus est porteuse de propriétés, ces propriétés deviennent des attributs de
la table relationnelle du MLD générée.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 68 ‐
EXEMPLE : Soit le MCD ci-après :
CLIENT 0, n PASSE 1, 1 COMMANDE

COCLI, NOCDE,
NOM DATE
1, n
SE COMPOSE DE
Qté
0, n
1, n 1, 1
TVA TAXE A PRODUIT
codeTVA, REF, DESIGN, PU
TAUX
MLD RELATIONNEL qui découle de ce MCD est le suivant :
 Client (cocli, nom,)

 Commande (nocde, date, #cocli)
 Ligne commande (#nocde, #réf, Qté)
 Produit (réf, désign, PU,#codeTVA)
 TVA (code–TVA, taux)
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 69 ‐
V.3.‐ RAPPEL SUR LES BASES DE DONNEES
- Une base de données est un ensemble structuré de données enregistrées dans un ordinateur
et accessibles de façon sélective par plusieurs utilisateurs.
- Une base de données, BD ou BDD en abrégé (en anglais database), est une entité dans
laquelle il est possible de stocker des données de façon structurée. Ces données doivent être
utilisées par des programmes, par des utilisateurs différents. Ainsi, la notion de base de
données est généralement couplée à celle de réseau, afin de pouvoir mettre en commun des
informations, d'où le nom de base. On parle généralement de système d'information pour
désigner toute structure regroupant les moyens mis en place pour pouvoir partager des
données.
NB : Une base de données permet de mettre des données à la disposition d'utilisateurs pour
une consultation, une saisie ou bien une mise à jour, tout en s'assurant des droits accordés à
ces derniers. Cela est d'autant plus utile que les données informatiques sont de plus en plus
nombreuses. Une base de données peut être locale, c'est-à-dire utilisable sur une machine
par un utilisateur, ou bien répartie, c'est-à-dire que les informations sont stockées sur des
machines distantes et accessibles par réseau. L'avantage majeur de l'utilisation des bases de
données est la possibilité de pouvoir être accédées par plusieurs utilisateurs simultanément.
Cet outil (Base de données) remplace avantageusement le concept de fichiers. Il est ca‐
ractérisé par les points suivants :
a) Données structurées : comme avec les fichiers, les données sont reparties
en enregistrement. Chaque enregistrement ayant une structure bien définie
répondant aux caractéristiques d’un enregistrement‐type.
b) Données non redondants : une même donnée ne sera pas répétée plu‐
sieurs fois dans la base de données ;
c) Données cohérentes : dans une base, il ne doit pas être permis d’enregistrer
des données incohérentes entre‐elles (voir intégrité référentielle)
d) Données accessibles directement selon des multiples critères
e) Données reliés entre elles conformément au MCD
f) Indépendance de programmes et des données : la base de données doit
être indépendante de TTT et doit permettre la prise en compte facile des
nouvelles applications. La programmation des applications ne doit pas dé‐
pendre des méthodes de stockage et d’accès utilisées pour des données. Elle
doit permettre l’évolution et la possibilité de modifications de la structure
de données sans remise en cause des programmes d’application qu’il utilise.
g) Données MAJ et exploitables par divers utilisateurs autorisés travail‐
lant éventuellement sur des problèmes différents.
h) Sécurité des données stockées. On distingue trois types suivants de
sécurité :
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 70 ‐
 Sécurité contre les indiscrétions : c’est la confidentialité (voir mot de

passe)
 Sécurité contre les destructions (pannes logiciels, départ du courant)
 Sécurité contre les erreurs
V.4.- SYSTEME DE GESTION DES BASES DE DONNEES (SGBD)

 Un SGBD est un logiciel permettant de décrire, manipuler et traiter les don‐
nées d’une base de données. Il permet de décharger le programmeur de la
programmation détaillée de toutes les manipulations de données sur la base.
 Les programmes d’application peuvent communiquer avec le SGBD par
l’intermédiaire des commandes ou instructions appropriées.
 Le SGBD sert donc d’interface entre les programmes d’application des utilisa‐
teurs d’une part et la base de données d’autre part.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 71 ‐
CHAPITRE VI : LE MODELE CONCEPTUEL DES TRAITEMENTS (MCT)

VI.1.‐ INTRODUCTION
 Le modèle conceptuel des traitements (MCT) permet de mettre l’accent sur l’ensemble
d’opérations réalisées au sein de l’entreprise en répondant à la question QUOI ? La conception du
modèle conceptuel des traitements se base sur le graphe de flux et les règles de gestion.
 Comme il a été dit dans le chapitre d’introduction, tout système d'information est composé d’une
base d’information et d’un processeur d’information qui représentent respectivement sa sta‐
tique et sa dynamique. A l’instar du Modèle Conceptuel des Données (MCD) qui schématise les
don‐ nées du système d’information, le Modèle Conceptuel des Traitements (MCT) décrit les
traitements et plus précisément toutes les activités découlant des échanges entre le domaine
étudié et le monde extérieur. Il exprime donc ce que fait le domaine sans se poser le problème
de savoir qui le fait, quand et comment.
 Le modèle de traitement est un zoom sur le modèle de communication de l'entreprise. Dans le
modèle de communication, sont représentés les messages échangés entre intervenants. Dans les
modèles de traitement, nous "voyons" comment un intervenant de l'entreprise réagit quand il
reçoit ce message et quelle opération il effectue. Un modèle conceptuel de traitement (MCT)
comprend les messages et leurs informations, les opérations conceptuelles et leurs opérateurs, les
intervenants de l'entreprise. Les intervenants de l'entreprise pris en compte sont les domaines
pour un modèle global ou les sous-domaines pour un modèle de traitement détaillé.
VI.2..‐ CONCEPTS DE BASE
VI.2.1- EVENEMENT
 L’événement matérialise un fait, qui en se produisant, doit déclencher une réaction du système.
Plus précisément cette notion recouvre deux aspects :
- le fait qui survient et sa perception. La décision d’un élève de terminale de s’inscrire à la
faculté de Bordeaux illustre cet aspect.
- le compte rendu de cette perception faite auprès du système d’information. Ainsi, dans le
cas de la pré-inscription, c’est le remplissage du dossier qui constitue le compte rendu du
souhait de l’élève.
Seul le second aspect est pris en compte dans la dynamique du système d’information et
correspond à la définition d’événement. Du fait de cette restriction l’événement (au sens
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 72 ‐
du modèle conceptuel des traitements) est porteur d’informations qui doivent être
obligatoirement digérées par le système d’information sans quoi il ne répondrait pas à
ses objectifs.
Parmi les événements, on distingue les événements externes et les événements internes :
 les événements déclencheurs externes sont des événements émis par un acteur externe. Par
exemple le dépôt d’un dossier de pré-inscription est un événement externe déclenché par un
futur bachelier souhaitant intégrer un DEUG à la faculté de Bordeaux.
 les événements internes sont des événements qui surviennent lorsqu’une opération se
termine. Ce peut être par exemple l’acceptation de la pré-inscription après vérification du
contenu du dossier. Un événement interne n’a lieu d’être que si le compte rendu de la fin
d’une opération doit être soit suivi d’une nouvelle réaction du système d’information, soit de
l’émission d’un message vers l’environnement.
Certains événements externes sont liés au temps. Par exemple, pour déclencher un traitement en début
d’année civil, on introduira l’événement « Début d’année ». L’événement « Date actuelle est
JJ/MM/AAAA » permettra d’exécuter un traitement à une date donnée.
Dans le MCT, chaque événement est identifié au moyen d’un libellé générique tel que « Dépôt d’un
dossier de pré-inscription ». Compte tenu de ce qui vient d’être dit, cet intitulé est très insuffisant pour
décrire l’événement car il ne fait pas apparaître les données du compte rendu associé à l’événement. Par
exemple, le dépôt d’un dossier de pré-inscription apporte de nombreuses informations telles que l’état
civil de l’élève qui effectue le dépôt, des données sur sa scolarité actuelle, le DEUG qu’il souhaite intégrer,
etc. Dans le cas où le nombre d’informations contenues dans le message associé à l’événement est peu
important il est recommandé de les citer en annexe du MCT. Dans le cas contraire, il sera utile de dégager
les principales entités figurant dans le compte rendu. Le terme « entité » ne fait pas référence au modèle
conceptuel des données ; il est pris dans son sens très général pour désigner tout objet abstrait ou concret
caractérisé par un ensemble de propriétés. Par exemple, l’événement « Dépôt de dossier de pré-
inscription» sera détaillé ainsi : « Dépôt du dossier de pré-inscription de l’élève E de la terminale T à la
formation F ». Ce texte, qui constitue le message associé à l’événement, fait intervenir trois « entités » :
Elève, Terminale et FormationSup.
Notons enfin que l’intitulé générique étant parfois long, on lui associe, sur le MCT un alias afin de le
référencer plus facilement. Les alias seront codés ainsi : « ext » ou « int » pour indiquer le type de
l’événement suivi d’un numéro séquentiel. Par exemple « ext1 » désignera l’événement « Dépôt d’un
dossier de pré-inscription ».
 Un événement est le compte rendu au SI du fait que quelque chose s’est pro‐ duit dans l’UE ou dans
le système d’infos lui‐même. Un événement est externe s’il pro‐ vient de l’UE. Il est interne dans le cas
contraire ; c.à.d. s’il a été produit par le SI. Un évé‐ nement externe doit provoquer une réaction du SI
sous la forme d’une opération. Un événement peut être porteur des propriétés. Ces propriétés
constituent un mouvement (interne ou externe). Les propriétés d’un mouvement contraire au MCD
n’ont pas besoin d’avoir un identifiant. Si on veut garder trace d’un mouvement et donc d’un
événement, une des actions de l’opération doit consister à mémoriser les propriétés de ce mouve‐
ment.
 Un événement est un fait qui provoque la réaction du système d’information. Un événement est une
action qui permet de déclencher plusieurs opérations à l’intérieur de l’organisme.
TYPE D’EVENEMENT
 Un type d’événements est un ensemble d’éléments caractérisés par :

 Des mêmes types des propriétés associées
 Des mêmes types d’actions à entreprendre
Chaque événement de ce type constitue une occurrence de ce type d’événements.
 Il existe deux types d’événements :
- Evénement déclencheur,
- Evénement résultat,
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 73 ‐
VI.2.2.- OPERATIONS
 La réponse à l’arrivée d’un événement est le déclenchement d’un ensemble de traitements appelé
opération. Le traitement d’enregistrement d’une pré-inscription est une opération déclenchée lors
du dépôt de dossier de pré-inscription
Lors de son exécution une opération ne peut pas être interrompue par l’attente d’un événement
externe. L’exécution d’une opération se ramène à l’exécution d’actions élémentaires effectuées sur la
base d’informations à partir des données portées par le ou les événement(s) déclencheur(s). Ces
actions élémentaires portent sur des occurrences d’entités ou d’associations du modèle conceptuel des
données et peuvent appartenir à l’un des quatre types suivants :
 insertion
 la modification
 l'effacement
 recherche
La logique d’enchaînement des actions élémentaires n’est pas toujours séquentielle et peut faire
intervenir des structures alternatives (Si .. Alors … Sinon) ou itératives (Tant que …, Répéter …, Pour …).
Sur le MCT, une opération est identifiée par un libellé et peut être décrite, de manière détaillée, en
annexe du MCT, en présentant la logique algorithmique du déclenchement des actions élémentaires.
Par exemple l’opération d’enregistrement du dossier de préinscription pourrait être détaillé ainsi :
- création d’une occurrence de l’entité « Préinscrit »
- création d’une occurrence de l’association « Demande » (reliant l’entité « Préinscrit » à l’entité
« Formation »)
- …
 Une opération est un ensemble d’actions accomplies par le SI en réaction à un
événement ou à une conjonction d’événements. Une opération produit en sortie
des nouveaux événements appartient à un type d’opération caractérisée par :
 Des types d’actions à entreprendre (chaque action étant une combinaison
d’actions élémentaires : ajout, modification, annulation, déduction et re‐
cherches reliées par TANT QUE…FAIRE et SI…ALORS SINON)
 Des types d’événements contributifs, eux‐mêmes caractérisées par des

types de propriétés (ces propriétés constituant des informations qui seront
utilisées par les actions de l’opération)
 Des types d’événements produits (événements internes ou résultats) dont
l’émission est soumise à des règles d’émission (règles de gestion condition‐
nant la production de ces événements)
 L'opération conceptuelle est un traitement, un travail effectué par un intervenant afin
d'émettre un message et/ou d'en traiter un dans un but précis. L'opération est
effectuée par un intervenant interne, un domaine ou un sous-domaine. L'opération
est dite conceptuelle, indépendante de l'organisation. Seules les opérations effectuées
par l'entreprise, les intervenants internes, sont analysées.
Exemple : la commande est une commande de coke. Le message à traiter ou
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 74 ‐
événement de l'opération est commande de coke. Les messages pouvant résulter de
l'opération sont les ordres de livraison ou de réapprovisionnement ou une
proposition de produit de substitution au client.
VI.2.3.- SYNCHRONISATION
Une synchronisation d’une opération marque le rendez‐vous des événements
contributifs qui doivent être arrivés avant le déclenchement de l’opération selon une
proposition logique (faite de OU et de ET) traduisant les règles de gestion d’activation,
c.à.d. les règles de gestion que doivent vérifier les événements contributifs pour déclen‐
cher les actions.
C’est une condition booléenne (ET / OU) traduisant les règles de gestion que doivent
respecter les événements pour déclencher une opération. Dans le cas ET, elle marque qu'un évé‐
nement déjà là doit en attendre un ou plusieurs autres. Remarque : Pour qu'il soit question de
synchronisation, il faut la présence de plusieurs événements déclencheurs ; aussi, le symbole de
synchronisation est laissé à blanc dans le cas d'un événement unique. Si tous les événements
entrants sont liés par le même opérateur, on peut seulement faire figurer l'opérateur dans le
symbole de synchronisation sinon il faut numéroter les événements (a, b, c …) et constituer l'ex‐
pression à l'aide des événements et des opérateurs. (ex : (a ET b)OU c)
Un type de synchronisation est caractérisé par :
 Une liste de type d’événements contributifs
 Des règles d’activation portantes sur ce type d’événements. Le MCD est global
mais le MCT se fait par Processus.
 La synchronisation de la première opération peut se faire sans attente des
apparitions d’un événement mais la synchronisation de toute opération sui‐
vante doit correspondre à une attente, car s’il n’y a pas attente entre la pre‐
mière et la deuxième opération, la deuxième devrait faire partie de la pre‐
mière (puisqu’une opération est une suite inintérruptible d’actions).
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 75 ‐
Exemple :
a
Incorrect car la production de b déclencherait l’opération 2sans
attente ; ce qui signifie qu’on aurait déclenché OPERATION 1 +
OPERATION OPEARTION 2 sans attente soit en réalité une seule opération.
(b peut produire une opération sans c)

b c
Il fallait la proposition logique ET qui permettra l’attente
d
‐ 76 ‐
OU
OPERATION 2
Avec une proposition logique OU il n’y a pas d’attente, soit b soit c peut
produire l’événement d.
b c
CORRECT
OU
Suite ininterrompue d’actions.
OPERATION
VI.2.4 REGLE D’EMISSION
- La production effective d’une ou de plusieurs occurrences d’un événement interne est

soumise à une règle d’émission, c’est-à-dire à une proposition logique qui s’applique au
contenu de la base d’information après exécution de l’opération. L’événement est produit
si la proposition logique est vraie. A l’issue de l’enregistrement d’un dossier de pré-
inscription deux cas peuvent se présenter :
‐ soit le dossier est complet et une occurrence de l’événement « Pré‐inscription de l’élève
E à la formation F réalisée le JJ/MM/AAAA » est émise
‐ soit le dossier est incomplet (certaines propriétés du MCD n’ont pas été renseignées)
et une occurrence de l’événement « Dossier D Mis en attente le JJ/MM/AAAA » est
pro‐ duite.
-Une règle d’émission permet de passer une condition sur le résultat d’une opération
déclenchée par un ou plusieurs événements.
Une règle d’émission peut être soit :
OK : Si le résultat de l’opération est bon,
___
OK : Si non,
Toujours : S’il n’y a pas de condition sur l’opération.
VI.3.‐ LES TRAITEMENTS
VI.3.1.- PRESENTATION
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 77 ‐
Qu’ils soient manuels ou automatiques les traitements sont constitués
d’opérations déclenchées par l’arrivée des événements. Une opération, pour être
activée doit avoir besoin des diverses combinaisons d’événements contributifs. Ex : les
événe‐ ments DEVIS PROPOSE et DEVIS ACCEPTE sont les événements permettant de
déclen‐ cher l’opération : « CONFECTION DES BONS DE FABRICATION ». Ces conditions
d’activation constituent la synchronisation de l’opération. Une fois déclenchée, celle‐
ci consiste en un certain nombre d’actions visant à mettre à jour la base d’informations
et à produire des nouveaux événements.
MAJ DE LA BASE
SYNCHRONISATION OPERATION
Attente d’événements contributifs (Actions) PRODUCTION

DE nouveaux
événe‐ ments/
événements in‐
ternes
Toute ACTION ou OPERATION est une combinaison d’actions élémentaires :
 Ajout à la base d’information ;

 Annulation dans la base ;
 Modification d’une propriété de la base (on peut considérer qu’il
s’agit d’une annulation plus un ajout)
 Déduction, c’est‐à‐dire élaboration (calcul d’une nouvelle propriété
à partir des propriétés connues), selon les REGLES contenues dans
les MODELES.
 Recherche d’infos parmi les données mémorisées.
Déduction et recherche permettent de confectionner le RESULTAT. Notons

qu’il ne s’agit pas forcement d’actions automatisées. La recherche peut par exemple
con‐ sister à utiliser les fiches en cartons. Les actions élémentaires sont articulées par
les primitives de la programmation structurée : TANT QUE,… FAIRE/FIN FAIRE‐
SI,…ALORS…SINON…
VI.3.2.- CLASSIFICATION DES ACTIONS PAR TYPE DE TRAITEMENT

Les actions manuelles ou automatiques ont pour objet d’effectuer les traitements sui‐
vants :
 Contrôles : vérifier la conformité des mouvements portés par les événements

avec les contraintes du modèle. Ex : pour accepter la commande d’un client, il
faut s’assurer que l’entité en question existe bien (soit répertoriée dans la base
d’infos)
 Maintenance des données signalétiques : mettre à jour les propriétés
signalé‐ tiques des entités et relations permanentes. Ex : noter la nouvelle
adresse du
client sur la fiche « client »
 MAJ des situations : soit directement en mettant à jour les propriétés des
entités et relations permanentes. Ex : en inscrivant le CA du produit qu’on vient
de calcu‐
ler sur la fiche statistique du produit, soit indirectement en enregistrant le mou‐
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 78 ‐
vement courant permettant de calculer ensuite la nouvelle situation ;
 Confection des résultats par des actions de recherche et déduction (cal‐
culs). Cette classification est de nature conceptuelle, quelque soit
l’organisation
retenue, en particulier, que les traitements soient automatiques ou non. Sur le
plan organisationnel et a fortiori opérationnel, les actions pourront revêtir des
formes très variées.
VI.3.3.- TRAITEMENTS MANUEL ET AUTOMATIQUE
Traitement Manuel
Exemples :
 Archivage
 Codage
 Destruction des documents
 Transmission d’informations orales
 Remplissage d’un formulaire
 Réception d’un document
 MAJ manuelle
 Report manuel d’information
 Recherche, tri des fichiers,…
Traitement automatique
Exemples :
 Copie des fichiers

 Extraction des fichiers
 Tri des fichiers,
 éclatement d’un fichier,
 MAJ des données dans la Base d’informations,
 consultation d’un ou plusieurs fichiers,
 regroupement des fichiers,…
VI.3.4.‐ LA COHERENCE DU FONCTIONNEMENT DU SYSTEME

Il importe de vérifier par recoupement que le SI fonctionne convenablement :
 Cohérence des sorties entre elles.

 Cohérence des grandes masses des sorties par rapport à celles des entrées.
Exemples :
 Si le système sort des statistiques de vente par client et par produit, il
faut vérifier que CA TOTAL est identique selon les deux ventilations :
TOTAL CA/PRODUIT=TOTAL CA/CLIENT
 Vérifier que la balance est équilibrée
 Vérifier que NOUVEAU STOCK=ANCIEN STOCK+TOTAL Qté ENTREE‐
Qté SORTIE
 Le concepteur du système devra mettre en place la possibilité
d’effectuer des tels contrôles à posteriori.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 79 ‐
‐ EXEMPLE
EXPOSE DU PROBLEME
Dans une grande administration, les demandes de promotion sont traitées selon les
règles de gestion suivantes :
 RG N° 1 : toute demande de promotion doit subir un examen au préalable

permettant de déterminer si elle est recevable ou non.
 RG N° 2 : l’examen du dossier d’une demande recevable ne peut se faire
qu’après rapport du supérieur hiérarchique.
 RG N° 3 : après examen du dossier par l’autorité compétente, la promotion se‐
ra accordée ou refusée.
MODELE CONCEPTUEL DE TRAITEMENT (MCT)
Demande de Evénement externe générateur du proces‐

Promotion sus
Pas d’attente
Examen préalable recevable
Opération
non recevable Règles d’émission des événements in‐
ternes
Dossier
ouvert Rejet Evénements interne résultat
Evénement interne intermédiaire. Attente du

rapport (attente conceptuelle)
Rapport du supérieur
Evénement externe
Hiérarchique
ET Synchronisation marquant l’attente (règles
d’activation de l’opération)
Examen du dossier Opération

avis favorable avis défavorable
Règle d’émission
P--r-o
--m
---o
--t--i-o--n-------------------------------------- --------------P
--r--o--m
---o--t-i-o--n-------------------------------
accordée refusée Evénements résultats
‐ 80 ‐
COMMENTAIRES
 Des événements externes déclenchent le processus (la première opération du
processus). Toute suite ininterrompue d’actions (c’est‐à‐dire ne nécessitant pas
l’arrivée des nouveaux éléments) constitue une opération. Selon les règles
d’émission, l’opération « examen préalable » produit le rejet de la demande ou
l’ouverture du dossier. Dans ce dernier cas, une synchronisation est mise en jeu
et correspond à l’attente de l’arrivée de l’événement externe « rapport du supé‐
rieur hiérarchique».
N.B : dans le MCT il ne faut jamais mettre les qualificatifs comme (DG, Directeur, Pré‐
fet, Comptable mais plutôt par exemple le responsable. Tous ces qualificatifs concer‐
nent l’aspect organisationnel.
 lorsque celui‐ci se produit, la synchronisation est activable et l’opération « exa‐

men du dossier » peut se déclencher. La règle d’activation est ici « dossier ou‐
vert » et « rapport du supérieur ». Elle se traduit par une proposition logique avec
des ET et/ou des OU portant sur les événements contributifs. Selon la règle
d’émission « avis favorable ou non », l’opération « examen du dossier » produit
l’événement résultat « promotion refusée » ou l’événement résultat « promotion
accordée ».
 l’attente de l’événement externe « rapport du Supérieur hiérarchique » est une

attente conceptuelle non liée au choix d’organisation. Si on avait ajouté l’attente
de l’événement « service du personnel disponible » (dans la mesure où c’est le
service du personnel qui instruit le dossier, ce qui est un choix d’organisation), on
aurait eu une attente organisationnelle (attente de la disponibilité d’une res‐
source, ici le service personnel) qui n’a rien à faire au niveau conceptuel.
 Le MCT indique ce qu’il faut faire, mais n’indique pas qui doit faire ni quand
il faut le faire ni où il faut le faire (concepts organisationnels) ni comment il
faut le faire (concept opérationnel).
VI.4.4.- PROCESSUS
Un Processus est un enchaînement synchronisé d'opérations au sein d'un même domaine,

généralement déclenché par un événement externe (externe au domaine ou au SI tout entier).Un
MCT est la représentation de l’enchaînement des opérations d’un processus. Un processus est
un enchaînement d’opérations incluses dans un même domaine d’activités
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 81 ‐
Dans le cas où le MCD est compliqué, on aura à la décomposer en processus
Exemple :
Les Processus Approvisionnement et Gestion de stock (deux processus différents)
VI. 4. SCHEMA DE FONCTIONNEMENT D’UN MCT
Formalisme Utilisé
E1 E2 En Evénements contributifs
PROPOSITIONS LOGIQUES Synchronisation (règle d’activation)

pose des questions pour savoir le processus du système
On décrit tout ce qui se passe dans le système
Opération
ACTIONS
R1 R2 Rp Règles d’émission règles qui permettent de sortir une
action
E’1 E’2 E’3 E’4

Evénements internes produits
Ou alors,
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 82 ‐
VI.5. CONSOMMATION DES OCCURRENCES DES EVENEMENTS CONTRI‐
BUTIFS
Chaque occurrence d’un événement contributif qui active la synchronisation
est consommée. Une occurrence de chaque événement correspondant à la règle
d’émission utilisée sera produite. Ainsi, s’il y a à l’instant t, deux promotions accordées,
une promotion refusée et 3 dossiers ouverts en attente et si, à l’instant t + t1, arrive le
rapport correspondant à l’un de ce dossier, il y a consommation d’une occurrence de
l’événement « dossier ouvert et d’une occurrence de l’événement « rapport ».
En outre, si l’avis est défavorable, il y a création d’une occurrence de « pro‐

motion refusée »… . a la fin de l’opération il n’y a plus que deux dossiers ouverts mais le
nombre de promotion refusée est passé à 2. Autrement dit, il reste deux occurrences de
« dossier ouvert et il y a 2 occurrences de « promotion refusée ».
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 83 ‐
VI.6.‐ CONSTRUCTION DU MCT

Pour construire un MCT, les éléments suivants sont à prévoir :
 Réaliser le graphe des flux (représentation des acteurs, événements et résultats externes
 Pour chaque événement, recenser les opérations déclenchées, et/ou les événements in‐
ternes produits.
 Regrouper dans une même opération tous les traitements qui ont les mêmes déclen‐
cheurs dans une unité de temps, avec la même synchronisation
 Règles de validation Une opération ne peut pas être interrompue par l’attente d’un évé‐
nement externe. Si tel est le cas, il faut décrire une seconde opération déclenchée par cet
événement en attente.
 Cas particuliers : soit le MCT ci‐dessus :
a) Cycles : Pour une même opération, l'événement déclencheur et l'événement résultat sont
identiques. Une commande de client est servie si les marchandises sont disponibles, si‐
non cette commande est mise en attente. Les commandes en attente sont réexaminées
lors de chaque réapprovisionnement afin de les livrer.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 84 ‐
 Il faut s'assurer que le cycle a bien un début et une fin : ici, c'est l’événement "Réapprovi‐
sionnement effectué" qui permet d'éviter que le cycle ne se déroule sans fin sur les
commandes en attente. Noter l'importance du concept d'occurrences d'événement :‐une
occurrence de Réappro est‐elle autorisée à consommer toutes les occurrences de Com‐
mande en attente ?‐si le réapprovisionnement est insuffisant, de nouvelles occurrences
de Commande en attente doivent‐elles être créées ?
b) Les événements consommables
 Un client non satisfait peut retourner un article. On lui fait un "avoir". Il peut alors le présenter en
caisse pour être remboursé de son achat. Il peut encore remplacer l'article défectueux par un
autre, auquel cas on annule l'avoir
VI.6.1- REGLES DE GESTION

Rôle des règles de gestion
Recensées lors de l'étude de l'existant ou définies pour le futur SI, elles décrivent les enchaîne‐
ments d'opérations. Elles rendent possible le regroupement des actions au sein d'une seule opération non
interruptible au niveau conceptuel.
On doit partir des orientations actuelles de gestion pour déterminer les règles de gestion du futur
système à mettre en place. La situation actuelle est la suivante :
 Les commandes clients jugés non solvables sont refusées (par le service commercial) : le service
commercial est organisationnel.
 Les commandes acceptées sont confrontées (au magasin) à l’état du stock pour déterminer quels
sont les manquants et quelles sont les commandes disponibles.
o En cas de manquant, on devra prendre toutes les dispositions pour réapprovisionner le
stock si ce n’est pas encore fait.
 Dès la livraison du fournisseur, les commandes devenues disponibles subissent les mêmes trai‐
tements que celles qui l’étaient dès le départ.
 Les commandes disponibles donnent lieu à la confection des bons de livraison aux clients ; ceux‐
ci peuvent refuser la marchandise, auquel cas il y a retour des marchandises.
 Si le client accepte la livraison, la comptabilité émet une facture qui ne sera soldée qu’après com‐
plet règlement, les clients qui n’ont pas réglé à l’échéance devant recevoir une relance. Les fac‐
tures soldées sont archivées (classées).
On peut alors dégager les règles de gestion suivantes :
RG 1 : toute commande de client non solvable est refusée

RG 2 : les commandes non disponibles sont mises en attente et devront déclencher un réappro‐
visionnement par le fournisseur.
RG 3 : les commandes en attente seront déclarées disponibles lorsque le réapprovisionnement
sera suffisant.
RG 4 : les commandes disponibles donnent lieu à la livraison aux clients.
RG 5 : les livraisons refusées par le client donnent lieu à un retour des marchandises.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 85 ‐
Afin d’être générales et de s’appliquer à un éventuel futur système automatisé, les règles
de gestion doivent faire abstraction de toute notion de lieu, de personne, de moyens ou
de temps (sauf si la durée présente un caractère conceptuel, indépendant de
l’organisation, par exemple l’année fiscale).
VI.6.2- DETERMINATION DES EVENEMENTS A PRENDRE EN

COMPTE
On peut partir d’un schéma de circulation obtenu à partir des interviews de poste de
travail actuel et de l’étude des circuits existants (événement = compte rendu ; synchro‐
nisation = rendez‐vous, voir RG au dessus) :
CLIENT Commande SERVICE Commande MAGASIN

acceptée
COMMERCIAL
Refus
Livraison
Retour Marchandise
Acceptation facture
Manquants
Réapprovisionnement
Facture
Paiement facture COMPTABILITE

Relance
(1)
Factures soldées
SERVICE
FOURNISSEUR
ARCHIVES
Ce schéma est obtenu grâce aux règles de gestion
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 86 ‐
On peut déduire de ce schéma de circulation, le GRAPHE DES FLUX en prenant soins de

gommer tout ce qui est de nature organisationnelle.
Commande
Commande
Commande refusée
acceptée
Listes des
Réapprovi‐
(2) manquants
sionnement
Bon de
livraison
Factures en
Retours attente de
règlement
Règlement
Relance
Factures
soldées
On obtient ainsi presque tous les événements. Des événements générateurs d’attentes
conceptuelles sont à ajouter aux :
 Evénements « réaction client » déterminant si la livraison est acceptée ou

non.
 Evénement date d’échéance ou envoi d’une relance.

 Il n’y a pas d’attente conceptuelle entre les événements commande acceptée
et manquant ou livraison
 Une attente à ce stade ne peut qu’être liée à l’organisation (le temps que le
magasinier consulte ses rayons par exemple).
 Les faits que les commandes acceptées transitent du service commercial au
magasin relève des choix organisationnels. Commande acceptée n’est donc
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 87 ‐
pas un événement conceptuel. On l’enlève du graphe (car elle transite du

client au service commercial)
 On évite des expressions telles que Bon de livraison ou liste des manquants
qui font trop penser à l’organisation existante.
 Le mot : facture en relance revêt un caractère conceptuel dans la mesure où il
y aura toujours des factures avec une organisation ou une autre. On corrige le
graphe de flux comme suit :
Commande
Commande
Refusée
Manquant
Réapprovi‐
(3) sionnement
Livraison
Retour des
mses Factures en
attente de
règlement
Relance
Règle‐
Factures
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Cours conçu et dispensé par l’Ass2. Kakule Musubao , ISC-GOFMaAct, uGr2JOURI.G. mail : kakulemusub@yahoo.fr, jkmusubao@gmail.com, Tél : 0998707246 ,
085311s0o7l3d3ée, Asnnée Académique 2021-2022
‐ 88 ‐
Opération :
 Commande
 Livraison
Chemin à suivre :
 Recueillir des informations auprès des utilisateurs et du Patron de
l’organisation.
 Demander / Elaborer les règles de gestion
 Elaborer le schéma de circulation (composé des postes et événement).
 On enlève tout ce qui est organisationnel et on reste avec les événements.
 On enlève ce qui est conceptuel, ce qui nous fera déboucher aux événements à
prendre en compte sur le graphe.
 On construit finalement le MCT définitif
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 89 ‐
VI.6.3- MCT DEFINITIF (SCHEMA DE FONCTIONNEMENT)
Commande Commande
client en attente
b
REAPPRO
a c
a ou (b et c)
Synchronisation a ou (b et c)
(Règles d’activation)
(règles d’activation) opération1
Examen commande
solvable ou en attente
Règles d’émission
Indisponible
DISPO INSOLVABLE
Toujours oui
(4)
Commande
refusée
Livraison Manquant APPRO
Réaction client
ET
ET
Synchronisation
RATION
FACTURATION Opération 2
n
Livraison Livraisonacceptée
Livraison
refusée
Refusée Acceptée
Date
échéance
Retour Marchandises
Facture en
attente de
ET
Règlement client règlement
Opération 4
Relancer
ET toujours
COMPTABILISATION, REGLEMENT
Comptabilisation, Règlement Opération 3
Règlement suffisant Insuffisant
Règlement Insuffisant
Suffisant Relance
Relance
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 90 ‐
REMARQUES :
 On est dans une sorte de boucle et pour y sortir, on y sort soit par livraison ou
soit par manquant d’où, il faut réapprovisionner encore.
 Si la commande reste toujours indisponible, elle devient une commande en at‐
tente jusqu’à ce que l’on honore la commande.
 Une commande en attente attend toujours un autre événement pour s’exécuter,
(le Réapprovisionnement) c’est une synchronisation.
 Au sein du MCT, nous avons des événements internes et externes.
 On peut soi‐même déclencher une opération.
 b et c peuvent eux‐mêmes déclencher la même opération
 a ou (b et c) peuvent déclencher la même opération également.
 Il n’y a pas de traitement sans événements
 Un événement peut produire 1 ou plusieurs événements.

 Pour produire un autre événement, il faut des règles d’activation (synchronisa‐
tion) et les règles d’émission.
 APPRO désigne le processus de réapprovisionnement non traité ici,
qui produit (par commande au fournisseur) l’événement «réappro‐
visionnement » en réaction à l’événement « produit manquant »
 S’il y a réapprovisionnement, l’occurrence de « commande en attente » pour le

produit réapprovisionné est consommée.
 On remarque que le TTT « relancer » consomme l’événement « facture en at‐

tente » et produit exactement le même événement car le fait d’envoyer une re‐
lance ne signifie pas que cet événement n’est plus à traiter, bien ou contraire.
DESCRIPTION DES EVEENEMENTS

Pour chaque événement, il faut décrire les éventuelles propriétés portées par celui‐ci..
Exemple :
 Evénement externe « commande client ». le client de code C commande le produit
de référence R pour une quantité Q.
o Propriétés : CRQ
 Evénement interne “ Réapprovisionnement’’. Le produit R a eu une entrée en
stock d’une quantité Q1.
o Propriétés : RQ1
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 91 ‐
EVENEMENT NATURE PROPRIETES

Commande client EXTERNE Code client
Référence du produit commandé
Quantité commandée
Réapprovisionnement INTERNE Référence du produit entré en stock
Quantité entrée
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 78 ‐
VI.6.4.- DESCRIPTION DES OPERATIONS
Outre les événements produits par l’opération, il convient de décrire les actions
entreprises et de mesurer ainsi leurs incidences sur la base d’informations.
Exemple :
MCT ACTUEL FUTUR
PROCESSUS : COMMANDES
OPERATION : Examen de la commande
a b
Examen
R1 R2 R3 R4
c
d e f
EVENEMENTS CONTRIBUTIFS
a : commande client
b : réapprovisionnement
e : commande en attente
EVENEMENTS EMIS
c : livraison
d : manquant
e : commande en attente
f : commande refusée
REGLE D’EMISSION
R1 : client solvable ET produit en stock
R2 : client solvable ET produit non disponible ET commande client
R3 : client solvable ET produit non disponible
R4 : client non solvable
ACTION SUR LA BASE
Consultation : consulter solvabilité du client, si solvable, ALORS consulter stock produits commandés
Mis à jour : si pas commande en attente ET client solvable ALORS insérer commande
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Cours conçu et dispensé par l’Ass. Kakule Musubao , ISC-GOMA , G2 SOIR I.G. mail : kakulemusub@yahoo.fr, jkmusubao@gmail.com, Tél : 0998707246 ,
‐ 101 ‐
CHAPITRE VII : MODELE ORGANISATIONNEL DES TRAITE‐

MENTS (MOT)
VII.1.‐ INTRODUCTION
- Le modèle organisationnel des traitements (MOT) est une représentation de l'activité de

l'organisme étudié qui prend en compte :
 La représentation des traitements entre l'homme et la machine;

 La période de déroulement de chaque tache;
 Répartition de la responsabilité de ces traitements (taches) au niveau des
microstructures : services, départements, divisions, poste de travail, bureaux, …
- Le modèle organisationnel des traitements s'attache à décrire les propriétés des traitements
non traitées par le modèle conceptuel des traitements, c'est‐à‐dire: le temps, les ressources, le
lieu. Le modèle organisationnel des traitements consiste donc à repré‐ senter le modèle
conceptuel des traitements dans un tableau dont les colonnes sont la durée, le lieu, les
responsables et ressources nécessaires à une action.
- Le niveau conceptuel exprimait le QUOI ? Le niveau organisationnel s’attache à décrire le SI
en répondant aux questions QUI ? OU ? QUAND ? Au plan de la description, le modèle
organisationnel des traitements (MOT) intègre les notions de temps, de durée (déroulement),
des ressources, de lieu et de responsabilité (poste de travail) et de na‐ ture des traitements
(manuels ou automatiques). Comme pour les chapitres précédents, ce chapitre s’appuie
également sur un exemple.
VII.2‐ CONCEPTS DE BASE D’UN MOT
a).- POSTE DE TRAVAIL

Un poste de travail est caractérisé par :
Un type de lieu qui représente l’ensemble des lieux où les actions d’une
opération pourront s’effectuer. Une occurrence d’un type de lieu particulier (là où
les actions de la procédure vont se passer. Ex : le magasin est l’ensemble des en‐
droits où pourra s’effectuer tous les inventaires. Un magasin particulier est une
occurrence du type de lieu magasin.
Un responsable : personne ayant la responsabilité de certaines actions d’une
opération ou ensemble des personnes. Ex : le chef magasinier est responsable des
inventaires.
Des ressources : moyens permettant de réaliser certaines actions d’une opé‐
ration.
Une ressource peut comporter essentiellement :
 Des hommes (personnel)
‐ 102 ‐
 Des programmes (logiciel)
 Des machines (matériel)
 Des hommes + des machines (système homme‐machine)
 Des fichiers
 Et accessoirement des outils ou de supports divers. Ex : aide magasinier,
micro‐ordinateur, disquette, papier.
Une ressource peut être partageable ou non. Une ressource partageable est
une ressource permettant de réaliser des actions distinctes simultanément. Ex : ordina‐
teur multipostes (qui connecte plusieurs périphériques d’entrée et sortie). Une res‐
source peut être consommable ou réutilisable Ex : le papier listing est consommable. Le
micro ordinateur et le magasinier sont réutilisables.
Bien entendu, une source réutilisable ne l’est pas indéfiniment (usure du matériel et du
personnel).
b).- PROCEDURES FONCTIONNELLES (PF)

Une Procédure Fonctionnelle (PF) est l’ensemble d’actions d’une opération
conceptuelle affectée à un poste de travail. Une PF est in interruptible.
1).‐ NATURE D’UNE PF
La nature d’une PF est son degré d’automatisation. Une PF est automatisée si

elle comporte des TTT automatiques (TA), dans le cas contraire, elle est manuelle. Une
PF automatisée peut être entièrement automatique (TTT différé en Batch), conversa‐
tionnel (on‐line : dialogue interactif ; c.à.d. avec TTT automatique complet, par transac‐
tion en temps réel) ou OFF LINE (ex : saisie dans un atelier de saisie par encodage)
2).‐ DEROULEMENT D’UNE PF
Le déroulement d’une PF comporte :
 L’instant où commence la PF : cet instant peut être parfaitement déterminé ;

par exemple : 9h du matin ou seulement déterminé par un instant au plutôt et
un instant au plus tard, par exemple : 9 T 17
 La durée maximale d’exécution de la PF.
3).‐ FLUX ENTRANT OU SORTANT D’UNE PF
 Flux entrant (entrées) : ensemble des informations qui sont traitées lors
d’une exécution de la procédure fonctionnelle.
 Flux sortant (sorties) : ensemble des informations émises lors d’une exécu‐
tion de la PF et constituant soit un flux entrant dans une autre PF ; soit des
résultats pour l’univers extérieur au SI.
 Le flux véhiculé par un support. Ex : papier, disquette ou même un homme.
Les informations transmises à travers le flux peuvent être :
 Des mouvements portés par les événements

‐ 103 ‐
 Des mouvements antérieurs mémorisés dans la base d’infos à l’occasion
d’événements antérieurs participants à la synchronisation.
 Des mouvements nouveaux mémorisés liés à un événement émis par la PF.
 Des lots de données permanentes dont l’’existance participe à l’un des évé‐
nements générateur des mouvements ou émis par la PF ou qui sont seulement
consultés ou mises à jour.
Le flux entrant est constitué par les informations qui doivent être traités par la pro‐
cédure fonctionnelle. Les événements de la synchronisation participent au déclen‐
chement de la PF. Le flux entrant est traité à l’occasion d’un événement. Le flux sor‐
tant est émis par un événement.
Concernant l’Exemple ci-dessous :
 Dans PF12, à l’occasion d’événement, “la date d’inventaire est arrivée’’, le lot
d’entités de type “stock d’un produit’’ située dans la disquette “stock à jour’’ est con‐
sultée et PF12 émet l’événement “Etat du stock édité’’ porteur comme information en
sortie du lot de la ligne relative au stock de produits.
 Dans PF6, l’événement “commandes transmises’’ est en fait un lot d’événement “une
commande est transmise’’, chacun de ces événements portants des informations re‐
latives à une commande et constituant une entrée dans PF7.
Certains événements comme dans PF1 correspondent à des lots d’informations traitées,
d’autres comme dans PF9 correspondent exactement à des mouvements portés dans un
seul événement. PF9 émet à chaque fois un événement « stock à jour », compte rendu du
fait qu’un stock d’un produit a été mis à jour dans la base d’informations.
PF10 consomme à 17h°° l’ensemble des événements de ce type qui on été

émis dans la journée et effectue son TTT à partir du lot des données à jour se trouvant
sur la disquette « stock à jour ».PF10 est un TTT BATCH enfin de journée dont le lot mis
à jour par des transactions survenues de manière aléatoire dans la journée. Notons que
ce lot est un lot des données permanentes trouvées dans la base d’informations
c)- EVENEMENTS
Un événement contributif participe au déclenchement d’une PF. Un événe‐
ment émis est ce qui se passe à l’issue de la PF, soit dans l’UE (événement résultat), soit
pour être consommé par une PF suivante (événement interne). Evénement et flux sont
étroitement liés. L’événement peut être porteur du flux lui‐même ou, et peut être sim‐
plement un événement du type « un flux est disponible dans la base d’informations » ou
encore, et peut être un lot d’événements accumulés antérieurement et porteur chacun
des mouvements.
Les événements peuvent être conceptuels (s’ils figurent sur le MCT) ou bien
organisationnels (s’il s’agit d’événements intermédiaires tels que “proposition des
commandes éditées’’). Certains événements organisationnels sont simplement des évé‐
nements du type « ressource disponible » ou « tel moment est arrivé » et ne figurent pas
‐ 104 ‐
sur le diagramme pour ne pas alourdir la présentation (mais on les trouve implicitement
dans les colonnes “déroulement et L/T’’). Certains événements ne sont porteurs d’aucun
mouvement. Exemple : « événement période d’inventaire ».
‐ 105 ‐
Des nombreux événements sont directement porteurs d’infos qu’il faut dé‐
crire (exemple : événement « commandes éditées », « ajustement occasionnel », « livrai‐
son fournisseur OK » devant donner lieu à la description de données figurant sur la
commande. Concernant l’ajustement ou porté sur le Bon de livraison du fournisseur.
Cette description sera celle :
 Des écrans en entrées ou en sorties

 Des documents d’entrées
 Des états de sorties
VII.3.‐ PRESENTATION DE L’’EXEMPLE
VII.3.1.- DESCRIPTION DU NIVEAU CONCEPTUEL

Rôle du système
Il s’agit d’un système de gestion de stock comportant deux processus :
 La tenue de stock
 L’approvisionnement
Ce système est en étroite liaison avec le système de gestion des commandes clients.
Règles de gestion
RG 1 : un produit peut être en stock dans plusieurs magasins

RG 2 : un produit en magasin peut être mouvementé plusieurs fois par diminution ou
augmentation de la quantité en stock.
RG 3 : un produit est vendu par un seul fournisseur pour tous les magasins
RG 4 : le système concerne une entreprise de distribution qui achète des produits aux
fournisseurs pour les vendre à ces clients
RG 5 : une commande de réapprovisionnement concerne un fournisseur
RG 6 : on passe une commande à un fournisseur dans l’un de deux cas suivants :
‐ 106 ‐
 Un produit commandé par un client à un magasin est en rupture de stock

dans ce magasin
 Dans un magasin, on a un produit : stock+ Total commandé aux fournis‐
seurs stock minimum
On commande alors Q=stock maximum ‐ (stock+total commandes). Autrement dit, pour
chaque produit d’un magasin, on définit un stock maximum et un stock minimum et dès
que le niveau de stock tombe en dessous du stock minimum, on commande ce qu’il faut
pour remonter au stock maximum.
RG 7 : les livraisons des fournisseurs sont contrôlées par comparaison avec les com‐
mandes. Toute livraison non conforme est refusée et retournera chez le fournisseur
RG 8 : on tient à jour un stock théorique d’après le mouvement du stock
RG 9 : les mouvements de stock sont :
a) Hors période d’inventaire :
 Livraison fournisseur : stock+Qté livrée
 Bon de livraison client : stock=stock‐qté livrée
 Retour de marchandises clients : stock=stock+Quantité retournée.
b) Pendant ou hors période d’inventaire :
Ajustement (suite à l’inventaire ou à un écart occasionnel constaté)
Stock=stock écart ente stock réel et théorique.
Les retours des marchandises fournisseurs n’entrent pas en jeu car les mar‐
chandises sont retournées avant d’avoir été prise en compte dans le stock théorique.
Chemin à suivre :
 Règles de gestion
 Schéma de circulation
 Graphe des flux
 Epuration du graphe
 Construction du MCT
‐ 107 ‐
VII.3.2.- MCD
Le modèle conceptuel des données est indiqué ci‐après :
COMMANDE 1, n COMPOSER DE
N° Cde, Date Quantité
1,1 0, n
PASSER A PRODUIT
Ref, design, PU vente
0, n
0, n
STOCKER
STOCK
0, n
0, n
MAGASIN
N° Mag, adresse
1, n 1, 1
VENDU PAR
FOURNISSEUR
code F, nom F, Rue F, ville F
‐ 108 ‐
VII.3.3.- MCT
.‐ PROCESSUS APPRO
Processus
Processus Tenue stock Gestion Cdes clients
Produits sous Produit manquant

stock mini
OU
Détermination des com‐

mandes à fournisseur
TOUJOURS
Commande
fournisseur
Livraison fournisseur
ET
Contrôle livraison
OK PAS OK
Livraison four‐
Livraison
nisseurs accep‐
fournisseur
tée
refusée
Processus
tenue stock
REMARQUES :
 Le MCT est indépendant du MCD

‐ 109 ‐
 Le MCT a des processus et leur nombre correspond au nombre des MCT à tracer.
VII.3.4.‐ PROCESSUS TENUE DE STOCK
Période d’inventaire
Communication du
stock théorique
Toujours
Etat d’inventaire
PROCESSUS Processus Gestion des

APPROV commandes clients
x
Ecart occasionnel Livraison fournis‐ Retour des Livraison client Inventaire
constaté seur acceptée marchandise effectué
a b c d y
a ou b ou c ou d ou (x et y)
Traitement des mouvements du stock

Toujours stock ˂ stock mini
Produit sous
Stock à jour
stock mini
PROCESSUS
APPRO
‐ 110 ‐
VII.4.‐CONSTRUCTION DU MODELE ORGANISATIONNEL DE TRAITEMENT (MOT)
REGLES D’ORGANISATION
Des choix d’organisation sont effectués, desquels découlent certaines règles
fixant les orientations générales.
 RO1 : les services achat et le magasin sont équipés des micro‐ordinateurs

compatibles pour pouvoir s’échanger des disquettes. Le service commer‐
cial dispose d’un matériel analogue.
 RO2 : pour la détermination des commandes à passer au fournisseur, le
micro‐ordinateur du service d’achat édite des propositions de commande
qui sont analysées par le responsable en vue d’une validation ou d’une
modification. Ces opérations doivent être faites le matin.
 RO3 : les commandes valides sont éditées :
a) Dans l’ordre des fournisseurs concernés pour être expédiées à
ceux‐ci
b) Dans l’ordre des magasins concernés pour être transmises à ceux‐
ci.
 RO 4 : à chaque livraison fournisseur, le magasinier contrôle la marchan‐
dise livrée en la comparant à la marchandise commandée figurant sur la
commande au fournisseur
 RO 5 : La MAJ du stock s’effectue :
a) Le matin à 9h°° pour les sorties de stock. Celles‐ci (doubles de Bons
de livraison) proviennent du processus “gestion des commandes
clients’’ et sont transmises au magasin concerné sur une disquette.
b) En temps réel (transactions en mode conversationnel) à tout autre
moment de la journée de travail pour les autres mouvements, les
anomalies sont immédiatement recyclées.
 RO 6 : le courrier est expédié à 12h°°.
 RO 7 :
 L’inventaire est manuel
 Le vendredi soir précédent, il y a édition de l’Etat du stock sur or‐
dinateur
 RO 8 :
‐ 111 ‐
 Durant tout le week‐end, et au vue de ces listings, le magasin com‐

plet mobilise toute son énergie à inventorier les casiers et à noter
les écarts constatés sur l’Etat du stock édité.
 La saisie de ces écarts pourra se faire dans les jours qui suivent
 RO 9 : dans un magasin, tout produit doit pouvoir être rangé dans un seul
casier et tout casier ne doit contenir qu’un seul produit
VII.5.‐ DETERMINATION DES PROCEDURES FONCTIONNELLES (PF)

La première étape du modèle organisationnel des traitements consiste à découper les opérations
en procédures fonctionnelles, une succession de traitements déclenchée par un événement.
Il s'agit donc d'associer dans un tableau :
 les procédures fonctionnelles
 l'heure de début et de fin
 le lieu du poste de travail
 le responsable du poste de travail
 les ressources du poste de travail
Procédure temps poste de travail
début durée lieu responsable ressources
Compte tenu des règles d’organisation, on est amené à affecter les actions
d’une opération à un ou plusieurs postes de travail. Il faut donc découper chaque opéra‐
tion en procédures fonctionnelles pour lesquelles on précisera le poste de travail (ma‐
nuel ou automatisé) et le déroulement.
Tableaux des procédures fonctionnelles : processus APPRO et PROCESSUS TENUE

DE STOCK
Les tables ci‐dessous sont complétées à base des règles d’organisation. Pour
le MOT, il faut voir le nombre d’opérations qu’il y a afin d’en éclater les actions.
TABLEAU DES PROCEDURES FONCTIONNELLES : PROCESSUS APPRO

PF DEROULEMENT ACTIONS NATURE POSTE DE TRAVAIL
DEBUT DUREE LIEU RESPONSABLE RESSOURCES
MAXI
PF1 9h°° 30’ Edition propositions AB SA Acheteur ad‐ Micro
commandes joint
PF2 9h30’ 1h30’ Analyse propositions M SA Acheteur Acheteur
PF3 11h 30’ Validation AC SA Acheteur Adjoint+micro
PF4 11h30’ 30’ Edition commande AB SA Adjoint Micro
PF5 12h 30’ Envoi commandes M SC Gardien Coursier
PF6 12h30’ X’ Envoi aux magasins M SA Adjoint Coursier
PF7 10’ Contrôle livraison M MG Chef magasi‐ Chef+aide ma‐
nier gasinier
‐ 112 ‐
SA : service achat M : manuel
AC : automatisé conversationnel SC : service courrier
AB : automatisé Batch MG : magasin
TABLEAU DES PROCEDURES FONCTIONNELLES : PROCESSUS TENUE DE STOCK

PF DEROULEMENT ACTIONS NATURE POSTE DE TRAVAIL
DEBUT DUREE LIEU RESPONSABLE RESSOURCES
MAXI
PF8 9h°° 15’ MAJ par sortie de AB MG Aide Micro
stock
PF9 9h15’ à 5’ MAJ stock par autre AC MG Chef ou aide Micro+chef ou
17h mouvement de stock aide
PF10 17h 10’ Détermination pro‐ AB MG Aide Micro

duit sous stock mi‐
nimum
PF11 17h10’ X Transmission pro‐ M MG Aide Coursier
duits sous stock mi‐
nimum à service
d’achat
PF12 Jour fin 1h Edition Etat de stock AB MG Aide Micro
d’anné
e, ven‐
dredi
17h
PF13 Jo+17h 2jours Détermination des M MG Chef Chef+aide
x 12 écarts par inventaire
physique
‐ 113 ‐
VII.6.‐ DIAGRAMME D’ENCHAINEMENT DES PROCEDURES

Le schéma du fonctionnement du MCT se traduit après décomposition des
opérations en PF par un diagramme d’enchaînement des procédures
PROCESSUS APPRO
Déroule‐ ENCHAINEMENT DES PROCEDURES NA‐ Poste de tra‐

ment Début TURE vail LIEU
Durée maxi Responsable
RESSOURCES
9H 30’ AB SERVICE
PROCESSUS Ges‐
tion Cdes clients
ACHATS
PF 11
Disquettes Pdts Disquette Pdts

Sous stock mini manquants trans‐
ACHETEURS
Transmise mise ADJOINT
OU MICRO
PF1 Edition proposition

Toujours
Disquette proposition des

commandes émises
PF 3
9H30’ M SERVICE
Disquettes proposition des
1H 30’ commandes éditées
ACHATS
ACHETEUR
ACHETEUR
PF2 Analyse des propositions
Toujours
A
‐ 114 ‐
11H 30’ AC SERVICE

PF1 ACHATS
ACHETEURS
A ADJOINT +
Disquette Proposi‐ MICRO
tion Commandes
émises Propositions anno‐
tées et complétées
ET
PF3 Validation Modifications
Toujours
11h30’ AB SERVICE
30’ Disquette commandes
ACHATS
fournisseurs émise
ADJOINT MI‐
CRO
PF 4 Edition des commandes

toujours
Commandes triées/
PF 6
Magasin
12h°° M SERVICE COU‐

30’ Commandes triées / RIER
Fournisseurs GARDIER
COURRIER
PF 5 Envoi postal
toujours
Commandes envoyés
‐ 115 ‐
12h30’ va‐ M SERVVICE ACHAT

riable PF4 ADJOINT
Commandes Four‐ COURRIER
nisseurs/Magasins
PF6 Transmission au Magasin

Toujours
Commandes transmisses
9h M MAGASIN
10 Arrivée du Bon de CHEF MAGA‐
livraison fournisseur SINIER
ET CHEF‐AIDE
PF7 Contrôle de la Livraison

OK PAS OK
Retour Marchandises
Livraison Fournisseur au Fournisseur
OK
PF9
La PF concerne un poste de travail. Une action est ainsi un ensemble des ACTIONS
 Espace=poste
 Temps=lieu
 Pour tracer, on donne un enchaînement, on met la procédure Fonctionnelle puis
on voit les événements entrés et ceux qui en sortent. La PF concerne un poste de
travail
‐ 116 ‐
PROCESSUS TENUE STOCK

9H15’ AB MAGASIN
PROCESSUS
AIDE
Gestion commandes clients
MICRO
Disquette Bons de livrai-

sons clients transmise
PF 8 MAJ du stock à partir des sorties de stock

Toujours
JOUR AC MAGASIN
9H15’ T MAJ par sortie PF 7 CHEFouAIDE
17H5’ Stock effectuéé +MICRO
g
PROCESSUS Livraison four‐
Gestion de com- nisseur OK
c
mandes clients
Ecart occasionnel
constaté
Retour marchan-
dises client d
PF 13
Jour J<>Jo+1 et Jo+2 Ecart d’après

invetaire
a b e
a ET g ET (b ou c ou d) ou e
PF 9 MAJ du Stock
Toujours
Stock à jour
A
‐ 117 ‐
12H AB MAGASIN
10’ A AIDE‐
MAGASINIER
MICRO
PF10 Détermination des Produits de Stock < Stock mini
Toujours il y en a
Disquette Stock à jour transmissible
17H10’ M MAGASIN
variable
Disquette produits
Sous stock minimum
PF 11 Transmission à service achat

Toujours
Disquette
transmise
PF 1
‐ 118 ‐
Jour Jo AB MAGASIN
Fin année
Vendredi Période AIDE ‐
A 17h 30’ MAGASINIER
1h
d’inventaire
MICRO
PF 12 Edition Etat du stock

Toujours
Jours Jo+1 M MAGASIN

Jo+2 CHEF MAGA‐
A 7h Etat du stock Edité SIN
12H + AIDE
Stock physique
réel repéré
ET
PF 13 Inventaire physique et
détermination des écarts
Toujours
Ecarts notés
PF 9
‐ 94 ‐
VII.7.‐ GRAPHE DE CIRCULATION DES INFORMATIONS
PROC APPRO TENUE DE STOCK
T/L SA SC MAGASIN EXTERIEUR
J 9H Manquant
2 PSM Service commercial
o o BL clients
o
o o o Service commercial
PF 1 PF 8
micro micr
o
J15’
9H30’ Proposition Commandes
90’ PF 2 acheteur
Propos Annotés
BL Fournisseur
1 Fournisseur
10’ PF7 Chef + Aide
BL OK RM Fournisseur
RM Client
9H15’< TX17
Ecart
Occasionnel 3 Client
5’ PF 9
Micro
Stock o
à jour o 4
J Propos
11H o
o
30’ PF 3
Micro
o----------
Cours co
PF 4 Micro
‐ 95 ‐
J 30’ PF 4
11H30 Micro
12H J 30’
Commandes
Fournisseur
PF 5
Cer
Fournisseur
12H 30’ Cdes

Mag
PF 6 Commandes
X’ Cer
1
T/L SA SC MAGASIN EXTERIEUR
J 17H 4
o
o
PF 10 10’
MICRO
oStock à jour Service

o Commercial
PSM
o
5
H10
PF 11 X’
Cer
Jo 17H 1H
PF 12
30’ micro
5
Etat du Stock
JO + 1 12H
Jo + 2
7H PF 13
Chef + Aide
Ecarts
‐ 96 ‐
Ecarts notés sur Etat de

Stock
T=temps Frs=fournisseur
RM=retour des marchandises Mag=magasine
BL=Bon de livraison cdes=commandes
Cer=coursier PSM=produit sous stock minimum
L=Lieu
3
SYMBOLES UTILISES
procédure automatique
Procédure manuelle (si la conversationnelle (ressource,
Nom de PF
ressource n’est pas homme+machine)
ressource un ordinateur) ou automatique
Support papier
O Disquette
O
Cassette
Support ’’homme’’ lorsque l’information est

Disque transmise ou émise par une personne
Bande
chemin parcouru par l’information
télétransmission
Ce schéma se déduit du MCT en intégrant les contraintes liées à

l’organisation. Une opération du MCT se décompose en enchaînement des événements à
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 97 ‐
des attentes conceptuelles (c.à.d. ça doit provenir du MCT). Des événements liés à des
attentes organisationnelles sont apparus.
Ex : Evénements commande transmise. D’autres événements correspondant à des at‐

tentes organisationnelles sont implicites, ils ne figurent pas sur le diagramme pour ne
pas l’alourdir. Ex : pour la procédure F6, il faut lire :
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 98 ‐
Cdes fournis‐
seurs / Mag 12h30’ Coursier
disponible
ET
PF6
Il s’agit d’attente de disponibilité des ressources et des contraintes de temps.

Une procédure reste un ensemble interruptible d’action. Mais des interruptions nou‐
velles liées au poste de travail et aux contraintes du déroulement on fait leur apparition.
.‐ GRAPHE DE CIRCULATION
Le graphe de circulation se place d’un autre point de vu que celui du dia‐
gramme d’enchaînement. Celui‐ci montrait à partir desquels événements une procédure
était déclenchée. Le graphe de circulation lui, montre quelles sont les informations trai‐
tées par la procédure. Il met en évidence la circulation des infos dans l’espace et le
temps.
Les colonnes représentent les lieux et, les lignes des instants où la procédure
se déclenche. On fait figurer dans un rectangle le nom de la procédure fonctionnelle PF
et on regarde la durée maximum d’exécution. Les flèches en amont figurent les mouve‐
ments traités (mouvement mémorisés dans la base d’informations tel que les produits
manquants mémorisés sur disquette, ou mouvements portés par les événements) ou
encore les lots d’informations traitées (Ex : stock à jour sur disquette pour repérer les
produits en dessous du stock minimum, par exploration des stocks des tous les pro‐
duits). La confrontation des procédures dans l’espace et dans le temps avec indication
des ressources utilisées permet de s’assurer qu’une même ressource n’est pas utilisée
deux fois en même temps et au même endroit.
Les ressources permanentes telles que les fichiers disponibles en perma‐

nence dans un lieu ne constituent pas des contraintes de déclenchement et ne se trou‐
vent pas dans la synchronisation. Le graphe de circulation met également en évidence
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 99 ‐
les supports utilisés. Les supports suivis d’une flèche représentent les données traitées
(flux entrants). Ceux qui sont précédés d’une flèche correspondent à des résultats, à la
sortie de la procédure fonctionnelle (flux sortants).
VII.8.‐ DESCRIPTION DETAILLEE DE PF
VII.8.1.- OUTILS
Pour décrire de manière détaillée la PF, on utilisera la procédure suivante :
 Fiche de description des procédures : pout toute procédure manuelle ou

automatisée.
 Description des mouvements portés par les événements :
 Dessin des états de sorties
 Documents de saisie
 Grille d’écrans
 Document manuels
 Diagramme de réparation des tâches entre l’homme et la machine. Pour
les transactions conversationnelles (dialogue homme‐machine)
 Description de TTT automatique :
 Tableau des décisions lorsque la PF présente une structure alterna‐
tive très marquée.
 Grille de contrôle dans le cas de transaction.
L’utilisation des ces outils se fera selon la nature du PF :
 Procédures manuelles :
o Fiche de description
o Documents manuels, bordereaux,…
 Procédures automatisées :
o Fiche de description
o Tables de décisions éventuelles
o Bordereaux de sortie dans le cas de l’encodage.
o Etat de sortie pour les éditions
o Outil spécifique au PF conversationnelle :
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 100 ‐
 Diagramme de réparation entre l’homme et la machine

 Grille de contrôle
N.B : le choix de détails tels que : la forme générale des documents et des
écrans doit avoir l’approbation des utilisateurs directes et donc être défini au moment
de « l’analyse fonctionnelle détaillée ». Il faudra en particulier être attentif aux pro‐
grammes ergonomiques (adaptés à l’utilisateur pour plus de confort) lors de la concep‐
tion des écrans.
VII.8.2.- EXEMPLES
‐ CAS DE LA PROCEDURE PF9
FICHE DE DESCRIPTION DE LA PROCEDURE PF9
NATURE : conversationnelle
OBJET : MAJ immédiate du stock
EVENEMENT TRAITES : Bon de livraison fournisseur
Retour de marchandises client
Ajustement du stock sur écran
DONNEES UTILISEES : cfr diagramme de réparation de tâches entre l’homme et la machine
et la Description des écrans
EVENEMENTS RESULTATS : stock à jour
DONNEES SORTIES : cfr diagramme de répartition de taches entre l’’homme et la ma‐
chine et description des écrans
ACTIONS SUR LA BASE D’INFORMATIONS :
CONSULTATIONS : recherche du produit et de son stock dans le magasin
ACCES par référence ou désignation
MAJ : cfr TABLE DE DECISION
a).‐ DESCRIPTION DES ECRANS PROCEDURES PF9
Taper N° du magasin et af‐

N°MAGASIN ?01 REAUNIR ficher libellé magasin
CRITERE D’ACCES
1. PAR REF
2. PAR DESIGNATION Taper 1 ou 2
CHOIX ? 1
RM : RETOUR MARCHANDISES CLIENTS
BL : BON DE LIVRAISON FOURNISSEUR
Taper RM, BL ou AJ
AJ : AJUSTEMENT
TYPE DE MOUVEMENT ?…
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 101 ‐
DESIGNATION ? CHEMISE Si accès par désignation, on

Tape par exemple : CHEMISE
REF DESIGN PU DE VENTE Affichage

X01 CHEMISE 150
Taper réf correspondante
X23 CHEMISE 150
REF ? X01
REF ? X01 Si accès par réf.
Affichage
TYPE DE MOUVEMENT
REF Entrée quantité livrée ou stock
DESIGNATION réel
PU VENTE
Seulement si BL
QUANTITE ?
N°CDE FOURNISSEUR
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 102 ‐
CONCLUSION :
Comme nous l’avons dit à travers ce cours, MERISE est une « Méthode d’analyse
et de conception structurelle qui a vu le jour en 1978 et mise au point par le Ministère
de l’Industrie de la France. Elle est très répandue. C’est une Méthode d'analyse d'un sys‐
tème d'information qui vise à remplacer un système manuel d'une organisation par un
système automatisé du traitement de l'information. Cette méthode a pour but, dans un
premier temps de démontrer les éventuels problèmes du système en place et, dans un
second temps, d'apporter des améliorations au système.
Les facteurs pris en compte dans l'étude sont le traitement, la collecte, la saisie, la
transmission et le stockage de l'information. À l'aide de schémas et graphiques, on pour‐
ra analyser la transmission grâce au MCC, analyser et concevoir la structure du stockage
et la collecte avec les MCD et MLD et, enfin, concevoir la saisie et le traitement des don‐
nées avec les MCT et MOT. Une dernière partie consiste à mettre en œuvre le résultat de
l'analyse en suivant les MPD et MPT (Voir MERISE 2). Cette méthode tend à disparaître
car elle démontre des signes de faiblesse. Certains disent qu'elle est parfois inexacte et
n'apporte pas de solutions réelles ou elle est inappropriée, surtout dans une conception
objet où elle est remplacée par la méthode UML. Une Méthode MERISE2 permet la con‐
ception objet mais n'est en fait qu'une mise à jour de MERISE.
MERISE est donc une méthode d'analyse et de conception des SI basée sur le
principe de la séparation des données et des traitements. Elle possède un certain
nombre de modèles (ou schémas) qui sont répartis sur 3 niveaux :
 Le niveau conceptuel,
 Le niveau logique ou organisationnel,
 Le niveau physique.
L’étudiant devra lire et relire ces notes pour une compréhension parfaite de cette
méthode qui permet un formalisme clair d’un système d’information. La modélisation du
système d’information par MERISE permet une parfaite compréhension de son fonc‐
tionnement par le chef d’entreprise et par les futurs utilisateurs. La maîtrise de cette
méthode s’impose car c’est grâce à elle que l’étudiant sera capable de concevoir une
Base de données relationnelle.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
‐ 103 ‐
BIBLIOGRAPHIE
 La méthode Merise : H. Tardieu, A. Rochfeld, R. Coletti aux Ed. d’organisation

 Parlez-vous MERISE : H. Tardieu
 AMC*Designor : Mise en œuvre de merise – Gilles GUEJ aux Editions Eyrolles
 www.commentcamarche.net: La méthode Merise.
-http://cyril-gruau.developpez.com/merise/
-http://sql.developpez.com/modelisation/merise/
‐ http://merise.developpez.com/faq/
 Aho, A., Ullman, J. (1993). Concepts fondamentaux de l’informatique. Paris Dunod.
 Acsiome (1990). Modélisation dans la conception des systèmes d’information. Paris, Masson.
 Akoka, J. (2001). Conception des bases de données relationnelles en pratique : concepts,
méthodes et cas corrigés, I. Comyn-Wattiau. Paris Vuibert.
 Benett, S., Mcrobb, S., Farmer, R. (2001). Object-Oriented Systems Analysis and Design using
UML. McGrawwHill.
 Date, C. (1998). Introduction aux bases de données, 6e édition, Thomson international
publishing.
 Gabay, J. (1993). Apprendre et pratiquer Merise. Paris, Masson. Galacsi (1989). Conception de
bases de données : du schéma conceptuel au schéma physique. Paris, Dunod.
 Gardarin, G. (2000). Maîtriser les bases de données. Paris, Eyrolles.
 Guedj, G. (1996). AMC*Designor, mise en œuvre de MERISE. Eyrolles.
 Hainaut, J. (1994). Bases de données et modèles de calcul – Outils et Méthodes pour
l’Utilisateur. Paris, InterEditions.
 Matheron, J. (1994). Exercices et cas pour comprendre MERISE. Paris, Eyrolles.
 Matheu, P. (2000). Des bases de données à l’Internet. Paris, Vuibert
----------------------------------------------------------------------------------------------------------------------------------------------------------------

Cours de MERISE G2 Jour ISC 2021 - 2022-1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours de MERISE G2 Jour ISC 2021 - 2022-1

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE DEMOCRATIQUE DU CONGO

ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE

INSTITUT SUPERIEUR DE COMMERCE

COURS DE METHODE D’ANALYSE DES

Cours Conçu et dispensé par

ANNEE ACADEMIQUE 2021‐2022

Chap I : NOTIONS PRELIMINAIRES SUR LA METHODE MERISE

Qu'est-ce qu'une méthode ?

Qu’est-ce que MERISE ?

I.2.‐ OBJECTIFS DU COURS

 Concevoir et d’organiser le système d’information d’une organisation.

- l'imitation : il copie sur un support des relations perçues sur l'environnement

 Caractéristiques fondamentales des modèles

Le caractère abstrait d'un modèle doit notamment permettre :

 de faciliter la compréhension du système étudié

I.4.‐ HISTORIQUE DE LA METHODE MERISE JUSQU’AUX METHODES OBJET

1. Les premières méthodes d'analyse (années 70)

Chap II : SYSTEMES D’INFORMATION

II.1.1.- Définitions d'un système

Une entreprise est donc un système décomposable en trois sous‐systèmes : le sous‐

Système d’information information‐décision

Une telle décomposition prend bien en compte :

- la différence de besoin en matière d’information des modules opérants et pilotes,

II.1.2.- LE SYSTEME D’INFORMATION D’UNE ENTREPRISE OU ORGA-

SCHEMA DU S.I. D’UNE ENTREPRISE

Le SI est composé d’éléments divers (employés, ordinateurs, règles et méthodes…) chargés de

II.1.3.- ARCHITECTURE ET CONCEPTION D’UN SYSTEME

Le processeur d’information produit des changements dans la base d’information à la réception

Relativement à la conception d’un système d’information, l’architecture présentée ci-dessus induit

- celle de la base d’information (aspect statique)

Le SI est donc la mémoire de l’organisation.

Il contrôle à ce titre un aspect statistique :

Le SI comporte un aspect dynamique :

 Possibilité de mise à jour de données mémorisées dans la base d’informations

Cette partie active du SI constitue le processeur d’informations (autrement dit le sous-

- Un système d’information intégré au système opérant ne décrit plus le fonctionnement du

II.1.4.- ACTIONS ROGRAMMEES ET DECISIONS

Exemple : la connaissance écritures comptables détermine de manière unique la nouvelle balance.

Il existe une règle unique parfaitement explicitable (formalisable) permettant de déduire la

 Des actions programmées

II.2.- SYSTEME D’INFORMATION AUTOMATISABLE

Pour qu’un SI soit automatisable, il doit être formalisable. La connaissance des

Par exemple : les décisions de réapprovisionnement peuvent s’effectuer par l’utilisation

II.3‐ SYSTEME AUTOMATISE D’INFORMATION (SAI)

II.3.2.- LES TROIS NIVEAUX D’ABSTRACTION D’UN SI

Pour les traitements automatiques, on étudie les découpages en programmes.

NIVEAU TRAITEMENT DONNEES CHOIX

II.3.3.‐ Cycle d'abstraction de conception des S.I.

La conception du système d'information se fait par étapes, afin

Cette succession d'étapes est appelée cycle d'abstraction pour

Enfin, le modèle physique reflète un choix matériel pour le système d'information.

Niveau Statique (données) Dynamique (traite‐

ou logique (OU ?) (QUI ? QUAND ?) QUI ? QUAND ? OU ?

II.3.4.‐ Système d’Information et Système Informatique

Il ne faut toutefois pas confondre un système d'information avec un système informa‐

Parmi les informations qui appartiennent au système d’information, certaines doivent

- le schéma directeur : dont le rôle est de définir, de manière globale, la politique

Globalement Schéma directeur

Par projet Etude détaillée

Cette démarche lourde et parfois complexe est adaptée à l’automatisation de « gros

CHAPITRE III : LE MODELE CONCEPTUEL DE COMMUNICATION (MCC)

Un partenaire est un intervenant extérieur à l'entreprise. Il peut être perçu de manière

Ils sont l'application du troisième principe de systémique : l'existence de systèmes d'information