Université Hassan II de Casablanca

Ecole Supérieure de Technologie

Département Génie Informatique

Support de Cours
1ére Année

Analyse et Conception des

Systèmes d’Information
-
MERISE

Elaboré par : Pr. Nadia AFIFI

 A
AVVA
ANNTT--P
PRRO
OPPO
OSS

L’information se présente sous trois formes: les données, les

connaissances et les messages. On a l’habitude de désigner
par «système d’information» l’ensemble des moyens
techniques et humains qui permet de stocker, de traiter ou
de transmettre l’information. Ainsi, l’objectif du Système
d’Information(SI) est de rendre possible la mise en commun
d’informations appartenant à des sources séparées.
L’élaboration des SI fait appel à des méthodes et des
langages de modélisation afin de les concevoir et de pouvoir
les réaliser par la suite. La conception classique qui se base
sur la décomposition fonctionnelle des systèmes demeurent
un standard qui répond aux exigences fonctionnelles, aux
performances et à la robustesse attendues par les clients.
Dans ce support on présente de façon simplifiée les
différents concepts de la méthode de conception des SI
Merise. On traitera aussi bien les niveaux d’abstractions, que
les étapes de la méthode, illustrées par des études de cas.
L’objectif de ce cours étant de fournir un outil
d’apprentissage par la présentation de la méthode. Il est
composé de quatre chapitres qui traitent les différentes
étapes, niveaux d’abstractions, et modèles associées.
Le support s'adresse aux étudiants de premier cycle (DUT,
BTS). Il pourrait également servir de référence aux étudiants
de second cycle (universités et écoles d’ingénieurs) désireux
d’apprendre les principes et les outils de la méthode Merise.
2
Table des matières
CHAPITRE I
INTRODUCTION – Les Systèmes d’information….…7
I.1 Systèmes d’Information: Définition……………………8
I.2 Analyse & Conception des SI………………………..….8
I.3 Remarques………………………………………………9
I.4 SI : Rôle, Composantes, Evolution………………….13
I.4.1 Rôle…………………………………………………..13
I.4.2 Composantes……………………….………………14
I.4.3 Evolution14……………………………..…………..14
CHAPITRE II
La Méthode MERISE – Principes & Outils…………..15
II.1 Historique de Merise………………………………….16
II.2 Principes généraux………………………………….…16
II.3 Les étapes de MERISE………………………………..17
II.3.1 Schéma Directeur…………………………………18
II.3.2 Étude Préalable……………………………………19
II.3.3 Étude Détaillée…………………………………….20
II.3.4 Étude Technique……………………………….….20
II.3.5 Mise en Œuvre……………………………………..21

3
II.3.6 Maintenance………………………………………..22
II.4 Méthode d’analyse et de conception………………….22
II.4.1 Niveau Conceptuel………………………………..24
II.4.2 Niveau Logique / Organisationnel……………..26
II.4.3 Niveau Physique / Opérationnel………………27
CHAPITRE III
Analyse & Conception des Systèmes d’Information
Modèles de Données……………………………………29
III.1 Définitions…………………………………………….30
III.2 Présentation de la démarche MERISE……………...32
III.3 Présentation de l’application………………………...33
III.4 Dictionnaire de données………………………..…….34
III.4.1 Quelques définitions…………………………….34
III.4.2 Dictionnaire de donnée de l’école…………….35
III.5 Des données au modèle entité / association……...…35
III.5.1 Terminologie………………………………………35
III.6 Schéma Entité/Association de l’application…….….45
III.7 Difficultés pour modéliser les données………..……46
III.7.1 Présentation......................................................46
III.7.2 Validation du MCD………………………………47
III.7.3 Généralisation / Spécialisation……………….49
III.8 Modèle Logique Relationnel………………………..52

4
III.8.1 Exploitation de la BdD………………………….52
III.8.2 Historique sur le modèle relationnel………….53
III.8.3 Fiche conseil……………………………………..54
III.8.4 Domaine…………………………………………...57
III.8.5 Règles de passage du MCD au MLD…………58
III.8.6 Modèle Relationnel du cas Ecole……………..59
III.9 Modèle physique de la base………………………….61
CHAPITRE IV
Analyse et Conception des Systèmes d’Information
Modèles de Traitements………………………………..65
IV.1 Modèle Conceptuel des Traitements (MCT)…..……66
IV.1.1 Introduction……………………………………...66
VI.1.2 Concepts de base………………………………66
IV.2 Modèle Organisationnel des Traitements (MOT)….76
IV.2.1 Présentation générale…..………………………76
IV.2.2 Concepts, définitions et formalisme………….78
IV.3 Modèle Opérationnel des Traitements……………...83
IV.3.1 Introduction……………………………………….83
IV.3.2 Structuration des transactions…………….….84
VI.3.3 Structuration des programmes « batch »……86
Conclusion……………………………………………..…87
Bibliographie – Webographie…………………………88

5
"L'apprentissage est la seule chose que
l'esprit n'épuise jamais, ne craint
jamais et ne regrette jamais "

Léonard de Vinci

6
 CHAPITRE I

INTRODUCTION

Les Systèmes d’Information

Tous ce qui doit être fait

avant la programmation

7
I.1 Systèmes d’Information: Définition

Les Systèmes d’Information (SI) représentent l’ensemble

des composants du système réel (données, programmes,
écrans, documents, circuits, utilisateurs…) modélisé (grâce à
des modèles)
C'EST A DIRE :
Représenté au moyen de concepts (rubriques, fonctions,
évènements, entités, …)
LE SYSTEME D'INFORMATION EST UNE IMAGE
INCOMPLETE DE LA REALITE QUI DEFINIT CE QUE L'ON
DOIT FAIRE ET COMMENT ON DOIT LE FAIRE.

I.2 Analyse & Conception des SI

ASCI : Pourquoi ?

➢ DEUX CHIFFRES :
80% des utilisateurs insatisfaits ;
60% des informaticiens maintenance ;
➢ LES RAISONS :
– Progrès technologiques ;
– Pression des constructeurs ;
– Formations à revoir ;
– Les utilisateurs ne maitrisent pas les systèmes
conçus pour eux et sans eux.
Globalement l'informatisation est un échec
8
I.3 Remarques

1. Programmation = implémentation /codage /

développement / etc.
Principe : ne jamais commencer la programmation avant
d'avoir résolu tout le reste !
2. Avant l'analyse, il existe une étape appelée : étude
d’opportunité.
3. Après la programmation, il existe une étape appelée :
tests.
4. Pour mener à bien les deux étapes d’analyse et de
conception on doit disposer de modèles et de méthodes.

Modèle : ensemble de concepts précis ;

Exemple : norme, rubrique, entité, etc.

Méthode : chronologie d'étude des concepts et mode

d'obtention des instances de concepts.
9
Exemple : comment trouver les normes, les rubriques, les
entités d'un problème donné et dans quel ordre faut-il les
trouver ?
On peut dire qu’une méthode est ensemble de règles et
procédés pour la mise en place des systèmes:
– Fiables
– Performants
– Évolutifs
Composants d’une méthode:
– Une philosophie générale
– Une démarche
– Des formalismes
– Un vocabulaire
Origine d’une méthode :
– Informatisation des entreprises
– Evolution des démarches méthodologiques.
5. En analyse : un seul modèle et pas de méthode
6. En conception beaucoup de modèles et de
méthodes regroupes en deux familles : classique et
objet

10
7. Les trois principaux problèmes
➢ EN ANALYSE
L'analyse des besoins : comprendre ce que veut
l'utilisateur
– Il ne le sait pas toujours
– Il le sait mais ne sait pas l'exprimer
– Il sait l’exprimer mais on ne le comprend pas
Donc : Dialogue ; Patience ; Prototypes ; Ecrans
MEME UN PROBLEME SIMPLE PEUT ETRE MAL POSE !

11
➢ EN CONCEPTION
– Il faut s'occuper a la fois des données et des
traitements ;
– Il est fondamental de garantir la cohérence entre les
deux ;
– En Conception Classique (CC) garantir la cohérence
entre la structure de la base de données et les
requêtes et graphes ;
– En Conception Orientée Objet (COO) garantir pour
l'ensemble des classes la meilleure répartition
méthodes / attributs ;
➢ POUR L'ENSEMBLE DES ETAPES
– Assurer la communication;
12
 – Les résultats de l'étape i doivent être communiqués a la
personne qui s'occupe de l'étape i+1 ; donc : dossiers
doivent être standards si possible;
– Ne pas oublier non plus l'importance de la maintenance
(Les SI évoluent et les informaticiens bougent souvent)
CONCLUSION :
➢ Passer du temps sur l'analyse et la conception ne
garantit pas le succès mais le manque d'analyse et
de conception garantit l'échec.
➢ Utiliser une méthode ne garantit pas le succès mais
le manque de méthode garantit l'échec.
➢ Plus tôt on commence à coder plus tard on finit.

I.4 SI : Rôle, Composantes, Évolution

I.4.1 Rôle
Le système d’information de l’entreprise :
➢ est constitué de l’ensemble des moyens et procédures
de recherche, saisie, classement, mémorisation,
traitement, diffusion d’informations (renseignements,
connaissances);
➢ a pour objectif de restituer, aux différents membres de
l’entreprise, les informations sous une forme directement
utilisabl , au moment opportun, afin de faciliter le bon
fonctionnement opérationnel et la prise de décision aux
différents niveaux ;
➢ Il peut être vu sous trois aspects complémentaires:
13
 – INFORMATIONNEL
– ORGANISATIONNEL
– TECHNOLOGIQUE.

I.4.2 Composantes
Un Système d’Information comprend différente composantes
bien définies :
➢ Selon les niveaux de décision des utilisateurs
(stratégique…opérationnel);
➢ Selon les types de fonction assurés (traitement des
transactions, aide à la décision, etc.);
➢ Selon les domaines d’utilisation (commercial,
production, etc.).

I.4.3 Evolution
Les Systèmes d’Information évoluent de manière continue:
➢ Dans leur degré d’AUTOMATISATION (recours intensif à
l’ordinateur);
➢ Dans leur degré d’INTEGRATION (Liaison plus ou moins
forte entre les différentes composantes).

14
 CHAPITRE II

La Méthode MERISE

Principes & Outils

15
Merise est une méthode d'analyse, de conception et de
gestion de projet complètement intégrée, ce qui en
constitue le principal atout. Elle a fourni un cadre
méthodologique et un langage commun et rigoureux à une
génération d'informaticiens français.

II.1 Historique de Merise

Issue de l'analyse systémique, la méthode MERISE est née

dans les années 1970 et a surtout été utilisée en France, par
les SSII de ses membres fondateurs (Sema Metra, ainsi que
par la CGI Informatique) et principalement pour les projets
importants. Elle a d'emblée connu la concurrence de
Méthodes Anglo-saxonnes telle que SDM/S ou Axial.
Elle a ensuite cherché à s'adapter aux évolutions rapide des
technologies de l'informatique avec MERISE/objet, puis
MERISE/2 destinée à s'adapter au client/serveur. Depuis les
années 90 environ, la seule méthode qui subsiste et qui l'a
totalement remplacée est UML, mieux adaptée à la
conception de projet sur micro-ordinateurs puis avec
Internet, mais sans en avoir la même portée.

II.2 Principes généraux

La vocation de MERISE est double : d’une part MERISE

représente une méthode de conception de système
d’information (SI) et d’autre part MERISE propose une
démarche méthodologique de développement de SI.

16
Les atouts majeurs de MERISE en tant que méthode de
conception sont :
➢ Une approche globale du SI menée parallèlement
sur les données et les traitements,
➢ Une description du SI par niveaux : niveau
conceptuel, niveau logique ou organisationnel et
niveau physique ou opérationnel,
➢ Une description du SI utilisant un formalisme de
représentation précis, simple et rigoureux, pour la
description des données. Ce formalisme est
normalisé au plan international par l’ISO sous le nom
de : modèle « ENTITE RELATION ».
MERISE, comme nous l’avons dit, c’est aussi une méthode de
développement de SI. Les points forts de la méthode dans ce
domaine sont le découpage du processus de développement
en 6 étapes:
1. Schéma Directeur
2. Étude Préalable
3. Étude Détaillé
4. Étude Technique
5. Mise en œuvre
6. Maintenance

II.3 Les étapes de MERISE

1. Schéma directeur: Spécification de ce qu’on veut

faire;

17
 2. Étude préalable: Description de l’application de
manière conceptuelle et planification de sa
réalisation;
3. Etude détaillée
4. Etude technique:
– matériel,
– étude des ressources,
– choix de SGBD,
– choix de langage de programmation;
5. Mise en oeuvre
– Production des logiciels,
– Mise en exploitation;
6. Maintenance.
II.3.1 Schéma Directeur
➢ Structure générale de l’organisation future
➢ Structure des réseaux de communication
➢ Répartition des postes de travail
➢ Il donne les orientations à suivre pour mener le projet
➢ Initialisation :
– Préciser les objectifs et cadre d’étude
– Établir le planning général de l’étude
➢ Identification des besoins:
– Recenser les besoins de l’utilisateur
– Faire le Bilan

18
 ➢ Établissement d’un scénario pour réaliser le projet :
– Conception des scénarios
– Planning des scénarios
➢ Évaluation du coût :
– Définition des plans d’action et du budget relatif
au scénario retenu.
➢ Système de contrôle de réalisation, Indicateur de
performance:
– Définir des procédures de suivi, d’actualisation et
de mise en Œuvre du plan.
Merise exige (pour cette étape) l’établissement de deux
rapports :
1. Le rapport de synthèse pour le comité de contrôle :
Choix les plus importants de façon claire et précise
pour aider à la prise de décision.
2. Un rapport plus détaillé pour montrer l’ensemble
des choix: Hypothèses, scénarios, orientations qui
vont servir à l’étude suivante.

II.3.2 Étude Préalable

Le point de départ de l’étude préalable et le rapport détaillé
du schéma directeur.
➢ Recueil :
– Formaliser le niveau conceptuel des données et des
traitements.

19
 – Cerner le dysfonctionnement du système
– Identifier les goulots d’étranglement
– Sélectionner un sous ensemble représentatif.
➢ Conception :
– Formaliser des choix de gestion
– Appliquer les orientations du schéma directeur.
➢ Choix organisationnel :
– Définir plusieurs Scénarios pour l’étude suivante.
➢ Évaluation:
– du coût
– du délai
– Prévoir des indicateurs de contrôle du planning.
Merise exige pour (pour cette étape) l’établissement d’un
rapport détaillé servant de base pour l’étude portant sur la
description de toutes les données et toutes les procédures.

II.3.3 Étude Détaillée

➢ Reprendre le document de l’étude préalable et le
détailler
➢ Introduire toute les règles de l’organisation
➢ Choisir les orientations pour la réalisation.

II.3.4 Étude Technique

Passage du niveau conceptuel au logiciel
➢ Transformer la spécification fonctionnelle.

20
 ➢ Préciser les contraintes matérielles et humaines.
➢ Préciser le MOT en un ensemble de modules.
➢ Regrouper les données par site.
➢ Définir des systèmes de protection avant la phase de
production du logiciel.
➢ Choisir la méthode de gestion des données.
➢ Faut-il recruter du personnel? Former du personnel?
➢ Définir l’équipe de réalisation:
– Responsable de programmation
– Secrétaire de programmation
– Programmeurs, etc.

II.3.5 Mise en Œuvre

➢ Production du logiciel.
➢ Test d’intégration: Regrouper les différents modules
et voir si le programme marche globalement.
➢ Production des documents:
– Documents techniques détaillés.
– Notice d’exploitation.
– Guide pour les utilisateurs.
➢ Coexistence du nouveau système avec l’ancien.
➢ Définir une stratégie de transition.
➢ Lancer les nouveaux systèmes sous le contrôle.

21
➢ Respect des objectifs.
➢ Respect du cahier de charge.
➢ Qualité du système d’information.
➢ Respect des contraintes techniques.
➢ Comment les utilisateurs conçoivent le S.I?

II.3.6 Maintenance
➢ Revoir les performances du système d’informations en
cas de modifications il faut s’assurer qu’elles rentrent
dans la philosophie du S.I, pour garder la cohérence du
système.
➢ Planifier des modifications, les regrouper pour
optimiser les coûts.
➢ Mettre à jour la documentation après chaque
modification.

II.4 Méthode d’analyse et de conception

La méthode Merise d'analyse et de conception propose une

démarche articulée sur Trois niveaux de préoccupation.
Cet étagement en 3 niveaux a pour objectif de hiérarchiser
les préoccupations et les questions auxquelles répondre.
L'objectif est de ne pas biaiser les réponses apportées au
niveau conceptuel par des choix de technique ou
d'organisation (ou de réorganisation) : le niveau conceptuel

22
vise ainsi à s'abstraire de questions d'ordre organisationnel
ou technique, c'est le cycle d'abstraction.

23
La méthode Merise se distingue par l’étude de données et
des traitements prise de façon séparée sur une grande partie
de l’analyse.

Données Traitements

Modèle Conceptuel Modèle Conceptuel de

Conceptuel
de Données MCD Traitement MCT

Modèle Logique de Modèle Organisationnel

Logique
Données MLD de Traitement MOT

Modèle Physique Modèle OPerationnel

Physique
de Données MPD de Traitement MOPT

II.4.1 Niveau Conceptuel

Ce niveau de préoccupation correspond aux finalités de
l’entreprise. Il s’agit de décrire le « QUOI » en faisant
abstraction des contraintes d’organisation et techniques.
Les travaux menés à ce niveau visent à décrire le modèle (le
système) de l'entreprise ou de l'organisme on retrouve :
➢ Le Modèle Conceptuel des Données (ou M.C.D.),
schéma représentant la structure du système
d'information, du point de vue des données, c'est-à-
dire les dépendances ou relations entre les différentes
données du système d'information.

24
 ➢ Le Modèle Conceptuel des Traitements (ou M.C.T.),
schéma représentant les traitements, en réponse aux
événements à traiter (par exemple : la prise en
compte de la commande d'un client).
Donc, l'étude conceptuelle Merise s'attache aux invariants
de l'entreprise ou de l'organisme du point de vue du métier :
Quels sont les objets métier gérés par l'entreprise ? Quels
sont les processus traités ?, etc. ; indépendamment des
choix techniques (comment fait-on ?) ou organisationnels
(qui fait quoi ?) qui ne seront abordés que dans les niveaux
suivants.
II.4.1.1 Modèle Conceptuel de Données (MCD)
La description des données et des relations est réalisée à
l’aide des 3 concepts du formalisme individuel :
➢ OBJET (ou INDIVIDU ou ENTITE),
➢ RELATION,
➢ PROPRIETES.
II.4.1.2 Modèle Conceptuel de Traitement (MCT)
La description de la partie dynamique du SI est réalisée à
l’aide des concepts suivant :
➢ PROCESSUS,
➢ OPERATION qui comprend les concepts:
– ÉVÉNEMENT/RESULTAT,
– SYNCHRONISATION

25
 II.4.2 Niveau Logique / Organisationnel
Comme son nom l'indique, l'étude organisationnelle
s'attache à préciser comment on organise les données de
l'entreprise (MLD) et les tâches ou procédures (MLT). Pour
autant, les choix techniques d'implémentation, tant pour les
données (choix d'un SGBD) que pour les traitements
(logiciel, progiciel), ne seront effectués qu'au niveau suivant.
Les choix d’organisation sont pris en compte à ce niveau:
➢ La répartition homme/machine,
➢ Le mode de fonctionnement : temps réel ou temps
différé,
➢ La répartition géographique des données et des
traitements.
A ce niveau de préoccupation, les modèles conceptuels sont
précisés et font l'objet de choix organisationnels. On
construit :
➢ Un Modèle Logique des Données (ou MLD), qui reprend
le contenu du MCD précédent, mais précise, la structure
et l'organisation des données telle qu'elles pourront
être implémentées.
Par exemple, à ce stade, il est possible de connaître la
liste exhaustive des tables qui seront à créer dans une
base de données relationnelle;
➢ Un Modèle Organisationnel des Traitements (ou MOT),
qui précise les acteurs et les moyens qui seront mis en

26
 œuvre. C'est ici que les traitements sont découpés en
procédures fonctionnelles (ou PF).
II.4.2.1 Modèle Logique de Données (MLD)
Il peut être selon les cas :
➢ Le modèle CODASYL, si une orientation base de
données « réseau» est prise.
➢ Le modèle RELATIONNEL, si une orientation base de
données « relationnel » est prise.
➢ Les fichiers CLASSIQUES, si une orientation fichiers
classiques est prise.
II.4.2.2 Modèle Organisationnel des Traitements
(MOT)
Le Modèle Organisationnel des Traitements (M.O.T.) permet
de représenter par procédure les phases et taches exécutés
par chaque poste de travail.
En résumé à ce niveau le « QUI FAIT QUOI ET OU » est décrit.

II.4.3 Niveau Physique / Opérationnel

Les réponses apportées à ce dernier niveau permettent
d'établir la manière concrète dont le système sera mis en
place.
➢ Le Modèle Physique des Données (ou MPD ou MPhD)
permet de préciser les systèmes de stockage employés
(implémentation du MLD dans le SGBD retenu).

27
➢ Le Modèle Opérationnel des Traitements (ou MOT ou
MOpT) permet de spécifier les fonctions telles qu'elles
seront ensuite réalisées par le programmeur.
A ce niveau, les choix techniques sont définis. Ainsi, les
organisations physiques de données sont spécifiées au
travers du Modèle Physique des Données (MPD) et la
description des traitements est réalisée pour chaque
transaction (temps réel) ou chaque unité de traitement
(temps différé) au travers du Modèle OPérationnel des
Traitements (MOPT).
A ce niveau le « COMMENT FAIRE » est décrit.

28
 CHAPITRE III

Analyse & Conception des

Systèmes d’Information

Modèles de Données

29
La conception d’un système d’information est une discipline
qui s’attache à étudier des méthodes de modélisation d’un
domaine d’application.
Le résultat de cette modélisation à pour objet
d’appréhender des solutions pour améliorer, voir
informatiser ce domaine.
L’informatisation n’est pas une fin en soit, les outils de
modélisation dépendent de la méthode employée.
Dans ce cours nous allons suivre la méthode Merise.

III.1 Définitions

➢ Base de donnés : est une collection cohérentes de

fichiers d’informations pouvant avoir des relations
conceptuelles entre elles.
Exemple:

30
➢ Fichier : est une collection cohérente de données
relatives à un élément précis.
Exemple: Fichier client
Identifiant : Numcli

Numcli Nom Prenom Adresse Code Localité

A3 Alami Rita 45, rue 3000 Rabat

lamartine

F56 Filali Ahmed 56, Bd 5000 Safi

Henry V

H67 Ali Houda 89, Av 2000 Casa

Fonda

Un fichier peut être assimile à un tableau

➢ Champ: (Field) chaque colonne possède le nom de
champ identifié par une variable de champ (nom,
prénom..).
➢ Enregistrement : (Record) chaque ligne représente une
fiche du fichier appelée enregistrement et identifiée par
un identifiant.
➢ Donnée : (Data) elle représente une cellule
du tableau (Intersection ligne, colonne). La
donnée est la plus petite occurrence se rattachant à
une organisation.
➢ Caractère : (caracter) il représente l’atome d’une base
de données et constitue la donnée.
31
III.2 Présentation de la démarche MERISE

La méthode Merise se distingue par l’étude des données et

des traitements prise de façon séparée sur une grande partie
del’analyse.
Nous nous attacherons dans cette 1ere partie qu’à l'étude
des données.

Recueil des informations Pré analyse

Dictionnaire des Données

Modèle Conceptuel des Étapes

Données (MCD)

Modèle Logique et de
Relationnel des Données
(MLD)

Modèle Physique des Modélisation

Données (MPD)

Pour illustrer la méthode, nous allons nous intéresser au cas

d’une ECOLE.

32
III.3 Présentation de l’application

L’académie nous demande d’informatiser la gestion des

écoles. La solution proposée est purement hypothétique
mais elle permet une bonne approche du sujet.
➢ Règles de gestion :
– Un instituteur enseigne dans une classe et une seule;
– Une classe comprend plusieurs élèves;
– Un instituteur ne peut enseigner que dans une école
mais une école gère au moins un instituteur ;
– L’école dépend d’un inspecteur et un seul;
– Chaque élève participe à un ou plusieurs ateliers
différents dans la semaine au jour qui lui convient,
pour une semaine donnée un élève ne peut
fréquenter le même atelier qu’une seule fois;
– Un instituteur peut être inspecté une fois, plusieurs
fois, ou aucune fois dans l’année;
– Les inspections sont réalisées sur une spécialité
donnée (sport, lecture, orthographe, calcul, etc.) à une
date donnée. En cas de réclamation une inspection
peut être refaite sur une même spécialité à une date
postérieure.

33
III.4 Dictionnaire de données

III.4.1 Quelques définitions

➢ Unicité sémantique : à une donnée correspond une
mnémonique, il faut parvenir à ce que chacun de ces
mnémoniques ait une signification unique au sein de
l’organisation. Il faut pour cela éviter :
– Les redondances : existence d’une donnée en double.
– Les synonymes : existence de deux mnémoniques
décrivant le même objet.
– Les polysèmes : mnémonique unique pouvant décrire
plusieurs objets différents.
➢ Contraintes d’Intégrité : (CI) une contrainte d’intégrité
est une règle à observer pour que chacune des valeurs
que revêt une donnée soit correcte.
Exemple : Une donnée doit toujours avoir au moins la
valeur 0 ; Les quantités doivent être supérieures à 100.
➢ Dictionnaire de Données : (DdD) est un outil qui permet
de recenser l’intégralité des données d’une organisation
à partir des informations recueillies. Il est conseillé dans
le dictionnaire de spécifier l’origine des données
(document, facture…) et leur type (calculées,
significatives…).
Il faut savoir qu’à terme certaines données telles que
les données calculées (TVA, remise, etc.) n’apparaîtront
pas dans la base de données puisqu’elles peuvent être

34
 recalculées par le système au moment de la
consultation.

III.4.2 Dictionnaire de donnée de l’école

N° Mnémonique Description Doc 1 Doc 2 Calc Sign

1 Code_eco Code de l’école x x

2 Nom_eco Nom de l’école X X

3 Adr_eco Adresse de l’école X X

4 Num_instit Numéro X X
d’instituteur

5 Nom_instit Nom d’instituteur x x

… … …

III.5 Des données au modèle entité / association

III.5.1 Terminologie
Le MCD ou M.E.A.T a pour but de décrire, selon l’univers de
discours, des entités et des associations qui les relient. Le
Modèle E/A (Entity-Relation Ship) est un modèle de données
défini dans le cadre de la méthode MERISE.

35
Par soucis de clarification de vocabulaire, et pour éviter
toutes ambiguïtés, la plupart des utilisateurs (USER’S)
utilisent une terminologie qui est la suivante:
III.5.1.1 PROPRIETE/ATTRIBUT/RUBRIQUE/CHAMPS/
ZONE
Une propriété est le plus petit élément du système
d’information manipulé par l’ensemble, et qui a un sens en
lui-même (ce sont des données faisant partie de la vie
intrinsèque d’entités ou d’associations).
On distingue les propriétés élémentaires, de propriétés
calculées : elles peuvent se déduire d’une autre propriété
par le biais d’une règle de gestion (arithmétique ou logique).
III.5.1.2 CONCEPT D’ENTITE
Une entité est un objet abstrait ou concret de l’univers du
discours. Une entité peut être :
➢ Une personne (CLIENT)
➢ Un lieu (DEPOT, BUREAU, ATELIER, …)
➢ Un objet documentaire (LIVRE, OUVRAGE, DOSSIER, etc.)
Après avoir réalisé le dictionnaire de données, il faut
regrouper ces données par paquet homogène. Ces paquets
représentent les entités.
Une entité est caractérisée par :
- Un identifiant
- Une suite d’information liée à cet identifiant.

36
Représentation graphique d’une entité :

Remarque :
Dans la plupart des études de cas, l’entité « DATE » est
présente : c’est une entité Spatio-temporelle formée d’un
seul attribut
DATE
(calendrier) - date : JJ/MM/AA
De même, on peut créer une entité « HEURE »

III.5.1.3 IDENTIFIANT
➢ C’est une propriété particulière de l’entité;
représentation de l’une des occurrences de l’entité ou
de l’association.
➢ Chaque identifiant est unique (UNIQUE).
➢ Le meilleur moyen pour ne pas risquer d’avoir des
synonymes consiste à prendre des numéros de
références comme identifiant.

37
➢ Un identifiant peut être simple c.à.d. constitué d’une
seule propriété élémentaire (d’ordre 1) : NUM_ELEV.
➢ Un identifiant peut être constitué de plusieurs
propriétés élémentaires: d’ordre2, 3 ou 4 voire 5.
III.5.1.4 OCCURRENCES D’UNE ENTITE
(Trouve son origine dans le verbe « OCCURS »)
Une occurrence ou tuple est une réalisation particulière de
l’entité ou un exemplaire de l’entité. L’ensemble des
occurrences forme l’entité désignée.
En pratique, on dénombre les occurrences selon une
représentation tabulaire ou chaque ligne de la table décrite
forme une occurrence ou tuple.
De façon théorique, on peut assimiler la notion d’entité
conceptuelle à la notion de fichier physique.
Remarque :
Le but d’une analyse est de pouvoir à partir d’un
dictionnaire de donnée aboutir à une collection d’entité
sans redondance, et ayant des liens logiques entre elles tel
que quelque soit la donnée celle-ci sera accessible à
volonté.

III.5.1.5 ASSOCIATIONS
Une association est un lien sémantique entre plusieurs
entités indépendamment de tous traitements.

38
 Une association est souvent nommée par un verbe qui
exprime le sens du lien entre les entités.
Les liens logiques existant entre deux entités sont
appelés Associations.
Par exemple, on peut considérer qu’il existe une
association Enseigne entre l’entité instituteur et élève
dans le cas de l’école.

Représentation graphique d’une association:

III.5.1.6 CARDINALITES D’UNE ASSOCIATION

La cardinalité minimale indique le nombre minimum de
fois ou chaque occurrence de l’entité est impliquée dans
une association.
Les cardinalités minimales peuvent être 0 ou 1:
– 0 indique que l’occurrence de l’entité n’est pas
impliquée dans l’association.
– 1 indique qu’elle est impliquée au moins une fois
dans l’association.

39
 La cardinalité maximale indique le nombre maximum de
fois ou chaque occurrence d’une entité peut être impliqué
dans les occurrences d’une association.
Les cardinalités maximale peuvent être 1 ou n :
- 1 si une occurrence d’entité est impliqué au plus une
fois dans l’association.
- n si une occurrence peut être impliquée plusieurs fois
dans l’association.
Les 4 couples de cardinalité sont :(0,1) ; (0,n) ou (1,1) ; (1,n)
Remarque :
Dans les études de cas, le n peut être fixé (ex : n=8 /9).
Donc la cardinalité représente la fréquence d’apparition
minimale et maximale d’une entité par rapport à une
association.
Exemple :
Un instituteur enseigne dans une classe et une seule.
Une classe comprend plusieurs élèves.

Représentation graphique des cardinalités:

40
 Notions de Contraintes d’Intégrité Fonctionnelle (CIF)
et d’associations en Merise :
Merise distingue deux types d’associations :
➢ Associations simples : ce sont des liens logiques
ayant pour cardinalités des cardinalités maximales.

➢ C.I.F. : Une Contrainte d’Intégrité Fonctionnelle et une

forme particulière d’association qui, par rapport à une
entité, a pour cardinalité 0,1 ou 1,1 ; et n’est pas
porteuse de propriétés.

III.5.1.7 RAPPEL MATHEMATIQUE SUR LA THEORIE

DES ENSEMBLES:
– Bijection (1,1)
– Surjection (1,n)
– Injection (0,1)
Qu’en déduire pour les CIF?

41
 III.5.1.8 ASSOCIATIONS PORTEUSES DE DONNEES
On peut y trouver des porteuses de données binaires,
ternaires, quaternaires, etc.

Association binaire :

42
Association ternaire:
Dimension de l’association est d’ordre 3

III.5.1.9 ASSOCIATIONS REFLEXIVES

43
L’association « Est marié à » est définie sur une seule entité
mais concerne 2 occurrences de la même entité.
(On autorise plusieurs mariages pour la même personne).
Remarque fondamentale:
Ce genre d’associations réflexives se rencontrera souvent
dans le dossier « Gestion de la production ».

Il est parfois nécessaire de combiner une association

réflexive et ternaire.
Exemple : On désire connaître, à la Mairie de Paris, Les
personnes mariées dans une même ville.

44
 0 : indique que les personnes (Mari et Épouse) n’habitent
pas dans la même ville bien qu’étant mariés.

III.6 Schéma Entité/Association de l’application

Le Schéma Entité/Association (E/A) représente l’intégralité

des entités et des associations.
En Merise, on appelle ce modèle le Modèle Conceptuel des
Données : MCD.

45
III.7 Difficultés pour modéliser les données

Ce chapitre a pour but de fournir les solutions adaptées

pour modéliser des situations simples qui ne peuvent pas
être traité correctement avec le modèle de base défini dans
le chapitre précèdent.

III.7.1 Présentation
Une agence immobilière constitue une BDD sur son parc
immobilier. Elle désire prendre en considération deux
activités :
➢ La 1ère concerne le suivi de la gestion des immeubles
➢ La 2eme concerne la gestion des hôtels qu’elle
possède.

46
 Nous sommes en présence de 2 applications différentes
concernant cette agence immobilière.
Gestion des immeubles :
➢ Les employés gèrent des maisons
➢ Un client peut-être à la fois propriétaire de plusieurs
maisons et locataire de plusieurs maisons.
➢ Certain clients ne sont que propriétaires et d’autre que
locataires.
Remarque :
On distingue différents type de propriétaires : Individus,
Entreprise civile ou commerciale.
Cette propriété inscrite dans l’entité client, va poser le
problème suivant (cf. paragraphe suivant).

III.7.2 Validation du MCD

Dans sa représentation tabulaire, l’entité client se réalise
de la manière suivante :

47
 NUMCLI NOM REVENU TYPE
LOCATION PROPRIO

21 DUPONT 15 000.00

45 SADOP Entreprise

32 MALON 12 000.00 Particulier

17 BOULON Entreprise

66 VALOU 8 000.00

Nous remarquons que dans le tableau des occurrences de

l’entité client, certaines propriétés : Montant revenus et
type_proprio n’ont pas de valeur, de plus pour le client
BOULON (N°17) les revenus n’existent pas.
La règle énoncée ci-dessus n’est pas vérifié:
• Pour les clients qui ne sont que propriétaire, la rubrique
« Revenu_location » figure à blanc.
• Pour les clients qui ne sont que locataire la propriété
« Type-proprio » ne prendra pas de valeur.
• Seuls les clients qui sont à la fois propriétaire et
locataire vérifient la règle.
Il faut proposer une solution qui vérifie la règle de
validation.

48
III.7.3 Généralisation / Spécialisation

(Entité générique / Entité spécifique)

49
Nous sommes en présence
➢ D’une entité générique (CLIENT) qui possède des
propriétés communes au propriétaire et au locataire
« Num_cli » et « Nom_cli ».
➢ De deux entités spécifiques: « PROPRIETAIRE » et
« LOCATAIRE ».
THEOREMES:
➢ Le lien « est un » entre des entités spécifiques et une
entité générique correspond à une règle d’héritage.
➢ L’héritage est une transmission de propriétés d’un
type générique vers un type spécifique:
50
 ➢ Tout propriétaire hérite des propriétés d’un client.
➢ Tout locataire hérite des propriétés d’un client.
On aurait pu, tout en conservant la règle de validation
construire le MCD suivant :

Le défaut de cette représentation est que le même objet

est représenté par deux, voire d’avantage:
Un client peut être à la fois propriétaire et locataire; Dans
ce cas, le nom du propriétaire sera égal au nom du

51
 locataire si et seulement si il y a une correspondance entre
les identifiants.
Agir avec méthode :
Lorsqu’une entité possède une propriété qui ne peut pas
prendre de valeurs pour certaines occurrences, appliquer
le mécanisme de spécialisation : mécanisme permettant
de créer à partir d’une entité générale, plusieurs entités
possédant des caractéristiques spécifiques.
Lorsque les mêmes informations sont présentes dans deux
entités différentes, appliquer le mécanisme de
généralisation : mécanisme permettant de factoriser des
propriétés communes à plusieurs entités à travers la
création d’une entité plus générale.

III.8 Modèle Logique Relationnel

III.8.1 Exploitation de la BdD

A partir de l’univers du discours, la démarche d’Analyse et
de Conception des Systèmes d’Informations est la suivante :
1. Élaboration du dictionnaire de donnée épuré.
2. Comprendre la structure de la base : élaboration du
MCD ou MEAT.
3. Élaboration du Modèle Logique de Données
Relationnel (MLDR) en observant les règles de
passage du MCD au MLDR.

52
 4. Élaboration du Modèle Logique de Données
Relationnel normalisé (3FN) ou Schéma des
Relations.
5. Implantation physique de la base (table, jeux
d’occurrences, choix des clés primaires: CP, des clés
étrangères: CE / éventuellement des clés
secondaires: CS) à l’aide d’un SGBD-R MS ACCESS,
PARADOXE, ORACLE, etc.
6. Interrogation de la base de données en Algèbre
Relationnelle (Mode QBE) et / ou en langage
d’interrogation de données (Mode SQL: langage de
requêtes)
7. Conclusion

III.8.2 Historique sur le modèle relationnel

Conçu en 1970 par E.F CODD (alors chercheur chez IBM-
SAN JOSE- CALIFORNIE), Ce modèle qui se développe le
plus actuellement pour des raisons de simplicités de
représentation.
Basé sur la théorie des ensembles et les mathématiques
relationnelles, il permet d’appliquer aux données tous les
opérateurs ensemblistes et relationnels.
Le grand apport de ce modèle est la normalisation des
données.

53
 III.8.3 Fiche conseil
Pour éviter toute confusion de vocabulaire, on adopte les
notions du modèle correspondant:

Modèle Conceptuel Modèle Relationnel

ENTITE TABLE

ASSOCIATION TABLE, RELATION

IDENTIFIANT CLE PRIMAIRE

Une table est une relation Bi dimensionnée constituée :

• de colonnes qui correspondent aux données
• de lignes qui représentent les enregistrements
EXEMPLE:
Soit la relation « Ouvrage » ; Dans sa représentation
tabulaire, elle se représente ainsi :

54
Dans sa représentation en extension, la relation
« Ouvrage » se représente ainsi :
Ouvrage ( N°Ouvrage ,Titre, Auteur, Qte_stock)
➢ Degré :
Correspond aux nombres d’attributs de la relation. La
relation « Ouvrage » est de degré 4.
➢ Cardinalité :
Elle représente le nombre de tuples ou d’occurrences
ou de lignes de la relation. La cardinalité de
« Ouvrage » est 5.
➢ Clé Primaire :
Elle peut être mono ou multi attribut. La CP sert à
identifier une occurrence parmi n. Dans le cas de
«ouvrage», la clé est mono-valuée ou d’ordre 1.
➢ Clé Étrangère : ou Clé Secondaire

55
 Correspond à un attribut dans une relation, mais est
clé primaire dans une autre relation.
Ouvrage ( N°Ouvrage ,Titre, Auteur, Qte_stock, #N°Genre)
CS CP
Genre (N°Genre, Libelle_Genre)

Modèle Conceptuel correspondant

➢ Relation Statique:
C’est une relation qui ne contient pas de clé étrangère (Ex:
«GENRE»)
➢ Relation Dynamique :
C’est une relation qui contient une ou plusieurs clés
étrangères.
➢ Vocabulaire Anglais :
- CP : Primary Key
- CE : Foreign Key

56
 III.8.4 Domaine
Le domaine représente l’ensemble de valeurs admissible
d’un attribut. La prise en compte des concepts du modèle
relationnel doit se faire à partir d’un SGBD-R.
Pour construire une base de données cohérente, il est
nécessaire de respecter notamment les contraintes
structurelles imposées par le modèle de données.
On va étudier trois types de contraintes structurelles:
III.8.4.1 Contrainte d’intégrité de domaine
C’est une contrainte qui exprime qu’un attribut doit prendre
une valeur sur le domaine ou il a été défini.
Les différents domaines disponibles avec MS-ACCESS sont :
* TEXTE
* MEMO
* NUMERIQUE
* DATE/HEURE
* COMPTEUR
* BOOLEEN (Oui/Non)
* MONETIQUE
*LIAISON OLE : Il est possible d’incorporer des
objets; l’objet incorporé peut être un graphique, un
tableau, ou des multimédia; OLE veut dire
incorporation d’objets liés (Objet Linking and
Embedding).
III.8.4.2 Contrainte d’intégrité de relation

57
C’est une contrainte qui exprime qu’une clé primaire doit
être unique et non nulle.
III.8.4.3 Contrainte d’intégrité de référence ou
référentielle
C’est une contrainte qui exprime que la valeur d’un attribut
dans une relation doit exister dans une autre relation.

III.8.5 Règles de passage du MCD au MLD

➢ Règle N° 1 :

OUVRAGE (N°Ouvrage, Titre, Qte_Stock, #N°Genre)

GENRE (N°Genre, Libelle_genre)
La règle N° 1 porte sur une association de cardinalité 1,n
non porteuse de données.
➢ Règle N° 2 :
Association de cardinalité maximale n,n porteuse de
données.

58
OUVRAGE (N°Ouvrage, Titre, Qte_Stock, #N°Genre)
COLLECTION (N°Collection, Type_Collection)
ACHAT (N°Ouvrage, N°Collection, Prix_Achat)
L’association porteuse de donnée, donne lieu donc à
l’écriture d’une relation qui aura pour clé la concaténation
des clés des entités qui participent à cette association.
➢ Règle N° 3 :
Association de cardinalité maximale n,n non porteuse de
données

OUVRAGE (N°Ouvrage, Titre, Qte_Stock, #N°Genre)

AUTEUR (N°Auteur, Nom_auteur, Nationalité_auteur)
ECRIRE (N°Ouvrage, N°Auteur)

III.8.6 Modèle Relationnel du cas Ecole

La relation est la représentation structurale du fichier. Elle
est constituée de :
1. Un nom.
2. Un identifiant souligné.
3. Des attributs.
Ex : Client (Num_Cli, Nom_Cli, etc.)

59
 III.8.1 Règles
1. Toute entité devient une relation ;
Inspecter (Num_Inspect, Nom_Inspect, Pre_Inspect)
2. Dans le cas d’une CIF l’entité ayant pour cardinalité
(1,1) récupère un attribut supplémentaire qui est la clé
de l’entité opposé. On parle d’une clé étrangère repéré
par un .
Eleve (Num_ele, Nom_ele, Pre_ele, #Num_instit)
3. Toute association devient une relation ayant pour
clé, la concaténation des clés des entités liées et
nécessaire à l’identification d’un enregistrement de
cette nouvelle entité.
Participe (Num_ele, Code_atel, Jour)
III.8.2 Modèle relationnel de l’école
Inspecteur (Num_inspect, Nom_inspect, Pre_inspect)
Ecole (Code_eco, Nom_eco, Adr_eco,#Num_inspect)
Instituteur (Num_instit, Nom_instit, Pre_instit, Classe,
dat_entr, #Code_eco)
Eleve (Num_ele, Nom_ele, Pre_ele, #Num_instit)
Atelier (Code_atel, Nom_atel)
Specialite (Code_spe, Libelle)
Participe (Num_ele, Code_atel, jour)
Inspecte (Num_instit, Code_spe, Date, Note)
60
III.9 Modèle physique de la base

Le passage du modèle relationnel au modèle physique

consiste simplement à décrire physiquement les relations.
Un champ peut être déclaré comme une clé. En dépit de
cela, un champ peut être indexé ou pas :
➢ Soit pour augmenter les vitesses de recherche
➢ Soit parce que ce champ représente une clé étrangère
Les trois possibilités offertes sont :
1. Cas d’un champ quelconque : le champ n’est pas
indexé.
2. Cas d’un champ clé : indexé sans doublons.
3. Cas d’une clé étrangère : indexé avec doublons.
Par exemple dans le cas de la table Instituteur le champ
num_instit qui représente la clé principale sera indexé sans
doublons, et le champ code_eco qui représente la clé
étrangère sera indexé avec doublons.
Dans le cas de la table Participe le champ num_ele et le
champ cod_atel qui représentent par concaténation la clé
principale, seront indexés avec doublons. En effet la
combinaison des deux clés est unique mais chaque champ
peut contenir des doublons.

61
 ➢ Table Inspecteur : Fichier des inspecteurs

Clé Champs Type Largeur Dec. Index avec Index sans

doublons doublons

O Num_inspect Numérique 5 0 N O

Nom_inspect Caractère 25

Pre_inspect Caractère 25

➢ Table Ecole : Fichier des écoles

Clé Champs Type Largeur Dec. Index avec Index sans

doublons doublons

O Code_eco Caractère 5 N O

Nom_eco Caractère 25

Adr_eco Caractère 50

Num_inspect Numérique 5 0 O N

➢ Table Instituteur : Fichier des instituteurs

Clé Champs Type Largeur Dec. Index avec Indexsans

doublons doublons

O Num_instit Numérique 5 0 N O

Nom_instit Caractère 25

Pre_instit Caractère 25

Classe Caractère 5

62
 Date_entre Date 8

Syndique Booléen

Code_eco Caractère 5 O N

➢ Table Élève : Fichier des élèves

Clé Champs Type Largeur Dec. Index avec Index sans

doublons doublons

O Num_ele Numérique 5 0 N O

Nom_ele Caractère 25

Pre_ele Caractère 25

Num_instit Numérique 5 0 O N

➢ Table Atelier : Fichier des ateliers

Clé Champs Type Largeur Dec. Index avec Index sans

doublons doublons

O Code_atel Caractère 5 N O

Nom_atel Caractère 25

63
 ➢ Table Participe : Fichier des participations d’un
élève à un atelier

Clé Champs Type Largeur Dec. Index avec Index sans

doublons doublons

O Num_ele Numérique 5 0 O

O Code_atel Caractère 5 O

Jour Caractère 10

➢ Table Spécialité : Fichier des spécialités

Clé Champs Type Largeur Dec. Index avec Index sans

doublons doublons

O Code_sp Caractère 5 N O

Libelle Caractère 30

➢ Table Inspection : Fichier des inspections pour un

instituteur à une date données sur une spécialité
donnée

Clé Champs Type Largeur Dec. Index avec Index sans

doublons doublons

O Num_instit Numérique 5 0 O

O Code_sp Caractère 5 O

O Date Caractère 8 O

64
 CHAPITRE IV

Analyse et Conception des

Systèmes d’Information

Modèles de Traitements

65
IV.1 Modèle conceptuel des traitements (MCT)

IV.1.1 Introduction
Les traitements constituent la partie dynamique du système
d’information. Ils décrivent les actions à exécuter sur les
données afin d’obtenir les résultats attendus par
l’entreprise.
Les traitements ne sont en fait que la traduction en actions
des règles de gestion qui composent l’activité de
l’entreprise.
Vue d’ensemble de la finalité du MCT

Concept Objectif Préoccupation

Modèle Représenter les Le QUOI

Conceptuel traitements exécutés
(Sans le QUI ni
des par l’entreprise
le COMMENT)
Traitements indépendamment de
son organisation

VI.1.2 Concepts de base

VI.1.2.1 PROCESSUS
- Définition:
Le processus constitue un sous ensemble de l’activité de
l’entreprise dont les points d’entrée et de sortie sont
stables et indépendants des choix d’organisation.

66
 - Exemple:
Considérons l’activité de gestion commerciale d’une
entreprise. Les processus suivants peuvent être identifiés:
– Gestion des commandes,
– Gestion des factures,
– Gestion de la comptabilité clients.
La représentation schématique de ces trois processus
est la suivante:
Prise en compte Commande Compte Client
d’une commande acceptée à jour (J-1)

VI.1.2.2 OPERATION
a. Concept d’opération :
Généralement, un processus comporte un nombre
important de traitements qu’il convient de regrouper en
ensembles plus élémentaires appelés opérations.
- Définition:
Une opération est constituée d’un ensemble d’actions qui
sont exécutables sans interruption.

67
 Une opération est déclenchée pour répondre à la
sollicitation d’un événement et produire un résultat.
- Exemple:
L’ouverture d’un dossier patient des l’arrivée de celui-ci dans
un centre de soins. Cette opération peut se caractériser par
les éléments suivants:
- Evénement déclencheur : arrivée d’un patient
- Opération : ouverture du dossier qui comprend les
traitements :
- rédaction d’une fiche d’identification
- rédaction d’une fiche d’actes à pratiquer
- Résultat : dossier ouvert
- Formalisme:

68
 Arrivée d’un patient

b. Concept d’événement résultat

L’événement correspond à une sollicitation pour le système
d’information qui doit réagir par l’exécution d’une ou de
plusieurs actions en vue de traiter cet événement.
- Exemple :
Dans le domaine de la gestion de personnel; nous pouvons
représenter l’opération étude de la demande d’embauche
avec les événements et résultats associes.
La représentation ci après des concepts ne tient pas encore
compte du formalisme.

69
Enfin il peut être intéressant de distinguer deux types
d'événement pour un processus :
➢ Événement externe:
C’est un événement qui se produit à l’extérieur des
opérations du processus et qui interviendra dans le
déclenchement d’une opération du processus
➢ Événement interne:
C’est un événement qui se produit à la fin d’une opération.
A ce niveau il est appelé RESULTAT de l’opération. Ce
résultat pourra être lui-même un événement déclencheur
d’une autre opération.
c. Concept de synchronisation d’événement
L’exécution d’une opération est toujours conditionnée par un
ou plusieurs événements.
La synchronisation d’une opération correspond à la condition
d’exécution de l’opération. Cette condition se représente
sous forme de conditions booléennes d’événements.

70
 Exemple: représentons la condition d’exécution A ET (B OU
C)) d’une opération:

d. Règles d émission de résultats

L’émission de résultats par une opération peut être
conditionnée par des règles; ces règles sont appelées règles
d’émission des résultats

VI.1.2.3 REGLES DE CONSTRUCTION D’UN MCT

a. Règle 1:
Une opération est une suite non interrompue de traitements;
toute intervention d’un acteur externe qui entraînerait une
interruption provoque un découpage de l’opération.
71
 - Exemple: Atelier de réparation véhicule

Dans cet exemple; nous voyons l’application de la règle 1. En

effet la signature du client est considérée comme un
événement externe; d’où la représentation de 2 opérations
distinctes pour traiter l’arrivée d’un client.
b. Règle 2 :
A l’intérieur d’une opération, il ne doit pas apparaître de
résultat pouvant conditionner la suite du déroulement des
opérations du processus étudié, si tel était le cas, il faudrait
découper l’opération.
Cette règle traduit le fait qu’une même opération doit avoir
une certaine homogénéité par rapport aux résultats produits.

72
Une même opération ne peut pas comporter des traitements
de nature très différente.
Cette règle constitue un principe de découpage rationnel des
opérations.

73
 c. Recommandations à prendre en compte
pour l’élaboration d’un M.C.T.
Établir un M.C.T. par processus quand le domaine d’activité
comprend un très grand nombre d’opérations.
Ne représenter aucun élément d’ordre organisationnel ou
physique.
Exemple de types d’erreurs souvent commises:
- Représentation de la notion de fichier ou support
(physique),
- Critère de découpage d’opérations de niveau
organisationnel.
Dans le cas de déclanchement d’une opération conditionnée
par un événement qui ne se produit pas (Ex : relance si
74
paiement non effectué dans les 15 jours), il suffira de faire
figurer dans le conditionnement de l’opération une condition
portant sur le dépassement du temps.
Exemple:

Un même événement ne peut être déclencheur unique de 2

opérations à priori distinctes.
Dans ce cas deux erreurs sont possibles :
- Il peut manquer un autre événement dans l’une des
deux opérations,
- Les deux opérations n’en font qu’une.
Il est possible d’admettre le découpage en « opérations
fines » bien qu’aucun événement externe n’intervienne. Ceci
peut se justifier pour matérialiser un résultat intermédiaire
qui facilite en général la compréhension du M.C.T.

75
IV.2 Modèle organisationnel des traitements
(MOT)

IV.2.1 Présentation générale

Le modèle conceptuel des traitements a permis de
décomposer un processus en opérations décrivant ainsi
l’ensemble de l’activité de l’entreprise.
Cette description doit être maintenant complète par la prise
en considération de l’organisation choisie par l’entreprise.
Deux préoccupations sont prises en considération:
1. L’affectation des traitements aux postes de travail
2. Le niveau et le type d’automatisation des
traitements qui peuvent être:
➢ Des Traitements Manuels (MA),
➢ Des traitements automatisés selon 2 modes:
- traitements en Temps Réel (TR) appelés aussi
traitements à réponse immédiate,
- traitements en Temps Différé (TD) appelés aussi
traitements à réponse différée ou encore
traitements par lot.
De plus, les orientations générales de l’informatisation sont
aussi intégrées à ce niveau, ainsi selon le cas les éléments
suivants sont précisés :
➢ Les Traitements relevant de l’informatique centrale,
➢ Les traitements pris en charge par l’informatique
locale (appelée aussi informatique individuelle),

76
 ➢ Les traitements relevant de l’informatique
départementale.
Le Modèle Organisationnel des Traitements (M.O.T) permet
de représenter l’ensemble des traitements en prenant en
compte l’organisation de l’entreprise. Celle-ci sera
matérialisée par les postes de travail.
Chaque poste de travail correspond à une unité d’action
élémentaire dotée de moyens d’exécution : moyens en
personnel et moyens de traitement automatique selon les
cas.
A chaque opération du niveau conceptuel correspondra une
ou plusieurs PHASES dans le M.O.T.
Une succession de phases appartenant à un même
processus s’appellera PROCEDURE.
Représentation schématique de l’élaboration du M.O.T

77
 IV.2.2 Concepts, définitions et formalisme
IV.2.2.1 PROCEDURE
A chaque processus du M.C.T. correspondra une ou plusieurs
procédures produisant des résultats dans le M.O.T.
Une procédure, constituée d’un ensemble de traitements,
est déclenchée par un ou plusieurs événements externes.
Elle correspond à l’exécution par l’entreprise d’un ensemble
de règles de gestion produisant un ou plusieurs résultats.
Exemple:
– Procédure de recrutement ;
– Procédure de traitement des commandes.
Une procédure appartient à un seul processus du M.C.T.
IV.2.2.2 PHASE
Sous ensemble de la procédure, la phase est une suite non
interrompue de traitements, de même périodicité, exécutés
par un poste de travail.
Exemple: Pour la procédure RECRUTEMENT nous pouvons
avoir les phases :
➢ PHASE 1: enregistrement de la demande d’embauche,
➢ PHASE 2: Contrôle du dossier de candidature,
➢ PHASE 3: édition de l’acte de recrutement.

78
Formalisme :

A chaque opération du M.C.T correspondra soit :

➢ Une phase unique dans le M.O.T.
Cas d’une opération pouvant être exécutée complètement
par un poste de travail dans une même unité de temps.
Exemple: contrôle formel d’un dossier de candidature: voir
fig. 5.1,
➢ Plusieurs phases dans le M.O.T.
Cas d’une opération devant être décomposé en plusieurs
sous ensembles du faits :
– de périodicités différentes de certains traitements,
– d’un découpage résultant d’une contrainte
d’organisation.
En reprenant le même exemple que précédemment mais en
considérant que :

79
 – un contrôle du dossier au plan professionnel est
effectué par le responsable du poste à pouvoir (service
technique),
– un contrôle administratif est effectué par le service
administratif.
Une nouvelle représentation du M.O.T. est donnée à la
figure 5.2.

80
 VI.2.2.3 TACHE
Une tache, représente un ensemble de traitements
élémentaires exécutes à l’intérieur d’une phase. Une phase
peut comprendre une ou plusieurs taches selon le cas.
Exemple:
Soit la phase du M.O.T. suivante :

81
Cette phase contient les taches suivantes:
➢ Tache 1 : contrôle d’existence du dossier patient,
➢ Tache 2 : création d’un dossier (si nouveau patient),
➢ Tache 3 : mise à jour des actes à pratiquer.
Le niveau de détail de description d’une phase dépend de
l’étape de conception; en général, la démarche suivante est
appliquée:

82
 ETUDE PREALABLE ETUDE DETAILLEE

Liste exhaustive des Description

PROCEDURES procédures. générale de chaque
procédure.

Enchaînement des Enchaînement

phases exhaustif des
représentatives par phases par
PHASES procédure. procédure.
Description générale Description
des phases. détaillée des
phases.

Liste des principales Liste exhaustive de

taches toutes les taches.
TACHES Description
détaillée de toutes
les taches.

IV.3 Modèle Opérationnel des Traitements

IV.3.1 Introduction
Le but du Modèle oPérationnel des Traitements (M.P.T.) est
de décrire l’architecture des logiciels qui devront être
réalisés à partir du Modèle Organisationnel des traitements.
Le M.O.T. a permis de décrire :
➢ Les phases « temps réel » avec la description:
– Des écrans de leur enchaînement,
– Des traitements associés à chaque écran,
– Des états papiers éventuels,
83
 ➢ Les phases « temps différé » avec la description :
– Des états,
– Des traitements regroupés en tache.
Le M.P.T. devra permettre de décrire l’architecture des
unités de traitement correspondant aux phases décrites
dans le M.O.T. Ces unités de traitement seront selon le cas:
➢ Des transactions (pour les phases « temps réel »
➢ Des programmes « batch » (pour les phases « temps
différé »)
L’étude du M.P.T. sera traitée pour ces deux cas.

IV.3.2 Structuration des transactions

L’environnement de développement interviendra dans la
description et la structuration des transactions. C’est ainsi
que par exemple le générateur de grilles d’écran et le
moniteur de gestion des transactions seront deux éléments
déterminant dans la production des transactions.
Démarche d’élaboration des transactions:
Règle 1:
➢ à chaque écran correspondra une transaction
Règle 2:
➢ Chaque transaction sera structurée et représentée de
la manière suivante (normalisation I.S.O)

84
Règle 3:
➢ Établir des recommandations ergonomiques pour
l’affichage écran et la saisie des données.
➢ Définir des normes d’affichage et de saisie.
Exemple: Normaliser l’utilisation des touches de fonction.
Règle 4:
➢ Standardiser la description des traitements en
distinguant 4 types de traitement :
– Les contrôles (avec ou sans saisie de données) ;
– Les mises à jour des données stockées ;
– Les calculs ;
– Les éditions.
Autres règles ou recommandations :
➢ Prévoir la réalisation de modules de service accessibles
par toutes les transactions.

85
Exemple :
– Module de contrôle de date,
– Module de contrôle spécifique,
– Module de transformation de code.
➢ Penser à bien gérer la confidentialité d’accès aux
informations: gestion des droits par utilisateur, par
information, par type de traitement, etc.
➢ Penser à la mise en œuvre de procédure de sécurité:
journalisation des mouvements de mise à jour en vue
d’une reprise ultérieure (suite à un incident).
➢ Gérer l’enchaînement des transactions.

VI.3.3 Structuration des programmes « batch »

Règles de découpage des programmes « batch »:
➢ Découpage selon la périodicité des traitements ;
Ex : distinguer les programmes journaliers des programmes
mensuels
➢ Découpage selon le type de programme ;
Quatre types de programme peuvent être distingues:
– programme de contrôle
– programme de calcul
– programme de mise à jour
– programme d’édition

86
 Conclusion

Ce support a pour objectif, au-delà de la transmission de

données théoriques, de proposer un réel savoir faire sur
Merise en favorisant une approche pratique de cette
méthode. A l’issue de cette lecture, on serait en mesure de
situer Merise dans la chronologie des méthodologies de
conception des Systèmes d’Information. Grace à l’étude de
cas présentée dans cet ouvrage, on pourrait exploiter la
méthode pas à pas sur des cas personnels concrets.
Enfin, et pour terminer par là ou il aurait fallu commencer,
expliquons ce que veut dire MERISE. Plutôt que de proposer
comme veut la tradition, une explication de chacune des
lettres, il paraît plus utile de retenir l’image du Merisier,
arbre bien connu qui ne peut porter de beaux fruits que si
on lui greffe une branche de cerisier ; ainsi en va-t-il des
méthodes bien conçues qui ne produisent bien que si la
greffe sur l’organisation est réussit.

87
Bibliographie – Webographie

➢ Jean-Patrick Matheron ; «Comprendre Merise outils

conceptuels et organisationnels» ; EYROLLES 2005.
➢ Jean-Patrick Matheron ; «Exercices et cas pour
Comprendre Merise» ; EYROLLES 2003.
➢ Hubert Tardieu, Arnold Rochfeld, René Colletti ; «La
méthode Merise Principe et outils» ; Editions
d’Organisation 2003.
➢ Joseph Gabay ; «Apprendre et pratiquer Merise» ;
Masson 1993.
➢ Joseph Gabay ; « Merise et UML pour la modelistion des
systèmes d’information» ; DUNOD 2003
➢ Drifa Seba ; «Merise Concepts et mise en œuvre» ; ENI
éditions 2003.
➢ [Link]
➢ [Link]
[Link]
➢ [Link]
methode-merise-etape-par-etape
➢ [Link]

88
 Nadia AFIFI’s Biography
Nadia AFIFI is currently a Professor
in the Computer Engineering
Department of the Higher School of
Technology (ESTC), Hassan II
University of Casablanca - Morocco
(UH2C).
She is IEEE Senior Member; part of
“Software Engineering, Business
Intelligence an and Security” (SEBIS)
research team of “Networks, Computer, Telecom &
Multimedia” (RITM) Laboratory (ESTC).
She received a PhD in Computer Engineering from UH2C;
and HDR (Habilitation to Direct Research) in IT. She had
received an Electrical Engineering, Computer Systems
degree from the Mohammadia School of Engineers (EMI),
Mohammed V University – Rabat. Prior to her academic
career, she had worked as a software engineer in the
Finance Ministry (Rabat).
Pr Nadia’s teaching and research interests include,
Information Systems Modeling (UML, MDA, etc.),
Information Systems Security, Software Architecture ,Human
Machine Interface, Dependability, Business Intelligence;
Cloud Computing Security, Big Data, IoT and Artificial
Intelligence.

89