1

MÉTHODE D’ANALYSE INFORMATIQUE I : MERISE

PRÉSENTATION DE L’ANIMATEUR
Elle sera animée par Le Chef de Travaux Ir KATO ZAWADI Marc
OBJECTIF DE L’ELEMENT CONSECUTIF
Fournir les principes de la modélisation des systèmes d'information et initier
l’étudiant au formalisme de modélisation des données selon la méthode
MERISE.
LES COMPÉTENCES QUE L’UE VA VOUS PERMETTRE DE DÉVELOPPER
Ces compétences visées dans cet élément consécutif sont les suivantes :
 Mener une étude informatique de la définition de besoin jusqu’à la
réalisation d’un Système d’Information informatisé.
 Acquérir une expérience de conception et de réalisation informatique à
travers un projet de développement d’un système d’information.
LE DESCRIPTIF DE L’UNITE D’ENSEIGNEMENT
Cette unité d’enseignement est de4 crédits où nous aurons à parler de :
1. Les concepts de base
2. Méthode de conception d’un système d’information
3. Les modélisations d’un système d’information avec la méthode MERISE
LE DÉROULEMENT DE L’UNITE D’ENSEIGNEMENT
Théories +TD(interrogation) +TPE : 30 heures.
Travail pratique : 15 heures.
MATÉRIELS DU COURS
Syllabus en dur + Ordinateur.
MODE D’ÉVALUATION
Interrogations ou travaux dirigés, Travaux pratiques, Examen à syllabus et
notes fermés et la présence au cours sur 1 pts.
Contacts :
 Appel et SMS : +243 811586171
 WhatsApp : +243 892779615
 2

REFERENCES BIBLIOGRAPHIQUES
 COURBON J.C.,« Systèmes d’Information : Structuration, Modélisation
et communication », INTEREDITION, 1998.
 [Link], « Conception des Systèmes d’Information », EDITION
EYROLLES , 2003
 HUBERT TARDIEN, « Méthode MERISE », Tome I, Tome II, EDITION LES
ORGANISATIONS, 1989.
 NANCY & AUTRES, « Ingénierie des Systèmes d’Information, Ed.
SYBEX, 2000
 XAVIER CASTELLANI, « Méthode d’analyse en Informatique », T0, T1,
T2, 1998
 SEBa Brifa, « Merise : « Concepts et mise en œuvre », collection
Ressources Informatiques, Editions ENI, 2003
 CAUVET C., ROSENTHAL-SABROUX C., Ingénierie des systèmes
d'information, Informatique et système d'information, Hermès Science
Publications, 2001.
 3

Chapitre premier : LES CONCEPTS DE BASE

1.0. Introduction

Le développement d'applications dans le domaine de l'informatique de gestion

est aujourd'hui généralement entendu comme contribution au développement
des systèmes d'information. Le système d'information intègre les dimensions
organisationnelles, humaines et technologiques de la gestion de l'information
d'entreprise. Ainsi, le développement de systèmes d'information toujours plus
complexes avec des problématiques beaucoup plus ambitieuses que par le
passé, caractérise-t-il aujourd'hui le terrain d'action de l'informatique de
gestion ?
1.1. Systèmes
Il existe plusieurs définitions du mot « système ».
Définition1
Un système est un ensemble d’éléments en interaction dynamique organisés
en fonction d’un but. (JOEL DE ROSNAY)
Définition 2
Un système est un ensemble d’objets et des relations entre ces objets et entre
les attributs de ces objets. (HALLEN)
Définition 3
Un système est :
- quelque chose (n’importe quoi),
- qui fait quelque chose (activité, fonction),
- qui est dotée d’une structure,
- qui évolue dans le temps,
- dans quelque chose (un environnement)
- pour quelque chose.
1.2. Système d’information
Un système d’information peut être défini comme l’ensemble des informations
circulant dans une entreprise et les moyens mis en œuvre pour les gérer.
 4

Du point de vue structure, un système est structuré de la manière suivante

Sous – Système
de Pilotage

Sous – Système
d’information

Sous – Système
opérant

 Un sous - système de pilotage est constitué de décideurs comme le comité

directionnel. Ils prennent des décisions stratégiques à court, moyen et long
terme et donnent des ordres au sous – système opérant.
 Un sous - système d’opérant appelé aussi sous – système opérationnel, est
constitué des exécutants. Ils exécutent les ordres venant du sous-système
de pilotage.
 Un sous – système d’information (système d’information) est le trait d’union
entre le sous-système de pilotage et le sous – système opérant. Ainsi, le sous
– système d’information permet de traiter les informations. Notons que le
but poursuivi par l’informaticien est d’améliorer le sous – système
d’information.
1.3. Rôle des Systèmes d’Information
Le rôle des systèmes d’information peut être schématisé de la manière
suivante :
Partant de ce schéma, le rôle du système d’information consiste en :
- l’analyse des données internes et externes
- le traitement des données
- la diffusion des résultats
- le stockage des informations
 5

INFORMATION INFORMATION
INTERNE EXTERNE
- Orale - Orale
- Ecrite - Ecrite
- Picturale - Picturale
- autres - autres

Appropriation

Tri des informations :

ANALYSE BRUTE utiles et non utiles

Structuration des
informations utiles

TRAITEMENT
PROPREMENT DIT

Résultat

DIFFUSION

Utilisateurs

D’où, dans la pratique un bon système d’information doit avoir les qualités
suivantes :
- La rapidité : chaque élément du système de l’entreprise doit être en
possession de l’information le plus rapidement possible
- La fiabilité : le système d’information doit être capable de déceler les
anomalies lors de traitement et ne livre que des informations valables.
- La pertinence : le système d’information doit être capable de prendre en
compte toutes les informations qui lui proviennent (certaines d’entre – elles
sont « parasites » et d’autres utiles).
Remarque : Les critères tels que la rapidité de la diffusion, le délai, la forme
(support) de la diffusion doivent être respectés, au niveau de la diffusion.
 6

1.4. Système informatique

Un système informatique est un sous ensemble du système d’information.
C’est l’ensemble des moyens humains, matérielles, algorithmes, méthodes,
procédures permettant le traitement automatique des informations dans les
entreprises ou organisations.
1.5. Classification des systèmes d’information
Dans la pratique, les systèmes d’information peuvent être appréhendés sous
différentes formes :
1.5.1. Selon le degré d’automatisation
On distingue :
- Le traitement manuel : sans l’apport d’un auxiliaire mécanique.
- Le traitement mécanique : A l’aide d’auxiliaires mécaniques pour le
traitement et la diffusion de l’information. Par exemple avec la machine à
écrire.
- Le traitement automatique : L’intervention de l’être humain au niveau du
traitement ou de la diffusion n’est pas exigée. L’homme n’intervient qu’en
amont et en aval. Par exemple avec l’ordinateur.
1.5.2. Selon le degré d’intégration des moyens
 Un Système d’information centralisé : le traitement s’effectue en un seul site
qui peut être le service informatique. Ce type de système informatique tant
à disparaître avec l’évolution de la technologie de l’information (C.T.I.). Les
moyens informatiques sont regroupés en un seul site et les utilisateurs ne
disposent d’aucun matériel. Dans cette architecture, les données sont
acheminées vers le site central par des moyens manuels, puis saisies,
stockées et traitées sur un ordinateur central unique. La diffusion des
résultats informatisés s’effectue à ce site central. Ainsi, l’outil informatique
est entre les mains des informaticiens.
 Un système informatique mixte ou décentralisé : L’architecture distribuée est
caractérisée par une concentration des organes de traitement (unité
centrale) et de stockage sur un ordinateur unique dit ordinateur central.
Les utilisateurs disposent uniquement des terminaux passifs (organes de
communication avec l’ordinateur central) dépourvus de possibilités de
 7

traitement et de stockage. Le traitement s’effectue au site central, la saisie

et la diffusion dans d’autres sites connexes

Terminal
passif

UNITE DE TRAITEMENT

Stockage

 Un système informatique réparti ou architecture répartie : dans cette

architecture appelée aussi architecture décentralisée, les utilisateurs
disposent des organes de traitement et de stockage des données qui peuvent
être reliés entre eux ou à un gros ordinateur. Dans ce cas, les ordinateurs
reliés constituent un réseau dont la topologie peut être sous de bus,
d’anneau ou d’étoile. Cette architecture facilite l’échange des données
informatiques (EDI) entre les utilisateurs selon leurs besoins. Ce type
d’architecture est souvent appelé « client-serveur ». C’est la tendance de la
solution informatique la plus choisie à ce jour.
 8

Mode par site

Mode global

1.6. Domaine, projet, application informatique

Dans la pratique, l’automatisation (informatisation) des systèmes
d’information dans les entreprises ou organisations peut concerner un
domaine, un projet ou une organisation.
Dans le cas de domaine et de projet, on parle de la conception. Dans le cas
d’une application, on parle de l’analyse.
Actuellement, la différence entre analyse et conception tend à se minimiser.
En effet, avant de réaliser une application ou un projet ou un domaine, il faut
toujours analyser, concevoir.
Pour illustrer la différence entre domaine, projet et application informatique,
considérons le schéma du système ci – après :
 9

Domaine d’informatisation

GESTION DES APPROVISIONNEMENTS

GESTION DES STOCKS

Gestion de stocks de
matières premières

Gestion de stocks des

pièces détachées

GESTION DES COMMANDES

A BUNIA

A MAHAGI

AU KOMANDA

Remarques
Le domaine est souvent représenté ou défini à l’échelon supérieur. Ainsi
un domaine peut désigner un service, un département dans une entreprise ou
organisation. Exemple : service des approvisionnements ou gestion des
approvisionnements.
 10

Le projet constitue l’ensemble ou les différentes activités réalisées

(effectuées) dans les services en question. Dans un service, on peut recenser
plusieurs projets d’informatisation rattachés au domaine. Exemple : dans le
domaine d’approvisionnements on peut rencontrer le projet de gestion de
stocks et le projet de gestion des commandes.
Les applications constituent les tâches qui peuvent être réalisées à
l’aide d’un ordinateur ou complètement automatiser. Exemple : gestion de
stocks des pièces détachées.
 11

CHAPITRE DEUXIÈME
MÉTHODE DE CONCEPTION D’UN SYSTÈME D’INFORMATION : MERISE
2.0. Signification
MERISE est un acronyme qui signifie Méthode d’Etude et de Réalisation
Informatique pour le Système d’Entreprise.
2.1. Historique de MERISE
Jusqu’à la décennie des années 1970, l’informatique utilisait les méthodes
d’analyse privilégiant les traitements par rapport au partage des données à
partir des résultats à produire, définir les traitements à effectuer, puis déduire
les données nécessaires pour ces traitements. Ces méthodes présentaient des
inconvénients comme :
- La création des fichiers des données avec des redondances importantes,
- La lourdeur de la mise œuvre de l’informatisation suite à la longueur
importante du processus de conception, de développement et
réalisation,
De ces inconvénients apparut l’idée d’intégration de différentes
applications et celle de concevoir des systèmes intégrant l’ensemble des
activités de l’entreprise.
C’est dans ce cadre d’idée qu’ont émergé :
- La notion de système d’informatisation qui constitue une charnière entre le
système d’information (SI) et système organisé (SO),
- La notion de bases des données rendant ainsi l’information partageable par
plusieurs applications ou traitement.
Dans la recherche d’une méthode de conception du SI, deux voix de réflexion
contribuent au renouveau :
 Approche systématique du SI, modélisant l’organisation et son SI.
 La modélisation des données et des outils pour décrire les données
indépendamment de leur utilisation dans les traitements.
Ces deux voies de réflexions conduisent en France au développement de la
méthode MERISE.
En 1977 sous l’égide du ministère Français de l’industrie, soucieux de
concevoir et de définir une méthode d’intérêt national avec la collaboration des
principales sociétés de services Français et du centre d’étude technique et de
 12

l’équipement animé par Honoré Tardieu un groupe de travailleurs se constitue

et entreprend un système qui :
- Réactualise les acquis sur la spécification des traitements issue des
méthodes traditionnelles,
- Intègre les nouvelles méthodes orientées des systèmes d’informations et
l’approche par des données,
- Propose une démarche, fruit de l’expérience qui doit garantir la rigueur
de la méthode et sa facilité d’application sur le terrain.
Alors la méthode Merise naquit officiellement en 1979, marquant ainsi
l’apparition des méthodes complètes qui ambitionnent de résoudre
efficacement les problèmes posés par la conception des SI adaptés au
fonctionnement des entreprises et technologies informatiques des années
1980.
2.2. Les Principes de base de la Méthode Merise
De l’abstraction à la réalisation d’un Système d’informations, on va devoir
observer sous plusieurs angles de vues l’organisation que l’on étudie. Ces
angles de vues sont appelés les cycles.
MERISE présente dans sa démarche d’analyse trois cycles fondamentaux
selon la vision de chacun des intervenants :
- le cycle de vie,
- le cycle d’abstraction,
- le cycle de décision.
2.2.1. Le cycle de vie
(la vision que peut avoir l’utilisateur de l’évolution du logiciel). Ce cycle décrit
les diverses phases du système d’informatisation.
Il s’occupe de la manière de conduire le projet c’est-à-dire la succession de
phases contrôlables par l’organisation (planning, échéances, moyens
humains)
Ce cycle concerne entre autre :
a. L’analyse/conception où on analyse :
- Le schéma directeur : Etude globale du SI : Découpage en domaines
dans les buts de :
 13

 Définir les grandes orientations politiques et stratégiques de

l’entreprise ;
 Définir les besoins en SI en fonction de la stratégie de
l’entreprise ;
 Fixer les cadres budgétaires, la stratégie des besoins en
personnel et les contraintes diverses liées à l’environnement ;
 Fixer les lignes directrices des développements informatiques ;
 Définir les projets nécessaires à l’élaboration ou l’évolution du
SI ;
- Etude préalable : qui comporte :
 Une analyse critique du système existant (physique,
organisationnel, conceptuel) ;
 Définition des objectifs du nouveau système ;
 Les différents scenarios des solutions informatiques ;
 Un planning de la réalisation.
- Etude detaillée : qui permet de :
 Préciser l’organisation detaillée de la solution retenue ;
 Définir logiquement les données et les traitements informatiques
de la solution ;
 Définir les interfaces : écrans et états de sortie.
b. La réalisation
Elle consiste à produire le logiciel et à le mettre en place. Elle comporte
trois étapes :
 Etude technique : spécifications techniques complètes
 Production de logiciel : Ecriture des programmes et tests
 Mise en service : Installation de l’application informatique
c. La Maintenance
La maintenance du système d’information consiste à l’adapter aux
évolutions de l’environnement : correction des anomalies,
améliorations et évolutions.
 14

2.2.2. Le cycle d’abstraction

(La vision que peuvent avoir les informaticiens de l’évolution du logiciel). Ce
cycle représente la démarche de spécification du système (Organisation
étudiée) ; de l’abstraction de la réalité de l’existant du système, pour en
développer un modèle, et l’informatiser.

Réalité Abstraction Modèle du Système

du
Système Modélisation Informatisation

La conception du système d'information par MERISE 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 traitements, il faut vérifier la concordance entre données et
traitements 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 superflues.
Cette succession d'étapes est appelée cycle d'abstraction pour la conception des
systèmes d'information :

 L'expression des besoins est une étape consistant à définir ce que l'on
attend du système d'information automatisé, il faut pour cela :
 15

 Faire l'inventaire des éléments nécessaires au système

d'information
 Délimiter le système en s'informant auprès des futurs utilisateurs
Cela va permettre de créer premièrement le MCC (Modèle Conceptuel de
la Communication) qui définit les flux d'informations à prendre en
compte.
 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 MOT (Modèle
Organisationnel des Traitements), décrivant les contraintes dues à
l'environnement (organisationnel, spatial et temporel).
 Le modèle logique, MLD (Modèle Logique des Données), représente un
choix logiciel pour le système d'information.
 Le modèle physique MPD (Modèle Physique des Données) reflète un
choix matériel pour le système d'information.
2.2.3. Le cycle de décision
(La vision que peuvent avoir les décideurs de l’évolution du logiciel). Ce cycle
représente le point de vue de tous les décideurs de l’organisation étudiée
quelques soient leur niveau de décision et d’action (point de vue d’un décideur
au sens large). Durant le cycle de vie, des décisions sont à prendre aux
différentes étapes.
2.3. Composants de MERISE
MERISE est une méthode de conception, de développement et de réalisation
de projets informatiques. La méthode MERISE est basé sur la séparation des
données et des traitements à effectuer en plusieurs modèles conceptuels et
physiques.
En effet, l'agencement des données n'a pas à être souvent remanié, tandis que
les traitements le sont plus fréquemment.
Les composants de MERISE sont schématisés par le schéma suivant :
 16

Choix de gestion
S.I.
NATUREL Définition des informations et
des activités

S.I.O
NIVEAU CONCEPTUEL

Choix
NIVEAU ORGANISATIONNEL d’organisation

Types de ressources et
affectations

NIVEAU LOGIQUE S.I.I

Choix du
logiciel

NIVEAU PHYSIQUE Moyens et développe -

ment informatique

Choix
technique

Ressources effectives

- Le niveau conceptuel correspond à la finalité ou aux finalités de

l’entreprise. Il s’agit de décrire à « Quoi ? » sans tenir compte des conditions
d’organisation et technique ;
- Le niveau organisationnel concerne le choix d’organisation à savoir : la
répartition des traitements entre l’homme et la machine, le mode de
fonctionnement en temps réel ou en temps différé, l’affectation des données
et des traitements par type de site organisationnel.
- Le niveau logique concerne la structuration des données selon le type de
système de gestion de base de données à utiliser. Il permet aussi la
structuration des traitements par découpage de procédures de traitement.
 17

- Le niveau physique permet l’implantation ou l’organisation physique des

données dans les mémoires de masse selon le type de SGBD.
A chaque niveau d’abstraction (concept, organisationnel, logique, physique)
pour chaque volet (données et traitements) le S.I. est représenté par un
modèle.
2.4. Modélisation d’un système d’information.
La modélisation d’un système d’information par MERISE nécessite les étapes
suivantes représentées sous forme de tableau :
NIVEAUX DONNEES TRAITEMENTS
Niveau conceptuel MCD MCT
Niveau Organisationnel MOD MOT
Niveau logique MLD MLT
Niveau physique MPD MPT
1. Le MCD (Modèle Conceptuel des Données) : formalise la signification des
informations sur lesquelles repose le système d’information sans
contrainte technique ni économique.
2. Le MCT (Modèle Conceptuel des Traitements) : formalise l’activité du
domaine abordé, sans préciser les ressources, ni leur organisation. Il
s’agit répondre à la préoccupation « comment les traitements seront –
ils organisés ? »
3. Le MOD (Modèle Organisationnel des Données) : précise quelles sont
parmi les données définies au niveau du MCD, celles qui sont prises en
compte par le futur système informatisé où les données sont localisées
(répartition par site organisationnel). Peut – on organiser la BDD en
réseau, de façon hiérarchique, relationnelle.
4. Le MOT (Modèle Organisationnel des Traitements) : Il faut répondre à la
question les traitements organisés sont – ils informatisables ?
5. Le MLD (Modèle Logique des Données) : fournit une description des
données tenant compte des moyens informatiques de mémorisation et
de leur condition d’utilisation par le traitement.
6. Le MLT (Modèle Logique de Traitements) : décrit comment les tâches
informatisées définies dans le MOT précédent sont conçus en termes de
logiciel ? Il s’agit de l’Arborescence de la BDD.
 18

7. Le MPD (Modèle Physique des données) : C’est une description de

la méthode de base de données ou de l’ensemble des fichiers exprimés
dans la syntaxe du SGBD ou un Système de gestion des fichiers adaptés
(SGF adaptés). Il s’agit de l’Implantation de la BDD
8. Le MPT (Modèle Physique des Traitements) : précise pour la réalisation,
les spécifications techniques des différents modules définis au niveau
du MLT. Les modules sont réalisés par les langages de la quatrième
génération. C’est l’architecture technique des programmes.
2.5. Concepts manipulés dans la méthode MERISE
Le tableau ci – après présente les différents concepts manipulés dans
MERISE :
 19

NIVEAU DE CONCEPTS MANIPULES

DESCRIPTION DONNEES TRAITEMENTS
- Objets (entités) - Processus
- Relations - Opérations
CONCEPTUEL - Propriétés - Evénements
- Résultat
MCD - Synchronisation
MCT
- Objets (entités) - Procédure
- Relations - Phase
ORGANISATIONNEL - Propriétés - Tâche
MOD MOT
- Table - Procédure
- Attribut - Tâche
LOGIQUE MRD ( Modèle - Phase
Relationnel des - Fonction
Données) MLT OU MDLT
- Fichier - Application
- Rubrique - Unité de TTT
PHYSIQUE ( Traitement)
MPD - Temps réel ou batch
MPT

2.6. ETUDES PREALABLES OU ETUDE DE L’EXISTANT

2.6.0. Introduction
L’étude préalable détaille le projet défini par le schéma directeur informatique
et aboutit à un avant-projet à la suite duquel le décideur de l’entreprise choisi
de lancer la réalisation, de demander un complément d’étude, ou
d’abandonner le projet.
Le schéma directeur est un document permettant de clarifier les décisions et
de donner une première idée de la chronologie des activités informatiques de
l’organisation.
Spécialement pour les informaticiens, ils précisent la stratégie informatique
de l’entreprise, donc planifier l’informatisation de l’entreprise en moyen ou
long terme.
2.6.1. LA PHASE DE LANCEMENT D'UNE ETUDE PREALABLE
Le lancement d'une étude préalable est une phase importante de la démarche
d'analyse car ici on définit ses paramètres préalables. Une étude préalable
s'appuie soit sur des éléments connus issus d'un schéma directeur, soit sur
l'expression d'un besoin formulée par un utilisateur.
 20

Dans les deux cas, il convient de réactualiser le cadre et la définition des

besoins. Une interview préalable, permet de cadrer convenablement le champ
de l'étude et les contraintes stratégiques.
a. Définir le Projet : cadrage du projet
Avant de lancer l'étude préalable, il est impératif de bien définir le projet en
précisant les trois points suivants :
Quel est le champ de l’étude ?
Quel est le domaine d'activité ?
Quelles sont les grandes fonctions ?
b. Etude d’opportunité
Au cours de cette phase, ont détermine les objectifs du projet et les ambitions
informatiques de l'organisation. Le projet est donc opportun s’il rejoint les
ambitions informatiques de l’entreprise ou s’il résout un problème technique
ou organisationnel.
c. Etude de faisabilité
L’Etude de faisabilité permet de comparer les contraintes (négatifs) et les
atouts disponibles tant dans l’entreprise qu’au niveau des informaticiens pour
la réalisation du projet. Le projet est donc réalisable si les contraintes sont
maîtrisables. Il est donc préférable de s’appesantir sur les points suivants :
 Les contraintes
 Les atouts que présente l’entreprise pour réaliser le projet.
 Les interférences avec les autres projets.
 Les délais impartis pour la réalisation du projet.
 Le budget alloué.
d. Evaluation du projet
Au cours de l'entretien avec la direction, il convient de fixer des limites
financières. Il s'agit de trouver un compromis entre un besoin qui nécessite
un certain volume financier et les moyens à mettre au service de la résolution
de ce besoin.
2.6.2. LA PHASE DE RECUEIL DE L’INFORMATION
a. Introduction
Cette phase a pour but de détecter et détailler la situation réelle de l’existant
et aboutit à une compréhension du fonctionnement actuel du système
 21

d’information concerné par le projet. Cette étape se base toujours sur compte-
rendu d’interview (demandeurs, utilisateurs), exemplaires des documents de
gestion, rapports d’observation, schémas explicatifs (organigrammes, plans,
...).
Cette analyse doit répondre aux questions : Quoi ? Qui ? Qui Fait quoi ? Où ?
Comment ? Les réponses à ces questions permettent de connaitre la situation
réelle de l’organisation.
b. Principes
Le principe que le chercheur doit adopter est d’améliorer les connaissances de
l’observateur du domaine à analyser sur :
 les acteurs internes et externes,
 les circuits d’information,
 les documents,
 les règles observées par les acteurs de la gestion,
 Le vocabulaire technique utilisé dans l’organisation.
Elle fournit aussi aux étapes suivantes de la méthode MERISE du “matériel”,
c’est à dire un inventaire de documents et d’informations.
c. Techniques
La MERISE utilise aussi dans sa démarche des techniques telles que
l’interview, questionnaire, documentaire, …
d. Outils
Le résultat de cette phase se concrétise par l’utilisation de deux outils :
 le schéma de circulation et de traitement de l’information,
 le descriptif de document, des opérations et des postes de travail.
1o) Le schéma de circulation et de traitement de l’information
- Déterminer les Acteurs Internes et Externes
Les acteurs dans un domaine étudié sont les différents acteurs peuvent
être internes ou Externe. Les internes généralement sont ceux qui
manipulent directement l’objet d’étude et acteurs externes sont ceux qui
facilitent la réalisation d’objet d’une manière indirecte.
- Déterminer le circuit d’information ou flux de l’information :
On fait voir ici les différents acteurs et documents portants des
informations inchangées entre ces acteurs. On représente cela sur un
 22

schéma appelé circuit de circulation des informations où les cercles

représentent les acteurs et les flèches représentent les documents.
- Schéma de circulation et de traitement de l’information
Le SCTI est un tableau qui permet de représenter la circulation des
informations et de leurs traitements ; il se présente sous un tableau, les
acteurs et périodicité en en-tête, et portant les documents et les opérations
reliées par les flèches montrant le sens de circulation des informations.
NB : La colonne de périodicité détermine le temps ou la durée de chaque
opération.
2o) Description des postes de travail
Un poste de travail est le lieu dans lequel une personne dispose des ressources
matérielles lui permettant d'effectuer son travail. Dans le contexte plus
restreint informatique, ce terme correspond à l'ensemble des moyens
techniques mis à la disposition d'un utilisateur (écran, clavier, imprimante...),
et par extension l'interface du système d'exploitation.
Notons qu’un poste de travail implique donc des moyens humains et matériels,
le lieu de travail, activités, durée de service voir même des observations.
Une fiche de description de poste de travail permet de décrire les différents
postes de travail responsable des activités de votre projet.
Les fiches de poste de travail nous permettront de présenter l’environnement
organisationnel en présentant les noms, la situation géographique (le lieu) et
la période d’un poste de travail ainsi que :
 Les opérations effectuées, avec des durées d’exécution et volume des
données traitées.
 Les moyens utilisés.
 Les observations sur le fonctionnement du SI surtout les observations
causant le disfonctionnement du système tel que des surcharges,
niveau des moyens humains, type de traitement, ...
 23

NB : Autant qu’il existe des postes de travail ou acteurs internes, on aura

autant des fiches.
3o) Fiche de description des opérations.
Les descriptifs des opérations sont des fiches qui permettent de décrire les
opérations figurant sur les différentes postes du travail en mentionnant le
libellé de l’opération, son type de traitement, sa périodicité, de poste de travail
concerné, le document entré et les documents en sortie et voir même la
description du traitement.
Ces fiches de description permettent de décrire le traitement et de préparer
ainsi leur modélisation dans la phase de l’élaboration de la solution.
 24

NB. Il faut une fiche pour chaque opération. Autant des fiches, autant
d’opérations.
4o) Descriptif de document
Un descriptif des documents c’est une fiche qui permet de décrire toutes les
rubriques de tous les documents élaborés ou tenus par les acteurs internes.
Précisons que cette fiche doit mentionner l’intitulé nom des documents, la
description de la rubrique, le type de la rubrique (numérique, alpha
numérique), contrainte d’intégrité ou mode de calcul), mode d’obtention
(mémoriser=donnée saisie, calculer, induit, rubrique obtenue d’autres
rubriques).
 25

 Donnée : Description détaillée de chacune des rubriques du document

 Type : Type de donnée (AN alphanumérique, N numérique, D date ...)
 C.I. : Explication des contraintes d’intégrité ou du mode de calcul des
rubriques
 Mode d’obtention : L’obtention de l’information demande-t-elle une
mémorisation préalable ou un calcul ? L’information saisie doit-elle
provenir d’autres donc induite ?
2.6.2. CRITIQUE, DIAGNOSTIC DE L’EXISTANT ET PROPOSITION DE LA
SOLUTION
a. Critique, Diagnostic de l’existant
Cette phase consiste à partir des fonctionnements constatés, à dégager et
détailler les besoins réels à satisfaire.
Les remarques qu’expriment les utilisateurs peuvent trouver leurs causes
dans les disfonctionnements des détails de procédures administratives et
informatiques internes.
Pour déceler ces causes, on tient compte de la flexibilité des hommes et du
système, des interférences avec des systèmes existants, on relève les points
forts ; les points faibles ; contraintes et atouts dans l'organisation de
l'entreprise ainsi que les processus qui se déroulent aisément et ceux qui
présentent difficultés de fonctionnement dont l'impact sur le projet n'est pas
négligeable.
 26

La critique présentera de façon objective les processus pour lesquels une

automatisation apportera une amélioration sensible.
On devra se poser les questions suivantes :
 Les documents sont-ils suffisants pour gérer efficacement le système ?
 Les documents disposent-ils toutes les informations ou rubriques
nécessaires ?
 Les types de traitement n’entrainent ils pas des erreurs et des retards
dans la réalisation des opérations ?
 Est-ce que les postes de travail ne sont pas surchargé ou sous employés
compte tenu des durées de travail par jour par jour exigées par les
opérations exécutées par chaque poste de travail
 Est-ce que les moyens alloués (humains, matériels, logiciels) à chaque
poste de travail sont suffisants ou ne sont-ils pas de trop ?
 Les systèmes de stockage des données (SGBD local ou Serveur…) sont-
ils appropriés pour mieux gérer le stockage des données.
 L’architecture du système (client-serveur, distribué, centralisé…) et les
plateformes (Web, Windows, Linux…) sont-ils appropriés pour la gestion
du système d’information ?
 Au terme de la phase de recueil et de diagnostic, l'analyste est en mesure
de valider le champ de l'étude tel qu'il a été initialement défini.
 Il peut éventuellement reformuler le problème à résoudre en tenant
compte des observations qu'il a réalisées dans l'entreprise et au besoin
proposer des solutions organisationnelles et techniques.
b. Proposition d’une ou plusieurs solutions
Néanmoins la confrontation des points de vue entre les utilisateurs et les
concepteurs est une aide précieuse pour évaluer la pertinence des choix
d'orientation.
En plus, l'analyste proposera dans ces choix, les types de solutions techniques
aptes à soutenir l'organisation de la solution telle qu'elle a été évoquée
précédemment, en précisant le type d'organisation et d’implémentation
physique des données et des traitements à mettre en place ainsi que les
moyens de sécurité à mettre en œuvre.
 27

Ces choix ne sont pas encore la solution, ils déterminent seulement la

direction dans laquelle il faudra mener la réflexion pour concevoir les
différentes solutions possibles. Il fera valider ces choix par la direction de
l'entreprise.
 28

CHAPITRE TROISIEME
LES MODÉLISATION D’UN SYSTÈME D’INFORMATION AVEC LA
MÉTHODE MERISE
3.1. Modélisation
Un modèle est une abstraction de quelque chose de réel qui permet de
comprendre avant de construire, ou de retrouver les informations nécessaires
pour effectuer des entretiens, des modifications et des extensions.
L’abstraction, dans ce contexte, signifie l’examen sélectif de certains aspects
du problème ; c’est l’outil qui permet de délimiter notre connaissance de
l’univers aux entités et aux interactions qui nous concernent dans une
situation donnée.
La modélisation du système peut concerner un domaine, un secteur, une
entreprise, une organisation, etc. Elle commence toujours par une étude
préalable.
3.2. Modélisation conceptuelle
3.2.1. Modélisation conceptuelle de communication
a. But
Le but de cette section est de donner les différents mécanismes pour
construire un Modèle Conceptuel de Communication(MCC) ou encore
Modèle Conceptuel de Flux(MCF).
b. Découpage en domaines
Pour réduire la complexité de modélisation de l’entreprise en un seul
tenant, on découpe l’entreprise en domaines d’activité (Vente, Stock,
Achat, Comptabilité, Gestion du personnel). Un domaine d’activité de
l’organisation est un sous-ensemble relativement indépendant composé
d’informations, règles et de procédures de gestion.
Comment découper une organisation en domaines ?
La technique employée se base sur les ensembles d’informations
échangés, dits aussi flux d’information. Ces flux peuvent être classés
comme suit :
 Flux en provenance de l’environnement extérieur ;
 Flux à destination de l’environnement extérieur ;
 Flux interne échangé (entre les domaines).
 29

c. Analyse des flux

L’analyse des flux permet de représenter le fonctionnement global de
l’entreprise, du domaine, du secteur, ou de l’organisation.
Acteurs et flux
Un acteur représente une entité active intervenant dans le fonctionnement de
l’entreprise :
 Client, Fournisseurs, (acteur externe)
 Un domaine de l’entreprise (Gestion Personnel, Comptabilité)
Un flux de données est la représentation d’un échange d’informations entre
deux acteurs
Exemples :
Le client se présente chez le vendeur muni de la liste des produits qu’il veut
acheter. Le vendeur lui donne le prix de chaque produit et le total à payer. Si
le client est d’accord, le vendeur établît la facture et le client va à la caisse
pour le paiement.
Après paiement, la caissière enregistre et cachette la facture avec la mention
« a payé » et transmet une copie au vendeur et reste avec une autre copie pour
la comptabilité. Après, le vendeur remet au client la facture cachetée et les
produits achetés.
TD : construire le MCC, le MCT et le MOT
Corrigés référez-vous à votre note d’explications
 30

3.2.2. Modélisation conceptuelle de données(MCD)

Le Modèle Conceptuel des Données (MCD) a pour but de décrire les
objets manipulés par les utilisateurs dans le système étudié. La modélisation
conceptuelle des données aboutit à une représentation appelée Schéma
Conceptuel des Données. Le modèle le plus utilisé pour représenter les
données du monde réel est le modèle Entité – Association
( E/A) ou Entités – Relations ( ER).
Les concepts de base pour concevoir le modèle conceptuel sont :
- Entité
- Propriété
- Identifiant
- Occurrence
- Relation (Association)
- Cardinalité
- Contraintes d’Intégrité Fonctionnelles (CIF)
a. Entité (Objet)
Une entité est un type d’élément (objet, individu) du monde réel défini par :
- Une existence propre et utile pour l’organisation étudiée ;
- Des occurrences multiples (c’est – à – dire au moins deux) ;
- Des propriétés (au moins une) dont un identifiant.
Il existe deux catégories d’entités :
- Entités régulières : son existence ne dépend pas de l’existence d’une autre
entité.
- Entités faibles : son existence dépend de l’existence d’une autre entité.
Ex : l’entité RELEVE n’existe que si l’entité ETUDIANT correspondante est
présente.
Elle est représentée par un rectangle subdivisé en deux parties. La partie
supérieure contient le nom de l’entité et la partie inferieure les propriétés.
Nom_Entité
ETUDIANT
Propriété 1 Exemple :
Matricule
Propriété 2
NomEtud
Propriété 3
Propriété 4 PostNomEtu
DateNais
….
….
 31

b. Propriété ou Attribut
Une propriété est une information élémentaire (rubrique, donnée)
manipulable par le concepteur. Une propriété doit être décrite par un nom de
propriété et prendre des valeurs ayant un sens dans les systèmes
d’Informations étudiés.
Une propriété peut être obligatoire ou facultative et avoir un domaine de
valeurs.
Exemple
Nom de la Type de domaine et Signification
Propriété Valeur
Adresse du Client AN (Alphanumérique) Coordonnées complètes du
Client
Code Client N ( Numérique) Coordonnées propres à
chaque Client
N.B. Une propriété est véritablement élémentaire si elle n’est pas
décomposable en un ensemble de propriétés significativement plus petites.
c. Occurrence
Une occurrence est un élément individualisé appartenant à cet objet (un
exemplaire de l’entité).
Exemples :
- L’entité Client est constituée de tous les clients de l’Entreprise. Chaque
client constitue une occurrence de cette entité.
- L’entité Etudiant est constituée de tous les étudiants. Chaque étudiant
constitue une occurrence de cette entité
d. Identifiant
Un identifiant, c’est une propriété qui permet de distinguer sans ambiguïté,
une occurrence d’une entité de toutes les occurrences. On le désigne souvent
par le symbole (#).
Parmi tous les attributs de l’entité, l’identifiant est un attribut ou un ensemble
d’attributs permettant de déterminer une et une seule entité à l’intérieur de
l’ensemble. Graphiquement les identifiants sont les attributs soulignés.
L’entité faible aura un identifiant composé de l’identifiant de l’entité dont elle
dépend et d’un autre attribut
 32

Il existe deux sortes d’identifiants :

- Identifiant simple : S’il est constitué d’une seule propriété.
- Identifiant composé : S’il est constitué de deux propriétés
ou plus
Exemple :

ETUDIANT
Matricule
NomEtud
PostNomEtu
DateNais
….
e. Relation (Association)
Une relation est un lien (une association) qui unit deux entités (objets) ou
plusieurs.
Contrairement aux entités, les relations n’ont pas d’identifiants et d’existences
propres.
Les relations sont caractérisées, comme les entités, par un nom et
éventuellement des attributs.
Elle est représentée par une forme ovale.

Enoncé de l’association

Objet Objet
Nom Relation

Objet
Objet

Exemple :
 33

Client Acheter Produit

Professeur Dispenser Cours

N.B. La relation est toujours définie par un verbe à l’infinitif

Dimension d’une relation
La dimension d’une relation est le nombre d’objets (entités) participants à la
relation. C’est ainsi que l’on distingue :
- Une relation unaire : l’objet avec lui-même
- Une relation binaire : entre 2 objets
- Une relation ternaire : entre 3 objets
- Une relation n – aire : entre n objets
Les relations découlent de règles de gestion (organisation) au sein du
système.
f. Cardinalités d’une relation
La description complète d’une relation nécessite la définition précise de la
participation des entités. La cardinalité est le nombre de participation d’une
entité à une relation.
Les cardinalités explicitent les liens qui existent entre entités et associations
(relations) c’est – à – dire la participation des associations qui est mesurée au
moyen d’un couple des valeurs « Cardinalité Minimale et Cardinalité
Maximale » traduisant le nombre d’occurrences d’entités.
Ainsi, on peut définir la cardinalité comme suit :
Cardinalité minimale : 0 ou 1
C’est le nombre minimum de fois qu’une occurrence d’un objet participe aux
occurrences de la relation.
 34

Cardinalité maximale : 1 ou n
C’est le nombre maximum de fois qu’une occurrence d’un objet participe aux
occurrences de la relation.
On obtient ainsi les différents types de cardinalité :
0 – 1 : au plus un (0,1)
1 – 1 : un et un seul (1,1)
0 – n : 0 ou plusieurs (0, n)
1 – n : 1 ou plusieurs (1, n)
Formalisme de représentation
patte

Objet
Relation
Nbre Nbre

Card MIN Card MAX

3.2.3. Modélisation conceptuelle de Traitement

Les traitements représentent les diverses manipulations qu’il va falloir faire
subir aux données afin d’obtenir les résultats.
Le MCT permet donc de représenter les différents traitements à exécuter dans
le temps, sans tenir compte des contraintes d’organisation ou des moyens
logiciels ou matériels à employer pour arriver à réaliser le traitement.
Ainsi, le MCT permet de répondre aux questions : Quoi faire et quand sans
tenir compte de qui, comment, où.
Les concepts de base pour la construction du MCT sont :
- Evénement
- Opération
- Synchronisation
- Résultat
- Processus
a. Evénement
Un événement correspond à une sollicitation (ou scrutation) au système
d’information et qui à son tour doit réagir par l’exécution d’une ou de plusieurs
 35

actions en vue de traiter cet événement. C’est en quelque sorte la

représentation d’un fait nouveau au SI.
Un événement correspond à un signal provoquant un processus, donc une
série d’opérations et donnant lieu à un ou plusieurs résultats. L’événement
peut être interne ou externe au domaine du processus, il peut déclencher
et/ou résulter d’une opération et peut se combiner à d’autres événements. Il
est caractérisé par un code, un libellé et un commentaire le décrivant, son
type(interne ou externe au processus) et un certain nombre de propriétés
spécifiques à l’événement lui-même ( par exemple pour l’événement Appel d’un
client , on peut avoir les propriétés suivantes : nom du client, objet de son
appel, date/heure de l’appel…).
On représente un événement par un ovale contenant son libellé. Et un motif
de remplissage de l’ovale permettant de distinguer les événements externes ou
internes.
 36

Exemple : L’arrivée d’une demande d’embauche d’un client est un événement

porteur d’informations du client au SI. On peut représenter graphiquement de
la manière suivante :

dde
d’embauche événement

Etude de la demande Opération /

traitement

Résultat : Résultat :
Candidature
Candidature
acceptée
rejetée
b. Opération
Une opération est une action ou une série d’actions déclenchées pour réagir à
un événement ou à plusieurs événements. L’opération produit un ou plusieurs
résultats qui peuvent être des événements à leur tour. Dans la pratique, elle
est identifiée par un verbe ou par un substitut dérivé et elle est formalisée par
un rectangle contenant son libellé.
Une opération doit comporter :
 une entrée, un ensemble d’événements synchronisés qui la déclenchent ;
 un ensemble de tâches à exécuter ;
 en sortie, un ensemble de résultats et de règles d’émission.

Nom : Opération

REGLES (conditions d’émission)

 37

Remarques
- Cette suite d’actions doit être non interruptible, autrement dit les
opérations sont enchaînées les unes des autres.
- Une opération se déroule dans le temps c’est – à – dire à une certaine
durée (en attente d’exécution, en cours d’exécution, terminée)
- Une opération peut être décrite par des règles de gestion.
- Les opérations peuvent être regroupées sous l’appellation générique de
processus dès lors qu’elles concernent un même secteur d’activité.
Exemples d’opération
- Enregistrement du Patient
- Edition d’une fiche du Patient
- Ouverture d’un dossier Patient dès l’arrivée de celui – ci dans un centre
de santé.
Plusieurs éléments sont épinglés dans cette opération, il s’agit :
- Evénement : l’arrivée du Patient
- Opération : ouverture du dossier
- Résultat : Dossier ouvert
- Processus de gestion de commande
- Processus de gestion de Facturation
- Processus de gestion de livraison
c. Synchronisation
Le déclenchement de certaines opérations est surtout conditionné par
plusieurs événements. Il faut ainsi préciser à priori les associations
d’événements dont la présence est indispensable au déclenchement de
l’opération. C’est la synchronisation qui permet de le faire.
En d’autres termes, la synchronisation d’une opération correspond à
une condition sur les événements déclenchant l’opération. Cette condition
peut être liée à une valeur des propriétés du ou des événements, ou au
nombre d’occurrences du ou des événements.
La synchronisation est donc à la fois une association d’événements et
une expression booléenne (condition logique à satisfaire préalablement au
déclenchement de l’opération) formée à partir des opérations ET et OU.
 38

Il est donc recommandé d’attacher à chaque événement un label

plus facile à manipuler que le nom de l’événement. Toutes les combinaisons
entre les opérations sont permises.
La synchronisation se présente sous la forme :
a ET b ; a OU b ; a ET b ET c
Exemple
L’enregistrement d’une commande n’est disponible que lorsqu’on a
reçu la commande et que le client est déjà connu.

Cde Reçue
Client Connu

a
b

a ET b

Enregistrement de la
commande
 39

Rapport
Dossier Facture de
d’expertise
ouvert réparation
a
b
c

a ET b ET c

Remboursement de
l’assuré

Dossier chèque
clos

Le remboursement de l’assuré ne peut s’effectuer qu’au vu de la facture de

réparation ET du rapport d’expertise ET de l’ouverture du dossier.
d. Le résultat
On appelle « résultat », ce qui est produit par l’exécution d’une opération.
 40

Exemple

Cde Client
Événement

Préparation Cde
Opération

Colis
Résultat

N.B.
- Une même opération peut produire plusieurs résultats
- La production des résultats peut être soumise à des conditions de sortie de
l’opération de même que la synchronisation représente des conditions d’entrée
de l’opération.
 41

Exemple1

Rapport
Dossier Facture de
d’expertise
ouvert réparation
a
b
c

a ET b ET c

Remboursement de
l’assuré

Dossier chèque
clos

Exemple2

Déclaration
de sinistre

Vérifier la garantie
Risque couvert Risque non couvert

Sinistre Dossier Sinistre Lettre

pris en ouvert rejeté de refus
compte
 42

L’opération « Vérifier la garantie » déclenchée à l’arrivée de l’événement

« Déclaration de sinistre », génère les résultats : « sinistre pris en compte »,
« sinistre rejeté », « Dossier ouvert » et « lettre de refus (rejet) ».
e. Le Processus
Un processus est un enchaînement synchronisé d’opérations qui
représente une unité homogène de préoccupations de l’entreprise (propre à un
domaine d’activités). Il s’agit de la paie, la facturation client, le recrutement,
la livraison, etc.
Les événements pris en compte pour le déclenchement des opérations
conceptuelles sont les événements externes au processus.
Pour décrire un même domaine, on peut être amené à définir plusieurs
processus. Si ce domaine est vaste, on le découpe en plusieurs sous –
domaines (activités) ayant peut de rapport entre eux. Et chaque sous –
domaine est alors décrit par un processus.
Un processus est toujours déclenché par un événement extérieur. Par
exemple, la fin du mois déclenche la paie des employés.
f. La règle d’émission
La règle d’émission, qui en sortie de l’opération indiquera quels résultats
déclencher, est caractérisée par un code, un libellé et un commentaire. Sa
représentation graphique est la suivante :

Les règles d’émission les plus utilisées sont :

OK (OUI) : si le résultat de l’opération est bon ;
Non OK (KO) : si le résultat de l’opération n’est pas bon
RAS (TOUJOURS) : si l’émission de l’événement est indépendante du résultat
Exemple de MCT : Voir note de cours : Gestion commerciale.
 43

3.3. Modélisation organisationnelle

3.3.1. Modélisation organisationnelle des données
La conception du MOD a pour but de quantifier la Base de Données c’est –
à – dire de définir le volume exact de la Base de Données.
Conception du MOD
Les règles de conception du MOD se résument de la manière suivante :
- Le MOD se construit à partir du MCD
- Si tous les objets (entités) du MCD font l’objet d’automatisation, on dit alors
que le MCD équivaut au MOD. Si non, le MOD est différent du MCD.
- Si le S.I. est du type Client – Serveur, on parle de MOD global pour le
Serveur correspondant (lorsque la gestion se fait à la Direction Générale),
de MOD secondaire pour le Client (poste de travail)
- Le MOD ne comporte que les objets (entités) informatisables.
3.3.2. Modélisation organisationnelle de Traitement
a. Définition
Le Modèle Organisationnel des Traitements s’obtient à partir du MCT en
prenant en compte les choix d’organisation de l’entreprise.
Le MCT décrit le « QUOI » du système étudié c’est – à – dire fournit la solution
indépendamment de choix de l’organisation. Tandis que le MOT, appelé aussi
SOT (Schéma Organisationnel des Traitements) permet de répondre aux
questions :
- Qui fait quoi ?
- Où le faire ?
- Quand le faire ?
- Comment le faire ?
Dans ce cas, le niveau organisationnel intègre :
- L’affectation des tâches (Qui ?)
- La désignation des lieux (Où ?)
- La chronologie des opérations ou phases ou procédures (Quand ?)
- Eventuellement le mode opérationnel (Comment ?)
Le MOT est donc constitué d’un enchaînement de procédures fonctionnelles.
Chaque procédure fonctionnelle est déclenchée par un ou plusieurs
événements liés par une condition de synchronisation. La procédure
 44

fonctionnelle exécute le traitement et produit un ou plusieurs résultats qui

peuvent être éventuellement conditionnés par des règles d’émission.
MOT = MCT + Lieu + Moment + Nature
b. Paramètres organisationnels du MOT
1o) Le poste de travail
C’est le lieu de traitement ou la personne concernée. Autrement dit, c’est
l’ensemble des ressources humaines et matérielles implantées dans un
lieu, capable d’effectuer un ensemble de tâches. Par exemple : Service
comptabilité, client de livraison, chef de service de l’administration
commerciale, etc.
2o) Le type (nature) de traitement
Il définit le degré d’automatisation du traitement. Il existe trois types de
traitement :
- Le traitement manuel : aucune utilisation de l’outil
informatique
- Le traitement interactif (conversationnel) : C’est un
traitement avec assistance de l’ordinateur. Ici, il y a
succession des tâches manuelles et des traitements
informatiques. C’est un dialogue homme – machine.
- Le traitement automatique : C’est un traitement automatisé
en temps réel , en temps différé ou en temps partagé.
3o) La période
C’est la période d’exécution, c’est à dire :
- Les tranches d’heures , de jours, de mois, d’années pendant lesquelles
une procédure fonctionnelle peut être exécutée. Par exemple de lundi –
vendredi, de 9h – 12h, etc. Les tranches concernent le traitement
manuel ou interactif des procédures fonctionnelles.
- Les fréquences de traitements. Par exemple, deux fois par jour, chaque
jour à 12h, etc.
4o) La procédure fonctionnelle
Une procédure fonctionnelle est un ensemble de traitements exécutés
sans interruption par un même poste de travail utilisant des moyens de
 45

traitement d’un type déterminé et pendant une période d’activité

déterminée.
Tableau de procédures fonctionnelles
Période Phase ou procédure ou Service (Poste Nature : mode
(Quand ?) opérations de travail) : le de traitement
lieu(Où) ( comment ?)
- Tranche Le lieu de - Manuel
d’heures traitement ou - Automatisé :
- jours la personne en temps réel,
- mois concernée en différé, ou
- année en temps
- semaines partagé

Exemple : Exemple dans la note sur la gestion client.

3.4. Modélisation logique

3.4.1. Modèle logique des Données (MLD)
a. Définition
La finalité d'un MLD est de nous faciliter la création d'une base de données
pour gérer un tel domaine. Nous savons également qu'une base de données
est constituée par un ensemble de tables, dont chacune est composée de
champs de données et d’enregistrements.
Or , le MCD ne connaît pas la notion de table, tandis qu'une base de données
ne connaît pas le concept des entités reliées entre-elles via des relations
portant des cardinalités.
Pour cela, il existe un autre modèle, le modèle logique des données (MLD),
qui utilise essentiellement le formalisme des tables logiques. Un MLD, qui est
toujours basé sur un MCD donné, contient donc toutes les informations de ce
MCD, mais les représente à l'aide d'un formalisme différent qui est très adapté
aux structures d'une base de données.
 46

Tandis que le MCD représente un système d'information d'une façon générale

et indépendante d'un système informatique, le MLD tient compte de la
réalisation par le biais d'un SGBD.
Un MLD est essentiellement composé de tables logiques reliées entre
elles par des flèches.
Le but du MLD est de préparer l’implantation de la Base de Données.
b. Comment obtenir le MLD ?
Généralement, Le MLD s’obtient à partir du MCD, cependant il y a des
générations (ex 3ième génération) du MERISE qui l’obtient à partir du MOD.
Le MLD peut être relationnel, hiérarchique ou réseau selon le SGBD à utiliser.
Les règles de passage du MCD vers le MLD utilisées ici concernent le SGBDR
du fait qu’il est le plus répandu.
1o) Règles pour les objets du MCD (MOD)
- L’objet se transforme en une table ;
- L’identifiant de l’objet devient la clé primaire de la table ;
- Les propriétés de l’objet deviennent les attributs (champs) de la table ou
relations dans le MCD.
Transformation des entités
Toute entité est transformée en table. Les propriétés de l'entité deviennent
les attributs de la table. L'identifiant de l'entité devient la clé primaire de la
table.

Exemple :

2o) Règles pour les relations du MCD (MOD)

Nous allons définir les règles de transformation pour le passage du MCD au
MLD, en respectant les différents cas qui se posent.
 47

 Cas de la relation type Père – Fils :

Il s’agit de transformation des relations binaires du type (x,n) – (x,1), x pouvant
prendre les valeurs 0 ou 1.
L’objet Père étant du type 0,n ou 1,n et l’objet Fils est du type 0,1 ou 1,1
- L’objet Père devient la table Père ;
- L’objet Fils devient la table Fils ;
- L’identifiant de l’objet Père devient l’identifiant de la table Fils. Cet
attribut est aussi appelé clé secondaire ou clé étrangère ;
- Les propriétés de la relation deviennent les attributs de la table Fils.
D’une manière générale :
Afin de représenter la relation, on duplique la clé primaire de la table basée
sur l'entité à cardinalité (x,n) dans la table basée sur l'entité à cardinalité (x,1).
Cet attribut est appelé clé étrangère. Les deux tables sont liées par une flèche
nommée selon la relation, qui pointe de la table à clé étrangère vers la table
qui contient la clé primaire correspondante.
 Transformation des relations binaires du type (x,n) – (x,n), (x = 0 ou1)
On crée une table supplémentaire ayant comme clé primaire une clé
composée des clés primaires des 2 tables. Lorsque la relation contient elle-
même des propriétés, celles-ci deviennent attributs de la table
supplémentaire. Une propriété de la relation qui est soulignée devra
appartenir à la clé primaire composée de la table supplémentaire.

Exemple : La relation Acheter entre l’entité produit et client : se référer de la

note
3o) Cas particuliers
 Transformation des relations binaires du type (x,1) – (x,1)
Nous devons distinguer plusieurs cas. Sachant qu'une relation binaire du
type (1,1)-(1,1) ne doit pas exister il nous reste les 2 cas suivants:
Relation binaire (0,1)-(1,1)
On duplique la clé de la table basée sur l'entité à cardinalité (0,1) dans la
table basée sur l'entité à cardinalité (1,1).
Relation binaire (0,1)-(0,1) !!!
 48

On duplique la clé d'une des tables dans l'autre. Lorsque la relation contient
elle-même des propriétés, celles-ci deviennent également attributs de la table
dans laquelle a été ajoutée la clé étrangère.
Exemple : referez-vous à vos explications
Soit on migre la clé primaire de la table Entreprise dans la table Salarié, soit
on fait l'inverse.
 Transformation des relations ternaires
On crée une table supplémentaire ayant comme clé primaire une clé
composée des clés primaires de toutes les tables reliées. Cette règle s'applique
de façon indépendante des différentes cardinalités. Lorsque la relation
contient elle-même des propriétés, celles-ci deviennent attributs de la table
supplémentaire. Une propriété de la relation qui est soulignée devra
appartenir à la clé primaire composée de la table supplémentaire.
Exemple : La relation Livrer entre les entités Client, Agent et Produit
 Transformation de plusieurs relations entre 2 entités
Exemple :

La relation habiter du type (x,n)-(x,1), est traduite par la migration de l'attribut

Adresse dans la table Personne. La relation posséder du type (x,n)-(x,n) est
traduite par la création d'une table supplémentaire du même nom. Cette table
contient comme clé primaire composée, les clés des deux tables reliées
Personne et Maison.
 Transformation des relations réflexives
Nous appliquons les règles générales avec la seule différence que la relation
est 2 fois reliée à la même entité.
 49

Comme il s'agit d'une relation (x,n)-(x,n), une table supplémentaire est

créée. Cette table contient comme clé primaire composée, la clé des "deux"
entités reliées. Comme la même entité est liée 2 fois à la relation, on ne
peut pas utiliser 2 fois le même nom pour la clé. Dans ce cas il convient
d'utiliser des rôles dans le MCD, et d'intégrer le rôle dans le nom d'une des
clés migrées dans le MLD.
Exemple 2 :

Comme il s'agit d'une relation (0,1) -(0,1), nous avons en général le choix
en ce qui concerne quelle entité contiendra la clé étrangère. Comme cette
relation est liée deux fois à la même entité, il est évident que nous devons
dupliquer la clé primaire, tout en veillant que le même nom de clé ne sera
pas utilisé pour la clé primaire et la clé étrangère. Dans notre exemple, tous
les hommes mariés, ont comme valeur de la clé étrangère le matricule de
leur épouse actuelle. Pour les hommes non mariés et les femmes, la clé
étrangère est sans valeur. On pourrait bien sûr utiliser la modélisation
inverse avec une clé étrangère NO_MATRICULE_MARI, qui indique pour
chaque femme mariée, le matricule de son mari.
Exemple : Trouver le MLD et le schéma relationnel ou MLDR de MCD
suivant : cf. le MCD précédent
Solution :
 50

Trouvons d’abord le MLDR ou Schéma relationnel

TbClient(Codecli, NomCli, AdressD, AdressTel)
TbProduit(CodePro, Libelle, PrixUnit, DateExp, Provenance)
TbPaiement(NumPaie, Montant, DatePaie, ModePaie, #Codecli)
TbAgent(Matricule, NomAg, AdresTel, AdresDo)
TbAchat(Codecli,CodePro, DateAchat, QteAchat)
TbLivraison(Codecli,CodePro,Matricule, DateLiv)
MLD : referez-vous à vos notes d’explications
c. La Normalisation de MLD
Définition
La normalisation est un processus de décomposition des schémas
relationnels, qui a pour objectif d’obtenir des schémas sous « forme normale ».
Une forme normale est définie comme une liste des règles qui augmentent la
cohérence des données d’une Base de données relationnelle. Ces règles
permettent donc d’organiser des champs et des tables qui satisfont certaines
contraintes définies et qui ont pour but de préciser la cohérence des données
lors de leur stockage et leur mise à jour.
MERISE recommande 5 niveaux de normalisation, cependant dans la
pratique, on tient compte de trois niveaux de normalisation essentiels :
Les Règles de normalisation
C.1. 1ère Forme Normale (1FN) : Elle correspond à la dépendance fonctionnelle.
En d’autres termes, une relation R (une table) est en 1FN si chacun de
constituants (propriétés, champs) est en dépendance fonctionnelle par rapport
à une clé primaire. Le domaine de chaque attribut (champ) est simple (c’est –
à – dire non composé). Par exemple, à un client, on a un identifiant (une clé
primaire) qui lui correspond. Et tous les autres attributs doivent être associés
à la clé, sinon il faut normaliser c’est – à – dire mettre en ordre ou arranger.
C’est la raison pour laquelle on appelle Dépendance fonctionnelle (D.P.).
C.2. 2ème Forme Normale (2FN) : Une relation R (table) est en 2FN si et
seulement si
- elle est en 1FN
- Tout attribut non clé ne dépend pas d’une partie de cette clé. Autrement
dit, une relation R est en 2FN si et seulement si les attributs (
 51

constituants) qui ne font pas partie de cette clé sont en dépendance

fonctionnelle élémentaire par rapport à la clé. La 2FN est aussi appelée
DFE (Dépendance Fonctionnelle élémentaire).
C.3. 3ème Forme Normale (Dépendance Fonctionnelle Directe) : Une relation
est en 3FN si et seulement si
- Elle est en 2FN
- Tout attribut non clé ne dépend pas d’un attribut non clé (les attributs
ont une dépendance directe avec la clé de la table).
3.4.2. Modèle Logique de Traitement (MLT)
Le MLT est un ensemble de modèles et de schémas permet de décrire d’une
façon algorithmique le traitement à réaliser pour chaque opération
informatisable d’une application, retenue au niveau du MOT. Il s’obtient donc
à partir du MOT, en ajoutant aux traitements organisationnels du MOT, des
traitements spécifiques, du mode d’acquisition et d’utilisation des données de
l’interface utilisateur.
Un site correspond à un lieu où s’effectue le traitement autonome utilisant
une ou plusieurs machines. Une Unité Logique correspond à un module du
programme permettant d’exécuter une tâche. Une procédure logique est un
enchaînement logique des traitements. Dans la pratique, il n’existe pas des
règles de passage du MOT au MLT.
3.5. Modélisation physique
3.5.1. Modèle Physique des Données
a. Définition
Le modèle physique des données (MPD) est la traduction du modèle logique
des données (MLD) dans une structure de données spécifique au système de
gestion de bases de données (SGBD) utilisé. En d’autres termes, c’est la
traduction du MLD dans un langage de description des données spécifiques
c’est – à – dire mettre le MLD sur un support physique.
Le MPD est donc représenté par des tables définies au niveau du système de
gestion de bases de données. C'est donc au niveau du MPD que nous quittons
la méthode générale de création d'un MCD et de sa transformation en MLD,
pour nous tourner vers la manipulation d'un SGBD spécifique. En d’autres
termes, c’est la mise en place de la Base de données c’est – à – dire implanter
 52

une à une de chaque table en créant leur structure puis en les remplissant
de données.
Le but du MPD est d’adapter la Base de données aux spécifications du SGBD
et de l’aspect matériel sur lequel doit tourner l’application.
Ainsi, pour concevoir le MPD, on doit se référer au type de SGBD et du logiciel
d’implantation utilisé. Par exemple : le SGBD relationnel ACCESS, ORACLE,
FOXPRO, MYSQL, etc.
b. Passage du MLD au MPD
La démarche à suivre pour concevoir le MPD :
Le passage MLD au MPD se fait par les étapes suivantes :
 Implémentation physique de chaque table du MLD dans le SGBD
utilisé.
 Pour chaque table, indiquer au SGBD quel(s) champ(s) constitue(nt) la
clé primaire.
 Pour chaque table, indiquer au SGBD la (les) clé(s) étrangère(s), et la
(les) clé(s) primaire(s) correspondante(s).
En résumé :
 Créer la structure de la table
 Saisir les données de la table
 Manipuler la Base de Données
 53

3.5.2. Modèle Physique de traitement

Le Modèle Physique de Traitement ou le Modèle Opérationnel de Traitement
consiste en la réalisation sous forme hiérarchique (d’arborescence) de
différents programmes. Dans la pratique, le MOPT s’obtient à partir du MOT
sur base des opérations informatisables prévues dans le MOT.

Etude de Cas : Inscription Universitaire

A la réception du dossier rempli, un agent du département administratif
effectue un premier contrôle visuel de présence des pièces demandées.
Le dossier est repris par un autre agent expérimenté qui étudie son contenu
dans le délai : contrôles sur l’état civil du candidat (limite d’âge), sa scolarité
(niveau de scolarité). puis un cadre supérieur du département étudie la « lettre
de motivation » rédigée par l’étudiant, et faisant partie des éléments à fournir
dans le dossier, si le bilan de tous ces contrôles est favorable, une secrétaire
saisit sur un terminal du mini-ordinateur de l’université les informations
importantes de l’étudiant, qui sont stockées sur une base de données des
candidats l’ordinateur édite une convocation à l’étudiant, précisant date,
heure et lieu des épreuves de sélection.