UML-Merise : comprendre et modéliser

• Clarifier le besoin métier avant d'écrire la moindre ligne
• Détecter les incohérences et les trous fonctionnels tôt
• Aligner dev, PO et client sur un vocabulaire commun
• Anticiper la scalabilité de ta base et de tes services
• Documenter pour les futurs devs (et pour toi dans 6 mois)

Merise

• Origine francophone, utilisé dans l'enseignement et le secteur public en France
• Orienté base de données et système d'information
• Excelle sur le MCD / MLD / MPD (passage progressif du concept au technique)
• Cardinalités explicites : 1,1, 0,n, 1,n

UML

• Standard international, orienté code objet et applicatif
• 14 diagrammes possibles, on en utilise 4 à 5 en pratique
• Structure (classes, composants) et comportement (séquence, cas d'usage, activité)
• Multiplicités : 1, 0..1, 0..*, 1..*

Les briques de base

• Entité : un objet du métier (Client, Produit, Commande)
• Association : un lien entre entités (passer, contenir)
• Cardinalités : 0,1, 1,1, 0,n, 1,n (min et max)
• Propriétés (attributs) : portées par les entités, parfois par les associations
• Identifiant unique : chaque entité en a un (souvent un id technique)

Exemple : boutique en ligne (Mermaid)

erDiagram
    CLIENT ||--o{ COMMANDE : passe
    COMMANDE }o--|| PRODUIT : contient

    CLIENT {
        int id PK
        string nom
        string email
    }
    COMMANDE {
        int id PK
        date date_commande
        int client_id FK
    }
    PRODUIT {
        int id PK
        string libelle
        decimal prix
    }

Lecture : un CLIENT peut passer zéro ou plusieurs commandes (notation ||--o{). Chaque COMMANDE est passée par exactement un client.

Règles de passage

• Chaque entité devient une table
• Association 1,n : clé étrangère côté n
• Association n,n : table de jonction avec les deux clés étrangères
• Les attributs deviennent des colonnes typées
• Les identifiants deviennent des PRIMARY KEY

Le SQL correspondant

CREATE TABLE client (
  id     SERIAL PRIMARY KEY,
  nom    VARCHAR(100) NOT NULL,
  email  VARCHAR(150) UNIQUE NOT NULL
);

CREATE TABLE produit (
  id       SERIAL PRIMARY KEY,
  libelle  VARCHAR(150) NOT NULL,
  prix     NUMERIC(10,2) NOT NULL
);

CREATE TABLE commande (
  id              SERIAL PRIMARY KEY,
  date_commande   DATE NOT NULL,
  client_id       INT NOT NULL REFERENCES client(id)
);

-- Table de jonction pour l'association n,n
CREATE TABLE commande_produit (
  commande_id  INT NOT NULL REFERENCES commande(id),
  produit_id   INT NOT NULL REFERENCES produit(id),
  quantite     INT NOT NULL DEFAULT 1,
  PRIMARY KEY (commande_id, produit_id)
);

Anatomie d'une classe UML

• Nom de la classe en haut
• Attributs au milieu (avec visibilité : + public, - private, # protected)
• Méthodes en bas
• Italique = classe abstraite ou interface

Les liens

• Association simple : flèche pleine (les classes se connaissent)
• Agrégation : losange vide (lien faible, le tout peut exister sans la partie)
• Composition : losange plein (cycle de vie partagé, si le tout meurt la partie aussi)
• Héritage : flèche triangulaire vide
• Implémentation d'interface : flèche triangulaire en pointillés

Exemple Mermaid

classDiagram
    class Utilisateur {
        -int id
        -string email
        +seConnecter()
    }
    class Commande {
        -int id
        -Date date
        +calculerTotal() float
    }
    class Produit {
        -string nom
        -float prix
    }
    Utilisateur "1" --> "*" Commande : passe
    Commande "*" --> "*" Produit : contient

Cas d'utilisation

Vue très haute, côté utilisateur : qui peut faire quoi. Les acteurs (bonhommes) sont reliés à des bulles (les fonctionnalités). Utile en kick-off de projet pour partager le périmètre avec le métier.

Diagramme de séquence

Le plus utile au quotidien. Axe vertical = temps. Tu vois les échanges chronologiques entre objets ou services : appels API, événements, réponses.

sequenceDiagram
    participant U as Utilisateur
    participant F as Frontend
    participant A as API
    participant DB as Database

    U->>F: Clic "Valider commande"
    F->>A: POST /commandes
    A->>DB: INSERT INTO commande
    DB-->>A: id de la commande
    A-->>F: 201 Created { id }
    F-->>U: "Commande validée ✓"

Diagramme d'activité

Proche d'un organigramme : début, étapes, décisions (losanges), fin. Utile pour documenter un workflow complexe (parcours de validation, processus métier).

Les outils recommandés

• Mermaid : diagrammes en markdown, rendu natif dans GitHub/GitLab/Notion. Versionnable. Idéal pour la doc.
• draw.io / diagrams.net : éditeur visuel gratuit, export PNG/SVG, intégration VS Code via extension
• PlantUML : syntaxe texte puissante, plus complet que Mermaid sur les diagrammes UML avancés
• Excalidraw : pour les croquis rapides en brainstorm ou réunion

Bonnes pratiques

• Versionne les sources texte (Mermaid, PlantUML), pas les images PNG
• Range tes diagrammes dans docs/diagrams/ du repo
• Lie un diagramme à un cas d'usage ou un ADR, pas en vrac
• Mets à jour quand le code évolue (ou supprime, mieux qu'un schéma faux)