Merise : méthode, outils et pièges

Conduire une modélisation

Étape	Livrable	Avec qui
1. Cadrer	Périmètre, acteurs, objectifs	Commanditaire
2. Recueillir	Documents, entretiens, règles de gestion écrites	Utilisateurs
3. Dictionnaire de données	Liste des informations, types, contraintes	Équipe
4. MCD	Schéma + commentaire des cardinalités	Équipe, validé par les utilisateurs
5. Normalisation	MCD vérifié	Équipe
6. MLD	Tables, clés	Équipe
7. MPD	Script SQL du SGBD choisi	Développeurs
8. Jeux d’essai	Données réalistes, scénarios	Équipe, utilisateurs

Le dialogue avec les utilisateurs est plus important que le formalisme : un MCD élégant qui ne correspond pas à la réalité ne sert à rien. Relire chaque cardinalité à voix haute avec eux.

Bien poser les règles de gestion

Une règle de gestion est une phrase simple qui peut être vraie ou fausse :

Qualité	Mauvais	Bon
Précise	« Un client commande des choses »	« Un client peut passer zéro, une ou plusieurs commandes »
Complète (minimum et maximum)	« Une commande a des articles »	« Une commande contient au moins un article »
Sans ambiguïté	« Un article a un prix »	« Un article a un prix courant ; chaque ligne de commande conserve le prix payé »
Testable	« Les données doivent être cohérentes »	« Une quantité commandée est au moins égale à 1 »

Outils

Outil	Usage	Remarque
Mocodo	Génère un MCD, le MLD et le SQL à partir d’un texte	Libre, texte versionnable
Looping	Éditeur Merise graphique (MCD, MLD, MPD)	Logiciel de bureau
JMerise, AnalyseSI	Éditeurs Merise	Pour l’enseignement
MySQL Workbench, pgModeler, DBeaver	Schémas relationnels (modèle physique), génération et rétro-ingénierie de SQL	Pour le niveau logique et physique
draw.io (diagrams.net), Excalidraw	Dessin libre	Aucune vérification des règles
PlantUML, Mermaid	Schémas décrits en texte (diagramme de classes ou entité-relation)	Voir UML : outils et PlantUML

Mocodo : Merise en texte

sudo apt install python3-pip pipx
pipx install mocodo
mocodo --version

boutique.mcd :

CLIENT: num_client, nom, email, adresse
PASSER, 0N CLIENT, 11 COMMANDE
COMMANDE: num_commande, date_commande, statut
CONTENIR, 1N COMMANDE, 0N ARTICLE: quantite, prix_unitaire
ARTICLE: reference, libelle, prix, stock

mocodo --input boutique.mcd                 # produit le schéma (SVG) et d'autres fichiers
mocodo --input boutique.mcd --relations text    # affiche le MLD
mocodo --input boutique.mcd --relations postgres  # produit un script SQL (selon les options de la version)

La syntaxe et les options exactes dépendent de la version : consulter la documentation de Mocodo (liens ci-dessous). Écrire le MCD en texte permet de le versionner dans Git avec le code : chaque modification du modèle apparaît dans l’historique et la revue de code.

Rétro-ingénierie : de la base au schéma

Pour documenter une base existante :

sudo apt install postgresql-autodoc graphviz        # PostgreSQL : documentation et diagramme
sudo -u postgres psql boutique -c '\d+ commande'    # description d'une table

Des outils (DBeaver, pgModeler, MySQL Workbench) produisent un diagramme à partir d’une base existante ; vérifier le résultat : un schéma généré sans les règles de gestion est un point de départ, pas un MCD.

Versionner et documenter

docs/modele/
├── boutique.mcd            # source du MCD (Mocodo)
├── boutique.svg            # schéma généré
├── regles-de-gestion.md    # règles de gestion en phrases
├── dictionnaire.md         # dictionnaire de données
└── CHANGELOG.md            # évolutions du modèle
db/
├── schema.sql              # schéma de référence
└── migrations/
    ├── 001_initial.sql
    └── 002_ajout_telephone.sql

Pratique	Raison
Sources texte dans Git	Historique, relecture
Le schéma est un produit du modèle, pas l’inverse	Modifier le modèle d’abord
Garder les règles de gestion à côté du schéma	Le « pourquoi » des cardinalités
Commentaires SQL (`COMMENT ON TABLE`)	La base se documente elle-même

COMMENT ON TABLE ligne_commande IS 'Article commandé : une ligne par couple (commande, article)';
COMMENT ON COLUMN ligne_commande.prix_unitaire IS 'Prix payé au moment de la commande (différent du prix courant de l''article)';

Pièges fréquents

Piège	Conséquence	Remède
Modéliser les écrans plutôt que les données	Schéma qui évolue à chaque maquette	Partir des règles de gestion
Cardinalités inversées	Clés étrangères du mauvais côté	Relire la phrase de chaque cardinalité
Propriétés calculées stockées	Incohérences	Les calculer (requête, vue)
Entité « fourre-tout » (`DIVERS`, `AUTRE`)	Requêtes impossibles	Modéliser les vrais concepts
Clé naturelle instable (e-mail, nom)	Clés étrangères à réécrire	Clé technique + contrainte `UNIQUE`
Listes dans une colonne	1FN violée	Table liée
`NULL` partout	Cardinalités `(0,1)` mal pensées, héritage en table unique	Séparer les tables
Pas de contraintes dans la base (« l’application vérifie »)	Données corrompues dès qu’un autre programme écrit	`NOT NULL`, `UNIQUE`, `CHECK`, clés étrangères
Trop d’héritage	Schéma compliqué	Une table avec un type, ou composition
Sur-modélisation	Modèle illisible	Modéliser ce qui est demandé, faire évoluer ensuite
Un seul modèle « pour tout »	Entités sans lien	Un MCD par domaine

Liste de contrôle d’un MCD

Chaque entité a un identifiant et un nom au singulier.
Chaque association a un nom verbal et ses cardinalités justifiées.
Pas de propriété calculable ni multi-valuée.
Les propriétés dépendent de l’identifiant complet de leur entité (ou du couple, pour une association).
Les règles de gestion sont écrites et le MCD les traduit toutes.
Un utilisateur du domaine a relu le schéma.

Liste de contrôle d’un MPD

Types précis et cohérents entre clés étrangères et clés référencées.
NOT NULL sur les colonnes obligatoires ; UNIQUE sur les identifiants naturels.
Clés étrangères avec une action ON DELETE choisie.
CHECK pour les règles simples (valeurs positives, statuts).
Index sur les clés étrangères et colonnes de filtre fréquentes.
Jeux de données de test et échecs attendus vérifiés.
Migrations numérotées et versionnées ; sauvegarde avant migration.

Entraînement

Modéliser, avec le même raisonnement :

Sujet	Entités probables	Difficulté à repérer
Bibliothèque	ADHERENT, LIVRE, EXEMPLAIRE, EMPRUNT	Livre ou exemplaire ? Historique des emprunts
Réservation de salles	SALLE, UTILISATEUR, RESERVATION	Plages horaires, chevauchement
Formation	ETUDIANT, COURS, ENSEIGNANT, INSCRIPTION	Association ternaire ?
Forum	UTILISATEUR, SUJET, MESSAGE	Association réflexive (réponses)
Blog	AUTEUR, ARTICLE, ETIQUETTE, COMMENTAIRE	Étiquettes (N,N), commentaires imbriqués

Pour chacun : règles de gestion → MCD → MLD → MPD → jeu d’essai avec échecs attendus.

Dépannage

Symptôme	Piste
Les utilisateurs ne reconnaissent pas leur métier dans le schéma	Reformuler avec leur vocabulaire, relire les règles de gestion
Le modèle ne tient plus après un changement de besoin	Reprendre au MCD et redériver, plutôt que bricoler les tables
Impossible de dessiner proprement le MCD	Texte d’abord (Mocodo), mise en page ensuite
Le schéma et la base divergent	Le script versionné est la référence ; plus aucune modification manuelle en production
`mocodo: command not found`	`pipx ensurepath`, ouvrir un nouveau terminal
Doute sur une cardinalité	La reformuler en phrase pour chaque extrémité, avec un exemple concret

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

Aucune. pipx (paquet Ubuntu) évite l’erreur externally-managed-environment de pip (voir Python : installation).

Pour aller plus loin

Mocodo, Merise (Wikipédia)
Retour : Introduction et démarche