Merise : introduction et démarche

Merise est une méthode française de conception de systèmes d’information, très utilisée pour modéliser une base de données relationnelle. Elle propose d’aller du sens (ce que l’organisation manipule) vers le SQL (les tables), en trois niveaux de modèles. Les exemples de cette rubrique suivent un fil rouge : une petite boutique (clients, commandes, articles).

Pourquoi modéliser avant de créer les tables

Sans modèle	Avec un modèle
Tables ajoutées au fil de l’eau, redondances	Structure pensée, sans duplication
Incohérences (un client avec deux adresses différentes)	Règles de cohérence explicites
Changements coûteux une fois les données en place	Changements discutés sur un schéma
Difficile à expliquer à une équipe	Vocabulaire commun et schémas partagés

Une base mal modélisée est difficile à corriger après l’arrivée des données : quelques heures de modélisation évitent des migrations pénibles.

Les trois niveaux de modèles

Niveau	Modèle	Question	Dépend d’un SGBD ?
Conceptuel	MCD (modèle conceptuel de données)	Quelles informations, quels liens, quelles règles ?	Non
Logique	MLD (modèle logique de données)	Quelles tables, quelles clés ? (modèle relationnel)	Non (famille relationnelle)
Physique	MPD (modèle physique de données)	Quels types, index, moteur ? Script SQL	Oui (PostgreSQL, MySQL, MariaDB, SQLite)

Besoins  ──▶  MCD  ──▶  MLD  ──▶  MPD (SQL)  ──▶  Base de données
(texte)     entités,   tables,    types,
            associations clés     index

Chaque niveau se déduit du précédent par des règles précises (voir Du MCD au modèle logique et Du modèle physique au SQL).

Données et traitements

Merise sépare deux aspects :

Aspect	Modèles	Objet
Données	MCD, MLD, MPD	Ce que le système mémorise (cette rubrique)
Traitements	MCT (modèle conceptuel des traitements), MOT	Ce que le système fait : événements, opérations, résultats

Cette rubrique traite la modélisation des données. Pour décrire les traitements, des diagrammes d’activité ou de séquence d’UML sont plus répandus aujourd’hui (voir UML : diagrammes d’activité et d’états).

Démarche de conception

1. Recueillir les besoins : entretiens, documents (factures, formulaires), règles de gestion.
2. Établir le dictionnaire de données : liste des informations élémentaires (nom, adresse, date de commande…).
3. Écrire les règles de gestion en phrases (« Un client peut passer plusieurs commandes ; une commande concerne un seul client »).
4. Construire le MCD : entités, associations, cardinalités, identifiants.
5. Valider avec les utilisateurs, puis normaliser (Normalisation).
6. Dériver le MLD (tables et clés).
7. Écrire le MPD : script SQL pour le SGBD choisi.
8. Tester avec des données réelles, ajuster.

Le dictionnaire de données

Information	Type	Règle	Exemple
Nom du client	Texte, 100	Obligatoire	Martin
E-mail du client	Texte, 255	Unique	alice@exemple.com
Date de commande	Date et heure	Obligatoire	2026-01-15 10:30
Prix d’un article	Montant	Positif ou nul	49,00 €
Quantité commandée	Entier	Au moins 1	2

Une information du dictionnaire devient plus tard une propriété d’entité ou d’association.

Règles de gestion du fil rouge

• Un client est identifié par un numéro ; il a un nom, un e-mail et une adresse.
• Un client peut passer plusieurs commandes ; une commande est passée par un seul client.
• Une commande concerne un ou plusieurs articles, avec une quantité pour chacun.
• Un article est identifié par une référence ; il a un libellé et un prix. Il peut ne figurer dans aucune commande.
• Une commande a une date et un statut.

Ces règles deviendront le MCD (voir Le modèle conceptuel de données). Les écrire est l’étape la plus utile : elles lèvent les ambiguïtés avant de dessiner.

Merise et UML

	Merise	UML
Origine	France, années 1970-80	Standard international (OMG), années 1990
Usage principal	Bases de données relationnelles	Logiciel orienté objet (et au-delà)
Modèle de données	MCD, MLD, MPD	Diagramme de classes
Traitements	MCT, MOT	Activité, séquence, cas d’utilisation…
Enseignement	Très présent en France	Très présent dans le monde

Les deux se complètent : le diagramme de classes UML ressemble au MCD de Merise ; on peut modéliser une base avec l’un ou l’autre (voir UML : classes vers base de données). Le plus important : choisir un formalisme et l’appliquer avec rigueur.

Ce que Merise ne dit pas

Merise décrit la structure et les règles des données ; il ne choisit pas le SGBD, n’optimise pas les requêtes et ne traite pas la sécurité (droits, chiffrement). Ces sujets relèvent du modèle physique et de l’exploitation (voir PostgreSQL : utilisateurs et droits, MariaDB : index et performances).

Choisir son SGBD (pour le MPD)

Besoin	Piste
Base relationnelle riche, standard SQL	PostgreSQL
Compatibilité MySQL, hébergement courant	MariaDB ou MySQL
Application locale, fichier unique	SQLite
Données sans schéma fixe	Bases de documents (MongoDB, CouchDB) : la modélisation Merise s’applique moins directement

Dépannage

Symptôme	Piste
Difficile de décider ce qu’est une entité	Une entité est une chose identifiable qui a des propriétés et existe indépendamment (client, article) ; une simple valeur est une propriété
Le MCD devient énorme	Découper par domaine (clients, commandes, stock), un MCD par domaine
Désaccord avec les utilisateurs	Relire les règles de gestion écrites ; valider chaque cardinalité
Hésitation entre Merise et UML	Voir le tableau ci-dessus ; les deux mènent aux mêmes tables
Changement de besoin en cours de projet	Modifier le MCD d’abord, puis redériver MLD et MPD (migration)

Ubuntu 24.04 et 26.04 : différences à connaître

Aucune : la modélisation est indépendante du système. Pour tester les scripts, installer un SGBD sur Ubuntu (voir les rubriques PostgreSQL et MariaDB).

Pour aller plus loin

• Merise (Wikipédia)
• Suite : Le modèle conceptuel de données

Dans la même rubrique

• Introduction et démarche
• Le modèle conceptuel de données
• MCD avancé
• Du MCD au modèle logique
• Normalisation
• Du modèle physique au SQL
• Méthode, outils et pièges