Cours Approfondi sur MERISE
Méthode d’Étude et de Réalisation Informatique par Sous-
Ensembles
Introduction Générale
MERISE est une méthode française de conception et de développement de systèmes
d’information, créée dans les années 1970-1980. Elle est encore aujourd’hui très utilisée
dans les entreprises françaises et dans l’enseignement.
Pourquoi MERISE ?
Structurer la réflexion avant de coder
Séparer les données des traitements
Communiquer entre équipes techniques et métier
Produire une documentation claire et rigoureuse
Les 3 niveaux d’abstraction de MERISE
Modèles
Niveau Description
concernés
Le QUOI — ce que fait le système, sans se
Conceptuel MCD, MCT
soucier du comment
Le QUI, OÙ, QUAND — organisation humaine MOD, MOT,
Organisationnel/Logique
et logique MLD
Le COMMENT — les moyens techniques mis
Physique MPD, MPT
en œuvre
PARTIE 1 — Le Système d’Information (SI)
1.1 Définition
Un système d’information est l’ensemble des ressources (humaines, matérielles,
logicielles, données) permettant de collecter, stocker, traiter et diffuser l’information au sein
d’une organisation.
1.2 Les 4 fonctions du SI
1. Collecter : recueillir les données de l’environnement
2. Mémoriser : stocker les données de manière durable
3. Traiter : transformer les données en informations utiles
4. Diffuser : transmettre les informations aux utilisateurs
1.3 Les sous-systèmes
Système de pilotage : prend les décisions
Système opérant : réalise les activités
Système d’information : assure la communication entre les deux
PARTIE 2 — Le Modèle Conceptuel des Données (MCD)
Le MCD représente la structure des données de manière indépendante de tout choix
technique. C’est le cœur de MERISE.
2.1 Les entités
Une entité (ou objet) représente un objet du monde réel sur lequel on veut stocker des
informations.
Règles de notation :
Rectangle avec le nom de l’entité en majuscules
Liste des attributs à l’intérieur
Un attribut souligné = identifiant (clé primaire)
Exemple :
┌─────────────┐
│ CLIENT │
├─────────────┤
│ #numClient │ ← identifiant (souligné)
│ nomClient │
│ prenomClient│
│ adresse │
│ email │
└─────────────┘
À faire :
Identifier toutes les entités du domaine étudié
Chaque entité doit avoir un identifiant unique
Les attributs doivent être atomiques (non décomposables)
Ne pas mettre d’attributs calculés
2.2 Les associations
Une association représente un lien entre deux ou plusieurs entités.
Règles de notation :
Ellipse ou rectangle arrondi avec le verbe d’association
Reliée aux entités par des traits
Peut contenir des attributs propres
2.3 Les cardinalités (Point crucial)
Les cardinalités indiquent le nombre minimum et maximum de fois qu’une occurrence
d’une entité participe à une association.
Format : (min, max)
Cardinalité Signification
(0,1) Zéro ou une fois
(1,1) Exactement une fois
(0,N) Zéro ou plusieurs fois
(1,N) Au moins une fois
Comment lire les cardinalités : Pour lire la cardinalité d’une entité A dans une association
avec B :
“Une occurrence de A participe au minimum X fois et au maximum Y fois à
l’association”
Exemple complet :
CLIENT (1,N) ──── PASSER ──── (0,N) COMMANDE
Un client passe au moins 1 et au plus N commandes
Une commande est passée par 0 à N clients
À faire :
Toujours vérifier les cardinalités dans les deux sens
Justifier chaque cardinalité par une règle de gestion
Les cardinalités (1,1) et (0,1) indiquent souvent une clé étrangère future
2.4 Les types d’associations selon les cardinalités
Type Cardinalités Exemple
One-to-One (1:1) (1,1) — (1,1) Un client a un seul passeport
One-to-Many (1:N) (1,1) — (1,N) Un département a plusieurs employés
Many-to-Many (N:M) (1,N) — (1,N) Des étudiants suivent plusieurs cours
2.5 Les associations ternaires
Une association peut relier 3 entités ou plus. Utilisée quand la relation ne peut pas se
décomposer sans perdre de l’information.
2.6 Les associations réflexives (récursives)
Une entité peut être associée à elle-même.
EMPLOYE(#numEmp, nom) ←──── ENCADRER ────→ (même entité)
Un employé peut encadrer plusieurs employés, un employé est encadré par au plus un
employé.
2.7 Règles de construction du MCD
À faire :
1. Lister toutes les règles de gestion métier avant de commencer
2. Nommer les entités avec des noms communs au singulier
3. Nommer les associations avec des verbes à l’infinitif
4. Vérifier que chaque entité a un identifiant
5. S’assurer que les attributs sont bien placés
À ne pas faire :
Mettre des clés étrangères dans le MCD (c’est le niveau physique)
Créer des attributs composés (décomposer adresse en rue, ville, CP)
Oublier de valider avec les utilisateurs métier
PARTIE 3 — Le Modèle Logique des Données (MLD)
Le MLD est la traduction du MCD en tables relationnelles.
3.1 Règles de passage du MCD au MLD
Règle 1 — Toute entité devient une table
CLIENT(#numClient, nomClient, prenomClient, adresse, email)
Règle 2 — Association 1:N (One-to-Many)
La clé primaire du côté “1” migre vers la table du côté “N” en tant que clé étrangère.
MCD : CLIENT (1,1) ──── PASSER ──── (0,N) COMMANDE
MLD :
CLIENT(#numClient, nom, prenom)
COMMANDE(#numCommande, dateCmd, montant, numClient*)
↑ clé étrangère
Règle 3 — Association N:M (Many-to-Many)
L’association devient une table de liaison avec les clés primaires des deux entités +
attributs propres de l’association.
MCD : ETUDIANT (1,N) ──── INSCRIRE (note) ──── (1,N) COURS
MLD :
ETUDIANT(#numEtudiant, nom, prenom)
COURS(#codeCours, intitule, credits)
INSCRIRE(#numEtudiant*, #codeCours*, note)
Règle 4 — Association 1:1 (One-to-One)
La clé primaire de l’une migre vers l’autre.
PERSONNE(#numPersonne, nom, prenom)
PASSEPORT(#numPasseport, dateExpiration, numPersonne*)
Règle 5 — Association réflexive
Ajouter une clé étrangère qui référence la même table.
EMPLOYE(#numEmp, nom, numEmpSuperieur*)
3.2 Notation du MLD
Clé primaire : # ou soulignée
Clé étrangère : ***** ou en italique
PARTIE 4 — Le Modèle Physique des Données (MPD)
Le MPD est la traduction concrète du MLD dans un SGBD spécifique.
4.1 Ce qui change par rapport au MLD
Typage précis des données (VARCHAR, INT, DATE…)
Contraintes d’intégrité (NOT NULL, UNIQUE, CHECK…)
Index pour optimiser les performances
4.2 Exemple de MPD en SQL
CREATE TABLE CLIENT (
numClient INT PRIMARY KEY AUTO_INCREMENT,
nomClient VARCHAR(50) NOT NULL,
prenomClient VARCHAR(50) NOT NULL,
adresse VARCHAR(200),
email VARCHAR(100) UNIQUE
);
CREATE TABLE COMMANDE (
numCommande INT PRIMARY KEY AUTO_INCREMENT,
dateCmd DATE NOT NULL,
montant DECIMAL(10,2),
numClient INT NOT NULL,
FOREIGN KEY (numClient) REFERENCES CLIENT(numClient)
);
4.3 Les types de données courants
Type SQL Utilisation
INT / BIGINT Nombres entiers
DECIMAL(n,d) Nombres décimaux précis
VARCHAR(n) Chaînes de caractères variables
CHAR(n) Chaînes de longueur fixe
DATE Dates (YYYY-MM-DD)
DATETIME Date + heure
BOOLEAN Vrai/Faux
TEXT Textes longs
PARTIE 5 — Le Modèle Conceptuel des Traitements (MCT)
Le MCT représente ce que fait le système en réponse à des événements, sans se
soucier de qui le fait ni comment.
5.1 Les concepts du MCT
L’événement : un fait qui déclenche un traitement.
Événement entrant : vient de l’extérieur du système
Événement résultant : produit par le traitement
L’opération : un ensemble d’actions déclenchées par un ou plusieurs événements.
La synchronisation : exprime la condition de déclenchement (ET, OU).
La règle d’émission : détermine quel événement résultant est produit.
5.2 Schéma d’une opération MCT
Commande reçue Paiement reçu
│ │
└──────── ET ─────────┘
│
┌───────────────┐
│ TRAITER LA │
│ COMMANDE │
│ - Vérifier │
│ stock │
│ - Préparer │
│ colis │
└───────────────┘
│
┌──────────┴──────────┐
[OK] [Rupture]
│ │
Commande validée Commande en attente
5.3 Règles de construction du MCT
À faire :
Identifier tous les événements déclencheurs
Définir clairement les règles d’émission
Couvrir tous les cas (succès et erreurs)
Rester au niveau conceptuel (pas de technique)
PARTIE 6 — Le Modèle Organisationnel des Traitements
(MOT)
Le MOT précise QUI fait QUOI, OÙ et QUAND — il intègre la dimension humaine et
organisationnelle.
6.1 Les postes de travail
On définit les postes de travail (acteurs) qui réalisent les traitements.
6.2 Les types de tâches
Type Description
Manuelle Réalisée entièrement par un humain
Automatique Réalisée entièrement par l’ordinateur
Interactive Dialogue homme-machine
Conversationnelle Dialogue en temps réel
6.3 Représentation du MOT (tableau)
┌───────────────┬──────────────┬──────────────┬────────────────┐
│ Phase │ Client │ Commercial │ Comptable │
├───────────────┼──────────────┼──────────────┼────────────────┤
│ Commande │ Saisit cmd │ Valide cmd │ │
├───────────────┼──────────────┼──────────────┼────────────────┤
│ Livraison │ Reçoit colis │ Édite BL │ Édite facture │
├───────────────┼──────────────┼──────────────┼────────────────┤
│ Paiement │ Règle fact │ │ Enregistre pmt │
└───────────────┴──────────────┴──────────────┴────────────────┘
PARTIE 7 — Le Dictionnaire des Données
Le dictionnaire des données est un inventaire exhaustif de toutes les données du
système.
7.1 Structure du dictionnaire
Colonne Description
Nom Nom de la donnée (mnémonique)
Désignation Description lisible
Type AN (alphanumérique), N (numérique), D (date), B (booléen)
Taille Longueur maximale
Contrainte Valeurs possibles, obligatoire/optionnel
7.2 Exemple de dictionnaire
Nom Désignation Type Taille Contrainte
numClient Numéro client N 10 Obligatoire, unique
nomClient Nom du client AN 50 Obligatoire
email Adresse email AN 100 Unique, format email
montantCmd Montant commande N 10,2 >0
7.3 À faire pour le dictionnaire
Lister TOUTES les données avant de construire le MCD Éliminer les redondances
Normaliser les noms (convention de nommage cohérente) Identifier les données
calculées (ne pas les mettre dans le MCD)
PARTIE 8 — La Normalisation
La normalisation vise à éliminer les redondances et anomalies dans les tables.
8.1 Première Forme Normale (1FN)
Règle : Chaque attribut doit être atomique (indivisible) et il doit exister une clé primaire.
Pas 1FN :
CLIENT(numClient, nom, telephone1; telephone2; telephone3)
1FN :
CLIENT(numClient, nom)
TELEPHONE(numClient*, numero)
8.2 Deuxième Forme Normale (2FN)
Règle : Être en 1FN + tout attribut non-clé doit dépendre de toute la clé primaire.
Pas 2FN :
LIGNE_COMMANDE(#numCmd, #refProduit, qte, libelleProduit)
↑ dépend seulement de refProduit
2FN :
LIGNE_COMMANDE(#numCmd*, #refProduit*, qte)
PRODUIT(#refProduit, libelleProduit)
8.3 Troisième Forme Normale (3FN)
Règle : Être en 2FN + aucune dépendance transitive.
Pas 3FN :
EMPLOYE(#numEmp, nom, codeService, nomService)
↑ nomService dépend de codeService, pas de numEmp
3FN :
EMPLOYE(#numEmp, nom, codeService*)
SERVICE(#codeService, nomService)
PARTIE 9 — Démarche Complète MERISE
Étape 1 : Étude préalable
Analyser l’existant
Identifier les problèmes
Définir les objectifs
Évaluer la faisabilité
Étape 2 : Étude détaillée (niveau conceptuel)
1. Recueil des données → Dictionnaire des données
2. Identification des règles de gestion
3. Conception du MCD
4. Conception du MCT
Étape 3 : Étude technique (niveau logique/organisationnel)
1. Passage MCD → MLD
2. Conception du MOT
3. Vérification de la cohérence
Étape 4 : Réalisation (niveau physique)
1. Passage MLD → MPD (SQL)
2. Développement des traitements
3. Tests et validation
PARTIE 10 — Exemple Complet : Gestion d’une Bibliothèque
Règles de gestion
Un adhérent peut emprunter plusieurs livres
Un livre peut être emprunté par plusieurs adhérents (à des moments différents)
Un livre a un seul auteur principal
Un auteur peut avoir écrit plusieurs livres
Dictionnaire des données
Nom Type Taille
numAdherent N 8
nomAdherent AN 50
isbn AN 13
titreLivre AN 200
numAuteur N 8
nomAuteur AN 50
dateEmprunt D -
dateRetour D -
MCD
┌──────────────┐ ┌─────────────┐
│ ADHERENT │ │ LIVRE │
├──────────────┤ ├─────────────┤
│#numAdherent │ │ #isbn │
│ nomAdherent │ │ titreLivre │
│ prenomAdh. │ │ anneePubli │
│ dateInscript │ └──────┬──────┘
└──────┬───────┘ (1,1)│ECRIRE(0,N)
│ │
EMPRUNTER ┌──────────────┐
(0,N) (0,N) │ AUTEUR │
│ ├──────────────┤
dateEmprunt │ #numAuteur │
dateRetour │ nomAuteur │
└──────────────┘
MLD
ADHERENT(#numAdherent, nomAdherent, prenomAdherent, dateInscription)
AUTEUR(#numAuteur, nomAuteur, prenomAuteur)
LIVRE(#isbn, titreLivre, anneePublication, numAuteur*)
EMPRUNTER(#numAdherent*, #isbn*, #dateEmprunt, dateRetour, dateRetourPrevue)
MPD (SQL)
CREATE TABLE ADHERENT (
numAdherent INT PRIMARY KEY AUTO_INCREMENT,
nomAdherent VARCHAR(50) NOT NULL,
prenomAdherent VARCHAR(50) NOT NULL,
dateInscription DATE NOT NULL DEFAULT CURRENT_DATE
);
CREATE TABLE AUTEUR (
numAuteur INT PRIMARY KEY AUTO_INCREMENT,
nomAuteur VARCHAR(50) NOT NULL,
prenomAuteur VARCHAR(50)
);
CREATE TABLE LIVRE (
isbn CHAR(13) PRIMARY KEY,
titreLivre VARCHAR(200) NOT NULL,
anneePublication YEAR,
numAuteur INT NOT NULL,
FOREIGN KEY (numAuteur) REFERENCES AUTEUR(numAuteur)
);
CREATE TABLE EMPRUNTER (
numAdherent INT NOT NULL,
isbn CHAR(13) NOT NULL,
dateEmprunt DATE NOT NULL,
dateRetour DATE,
dateRetourPrevue DATE NOT NULL,
PRIMARY KEY (numAdherent, isbn, dateEmprunt),
FOREIGN KEY (numAdherent) REFERENCES ADHERENT(numAdherent),
FOREIGN KEY (isbn) REFERENCES LIVRE(isbn)
);
PARTIE 11 — Erreurs Fréquentes à Éviter
Erreurs dans le MCD
Erreur Correction
Oublier l’identifiant d’une entité Toujours définir une clé unique
Mettre des clés étrangères dans le MCD Les FK apparaissent seulement au MLD
Attribut non atomique Décomposer (ex: adresse → rue, CP, ville)
Cardinalités inversées Relire dans les deux sens
Erreurs dans le passage MCD → MLD
Erreur Correction
Oublier une table de liaison pour N:M Toujours créer une table intermédiaire
Mauvais sens de migration de la FK La FK va vers le côté N
Oublier les attributs de l’association Les inclure dans la table de liaison
Récapitulatif des Modèles MERISE
Modèle Niveau Objet Rôle
MCD Conceptuel Données Structure des données métier
MCT Conceptuel Traitements Opérations métier
MLD Logique Données Tables relationnelles
MOT Organisationnel Traitements Qui fait quoi, quand
MPD Physique Données SQL concret
MPT Physique Traitements Code applicatif
Ce cours couvre l’essentiel de la méthode MERISE telle qu’enseignée en BTS, DUT et
Licence professionnelle en France.