UML-Merise : comprendre et modéliser

Modéliser, c'est réfléchir avant de coder. C'est l'étape qui transforme une idée encore floue en un système clair et structuré : tu poses les objets de ton métier, les liens qui les unissent et les règles qui les gouvernent avant d'écrire la moindre ligne. Quand on débute, on a envie de foncer sur le clavier, et modéliser ressemble alors à du temps perdu. C'est l'inverse : chaque quart d'heure passé à schématiser t'économise des heures de débogage et de refactoring une fois que le projet a grossi.

Un modèle sert quatre objectifs très concrets. Comprendre le besoin d'abord : clarifier ce que le projet doit réellement faire, au lieu de découvrir en cours de route qu'on a codé dans la mauvaise direction. Organiser les idées ensuite : un schéma donne une vue d'ensemble et rend gérable une complexité qui, dans la tête, reste confuse. Éviter les erreurs surtout : corriger un oubli en phase de conception coûte une fraction de ce qu'il coûtera une fois en production, avec des données réelles et des utilisateur·ices en face. Communiquer enfin : un diagramme crée un langage commun entre les personnes qui développent, le client et le métier. Tout le monde regarde le même dessin et parle enfin de la même chose.

Une autre manière de le dire : modéliser, c'est visualiser le système dans sa globalité, expliquer clairement ta solution à quelqu'un d'autre, et corriger les incohérences très tôt, quand elles ne coûtent presque rien. Ce n'est ni une case administrative à cocher ni une perte de temps : c'est un investissement qui se rembourse dès la première semaine de développement.

Cet angle compte particulièrement si tu prépares un titre RNCP. Devant un jury, on ne te demande pas seulement que ton application fonctionne : on attend que tu justifies tes choix techniques, que tu structures tes données proprement et que tu démontres une démarche réfléchie. Savoir présenter un modèle et expliquer pourquoi tu as posé telle entité ou telle relation, c'est ce qui fait la différence entre « ça marche » et « je maîtrise ».

Un dernier repère, pour ne pas tomber dans l'excès inverse : modéliser ne veut pas dire tout dessiner dans le moindre détail pendant trois semaines avant de coder. Plus une erreur est détectée tard, plus elle coûte cher — un attribut oublié repéré sur un schéma se rajoute en dix secondes, alors que le même oubli découvert une fois la base créée et l'application codée, c'est une migration, du code à reprendre et des tests à réécrire. Tu modélises donc juste assez et en continu : un croquis rapide avant une feature, un modèle de données soigné avant une nouvelle table.

Prends un exemple concret. Sans modèle, tu codes une table utilisateur, puis une table commande, et trois semaines plus tard le client précise qu'une commande peut être réglée en plusieurs fois. Tu découvres qu'il te manque toute une notion de « paiement » que ton schéma n'avait jamais anticipée : il faut créer une table, migrer les données existantes, reprendre le code qui calculait les totaux et réécrire les tests. Avec un modèle posé en amont, cette règle serait apparue dès la première discussion, sous la forme d'une entité Paiement reliée à Commande. Le coût de l'oubli passe alors de plusieurs jours à quelques minutes de gomme.

La « règle du quart d'heure » se pratique en trois temps. D'abord tu listes les objets dont ton système doit se souvenir — ce seront tes futures entités ou classes. Ensuite tu traces les liens entre eux et, pour chaque lien, tu te poses la seule question qui compte : « combien au minimum, combien au maximum ? ». C'est là que naissent les cardinalités. Enfin tu confrontes ton croquis aux cas limites : et si un client n'a aucune commande ? et si un produit change de prix après avoir été commandé ? et si deux personnes réservent le même créneau ? Ces questions en apparence bêtes, posées avant de coder, sont exactement celles qui te sauteraient au visage en production.

Un modèle n'est pas qu'un outil de conception, c'est aussi de la documentation vivante. Quand une nouvelle personne rejoint le projet, un bon schéma de données lui fait gagner des jours de lecture de code. Et « la nouvelle personne », dans six mois, ce sera peut-être toi : tu auras oublié pourquoi telle table existe ou pourquoi telle relation est optionnelle. Un diagramme à jour répond à ces questions sans que tu aies à relire trois mille lignes. C'est aussi pour ça qu'on préfère un schéma un peu imparfait mais présent à un schéma parfait qui n'existe que dans la tête d'une seule personne.

Enfin, modéliser n'est pas réservé à un profil « architecte » lointain. En équipe, on modélise à plusieurs, au tableau, parce que la discussion autour du schéma fait émerger les désaccords sur le métier avant qu'ils ne deviennent des bugs coûteux. Seul·e, tu le fais en continu, à petite dose. L'important n'est jamais la beauté du diagramme : c'est la réflexion qu'il déclenche et les mauvaises surprises qu'il t'évite.

• 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)

UML (Langage de Modélisation Unifié) est un langage visuel standardisé et international, orienté objet. Il permet de représenter tous les aspects d'un logiciel, de sa conception à son déploiement, à travers une série de diagrammes normalisés. On le croise partout où l'on programme avec des objets : Java, C++, Python, des frameworks comme Spring Boot ou Angular, aussi bien côté front que back, et jusque dans les applications mobiles iOS et Android. La spécification prévoit quatorze types de diagrammes, mais en pratique quatre ou cinq suffisent : les uns décrivent la structure (classes, composants), les autres le comportement (cas d'utilisation, séquence, activité).

Merise, elle, est une méthode française d'analyse et de conception née dans les années 1970. Elle reste très présente en France, notamment dans l'administration, les entreprises traditionnelles et l'enseignement. Contrairement à UML qui couvre tout le système, Merise est centrée sur l'organisation des données et la conception de bases relationnelles. On la retrouve sur les systèmes d'information d'entreprise, les projets orientés SQL (PostgreSQL, MySQL), les applications de gestion et, très souvent, dans les dossiers professionnels RNCP où l'on attend un modèle conceptuel de données propre.

En pratique, la question n'est donc pas « UML ou Merise » mais « UML et Merise ». Quand tu conçois une base, le trio conceptuel de Merise (dont tu verras le détail dans les chapitres suivants) est redoutablement efficace pour poser des tables saines. Quand tu spécifies le comportement de ton application — un parcours utilisateur, un échange entre services, une hiérarchie de classes — les diagrammes UML sont plus adaptés. Les deux se complètent : à toi de piocher l'outil qui répond à la question que tu te poses à cet instant.

Une image aide à retenir la différence. Merise est un architecte de bâtiment spécialisé dans les fondations : il s'assure que la structure qui portera tes données est saine, cohérente et durable. UML est un storyboard de film : il raconte qui fait quoi, dans quel ordre, comment les objets discutent entre eux. Un même projet a besoin des deux — des fondations solides et un scénario clair. C'est pour ça qu'on ne les oppose pas.

Concrètement, comment choisir sur le terrain ? Pose-toi une question simple : « est-ce que je réfléchis à des données à stocker ou à du comportement à exécuter ? ». Si tu conçois une base — des tables, des relations, des clés — le trio conceptuel de Merise (que tu détailleras dans les chapitres suivants) est imbattable pour poser des tables propres du premier coup. Si tu spécifies un parcours utilisateur, un échange entre ton front et ton back, ou une hiérarchie de classes dans ton code, ce sont les diagrammes UML qui parlent. Beaucoup de projets réels commencent par un modèle de données Merise, puis basculent sur UML dès qu'il s'agit d'écrire le code applicatif.

Attention à deux pièges de débutant·e. Le premier : croire qu'il faut absolument choisir un camp et devenir « team UML » ou « team Merise ». Non — un·e bon·ne dev pioche dans les deux boîtes à outils selon le besoin. Le second : confondre la notation et la réflexion. Peu importe que tu écrives une cardinalité 0,n à la mode Merise ou une multiplicité 0..* à la mode UML : ce qui compte, c'est que tu aies compris la règle métier « zéro ou plusieurs » qu'elle exprime. Les symboles changent, l'intention reste la même.

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..*

Le MCD représente la vision métier de tes données, sans aucune considération technique. À ce stade, on parle le langage du client, pas celui de la machine : ni type de colonne, ni clé étrangère, ni moteur de base. On répond seulement à la question « de quoi ce système a-t-il besoin de se souvenir, et comment ces choses sont-elles reliées ? ». C'est justement parce qu'il reste indépendant de la techno qu'un MCD survit à un changement de base de données ou de framework.

Trois briques suffisent à le construire. Les entités sont les objets de ton métier : Client, Commande, Produit. Les associations sont les liens entre ces entités, nommés par un verbe : un client passe une commande, une commande contient des produits. Les propriétés (ou attributs) décrivent chaque entité : un client a un nom et un email. Enfin, chaque entité possède un identifiant unique qui distingue une occurrence d'une autre — le plus souvent un identifiant technique. Tu retrouves les détails et un exemple juste en dessous.

Le cœur du MCD, ce sont les cardinalités. Elles s'écrivent sous la forme (min, max) de chaque côté d'une association et répondent à deux questions : « au minimum, combien ? » et « au maximum, combien ? ». Une cardinalité 1,1 signifie « exactement un » ; 0,1 « au plus un, éventuellement aucun » ; 1,n « au moins un, potentiellement plusieurs » ; 0,n « aucun ou plusieurs ». Exemple : entre Client et Commande, un client peut passer zéro ou plusieurs commandes (0,n), mais une commande est passée par un et un seul client (1,1). Se tromper de cardinalité, c'est se tromper de règle métier — et donc, plus tard, de schéma de base.

Passons les cardinalités au ralenti, parce que c'est là que se jouent la plupart des erreurs de conception. Chaque association a deux cardinalités, une de chaque côté, et chacune se lit indépendamment. Reprends « un client passe des commandes ». Côté client, tu te demandes : « un client donné participe à combien de commandes, au minimum et au maximum ? » → au minimum zéro (un client qui vient de s'inscrire n'a rien commandé), au maximum plusieurs, donc 0,n. Côté commande, tu te demandes : « une commande donnée est liée à combien de clients ? » → exactement un, jamais zéro ni deux, donc 1,1. Le fait de raisonner « une occurrence à la fois » est le secret pour ne jamais te tromper.

Le minimum (le premier chiffre) est celui qu'on oublie le plus, et pourtant c'est lui qui porte les règles métier fines. Un 0 signifie « l'existence est optionnelle » : un client peut exister sans commande. Un 1 signifie « l'existence est obligatoire » : une commande ne peut pas exister sans client rattaché. Cette nuance, invisible pour un débutant, se traduira directement en base par une colonne qui accepte ou refuse la valeur NULL. Modéliser proprement le minimum, c'est déjà décider de la solidité de tes futures contraintes.

Deux mots enfin sur l'identifiant et les propriétés d'association. Chaque entité doit posséder un identifiant qui distingue une occurrence de toutes les autres : on utilise presque toujours un identifiant technique (un id auto-incrémenté) plutôt qu'une donnée métier comme l'email, qui peut changer. Et certaines propriétés n'appartiennent ni à une entité ni à l'autre, mais à la relation elle-même : la quantité d'un produit dans une commande n'a de sens que pour le couple (commande, produit). On la porte donc sur l'association, pas sur une entité — un détail qui deviendra une colonne de la table de jonction au moment du passage au relationnel.

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.

Merise fait passer du besoin métier à l'implémentation technique en trois niveaux successifs, sans rupture. Le MCD est le niveau conceptuel : les entités, les relations et les cardinalités, sans considération technique. Le MLD est le niveau logique : on transforme le MCD en tables relationnelles avec des clés primaires et des clés étrangères. Le MPD est le niveau physique : on écrit le code SQL réel, avec les types de colonnes, les contraintes, les valeurs par défaut et les index propres à ton SGBD. Chaque niveau ajoute une couche de détail sans remettre en cause le précédent.

Le passage du MCD au MLD suit quelques règles mécaniques qu'il faut connaître par cœur. Chaque entité devient une table, et ses propriétés deviennent des colonnes typées. Chaque identifiant devient une clé primaire (PRIMARY KEY). Pour une association un-à-plusieurs (1,n), on ajoute une clé étrangère du côté « plusieurs » : la table Commande reçoit une colonne client_id qui pointe vers Client. Pour une association plusieurs-à-plusieurs (n,n), aucune clé étrangère simple ne suffit : il faut créer une table de jonction qui porte les deux clés étrangères, et éventuellement des attributs propres à la relation (une quantité, une date). Le scénario ci-dessous te fait dérouler exactement ce cas.

La dernière brique, souvent négligée par les débutant·es, ce sont les clés étrangères déclarées avec REFERENCES. Ce n'est pas de la décoration : c'est la contrainte d'intégrité référentielle qui empêche de créer une commande pointant vers un client qui n'existe pas. Sans elle, ta base accepte silencieusement des données incohérentes que tu paieras un jour en production. C'est précisément cette contrainte qui fait la solidité — et l'intérêt — d'une base relationnelle par rapport à un simple tableur.

Prenons le temps de dérouler le passage en entier sur l'exemple de la boutique, parce que c'est un geste que tu répéteras sur chaque projet. Ton MCD contient trois entités (Client, Produit, Commande) et deux associations : « Client passe Commande » en 1,n et « Commande contient Produit » en n,n. Première étape, tu poses une table par entité. Deuxième étape, l'association 1,n ne crée pas de table : elle se traduit par une simple colonne client_id ajoutée dans commande, côté « plusieurs ». Troisième étape, l'association n,n ne peut pas tenir dans une colonne ; elle donne naissance à une quatrième table, commande_produit, qui contient les deux clés étrangères et la quantité. Tu passes ainsi de trois « boîtes » conceptuelles à quatre tables physiques, mécaniquement.

Un mot sur la clé primaire des tables de jonction, un point que les débutant·es traitent souvent à la légère. Sur commande_produit, la bonne clé primaire est le couple (commande_id, produit_id). Cette clé composite garantit qu'on ne peut pas enregistrer deux fois la même paire — une même commande ne référencera jamais deux fois le même produit, elle augmentera plutôt la quantité. Oublier cette clé, c'est ouvrir la porte aux doublons silencieux qui fausseront tous tes totaux plus tard.

Garde enfin en tête que le MPD ajoute une dernière couche que le MLD ignore : les choix propres à ton moteur. C'est au niveau physique que tu décides du type exact de chaque colonne (VARCHAR(150) plutôt que « texte »), des valeurs par défaut (NOW() pour une date de création), des index à créer sur les colonnes que tu filtreras souvent, et des règles de suppression en cascade. Le même MLD peut donner un MPD légèrement différent selon que tu vises PostgreSQL ou MySQL — d'où l'intérêt d'avoir gardé les niveaux séparés plutôt que d'écrire du SQL dès le début.

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)
);

Le diagramme de classes est le cœur de la modélisation orientée objet. Il représente la structure statique de ton application : quelles classes existent, ce qu'elles contiennent et comment elles se relient. Il ressemble beaucoup à un modèle de base de données, à une différence près et de taille : il ne modélise pas seulement des données à stocker, mais des objets de code qui portent aussi un comportement — leurs méthodes. Une classe Commande ne se contente pas de connaître sa date et son client : elle sait calculerTotal().

Chaque classe se dessine en trois compartiments empilés. En haut, le nom de la classe. Au milieu, les attributs, avec leur visibilité : + pour public (accessible partout), - pour private (interne à la classe), # pour protected (accessible aux classes filles). En bas, les méthodes, c'est-à-dire ce que la classe sait faire. Une classe écrite en italique désigne une classe abstraite ou une interface, qu'on ne peut pas instancier directement.

Ce qui donne toute sa richesse au diagramme, ce sont les relations entre classes, et il faut les distinguer. Une association simple relie deux classes qui se connaissent (un User passe des Order). L'héritage exprime un « est un » : un Admin est un User. La composition traduit une vie partagée : une Order contient des OrderItem qui n'existent pas sans elle — si la commande disparaît, ses lignes aussi. L'agrégation est un lien plus lâche : un Panier référence des Produit qui, eux, continuent d'exister indépendamment du panier. Choisir la bonne relation, c'est déjà documenter une règle métier importante.

La question qui revient tout le temps : « quelle différence entre un diagramme de classes et mon modèle de données Merise, puisque les deux ont l'air de dessiner des boîtes reliées ? ». La réponse tient en un mot : le comportement. Un MCD décrit des données à ranger ; une classe décrit un objet qui agit. Ta table utilisateur stocke un email et un mot de passe. Ta classe Utilisateur, elle, stocke ces mêmes attributs mais sait aussi seConnecter(), changerMotDePasse() ou estAdministrateur(). Le diagramme de classes vit du côté du code, pas du côté du stockage.

Le piège classique est de confondre composition et agrégation, alors que la distinction est simple si tu te poses la question de la vie et de la mort. Composition : « si je détruis le tout, la partie a-t-elle encore un sens ? ». Une ligne de commande (OrderItem) n'a aucun sens sans sa commande : si la commande disparaît, ses lignes aussi → composition, losange plein. Agrégation : « la partie survit-elle au tout ? ». Un produit reste un produit même si on vide le panier qui le contenait → agrégation, losange vide. Choisir l'un ou l'autre, c'est décider si la suppression doit se propager en cascade dans ta base.

Quant à l'héritage, il traduit un « est un » et rien d'autre. Admin hérite de User parce qu'un administrateur est un utilisateur avec des pouvoirs en plus. Attention à ne pas en abuser : les débutant·es voient de l'héritage partout, alors qu'une simple association ou un attribut « rôle » suffit souvent. Une bonne règle : n'utilise l'héritage que si les classes filles ajoutent réellement des attributs ou des méthodes propres, pas seulement pour ranger des concepts qui se ressemblent. Un diagramme de classes lisible, c'est d'abord un diagramme qui ne cherche pas à tout modéliser.

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

Là où le diagramme de classes fige une structure, ces trois diagrammes décrivent ce qui se passe. Ils répondent chacun à une question différente : qui fait quoi (cas d'utilisation), dans quel ordre (séquence), et selon quel cheminement (activité). Tu n'as pas besoin des trois à chaque fois — tu choisis celui qui éclaire la zone d'ombre du moment.

Le diagramme de cas d'utilisation se place tout en haut, du point de vue utilisateur. Des acteurs (les bonhommes : Client, Administrateur, API externe) sont reliés à des bulles représentant les fonctionnalités (Se connecter, Commander, Suivre la livraison). Son intérêt : définir et partager le périmètre du projet en début de mission, sans entrer dans la technique. C'est un excellent support de discussion avec le métier ou le client, parce que tout le monde le lit sans formation.

Le diagramme de séquence est le plus utile au quotidien de développeur·euse. Son axe vertical, c'est le temps : chaque ligne verticale représente un objet ou un service, et les flèches horizontales sont les messages échangés, dans l'ordre. On le lit de haut en bas. Il rend limpide un enchaînement d'appels — clic utilisateur, requête HTTP, traitement serveur, écriture en base, réponse — et devient vite indispensable pour spécifier une API, un processus de connexion, une transaction de paiement ou tout workflow qui demande une synchronisation précise.

Le diagramme d'activité, enfin, ressemble à un organigramme : un début, des étapes, des décisions (les losanges) et une fin. Il documente un processus métier ou un parcours de validation là où l'ordre des étapes et les branchements comptent plus que les acteurs. Règle commune aux trois : garde-les simples. Un diagramme par scénario clé suffit, et s'il ne tient pas sur un écran, c'est qu'il faut le découper.

Pour bien choisir entre ces trois diagrammes, garde en tête à qui tu parles. Le cas d'utilisation s'adresse au métier et au client : il tient sur une page, ne contient aucun terme technique, et sert à se mettre d'accord sur le périmètre (« est-ce que l'administrateur peut supprimer un compte ? oui / non »). C'est souvent le premier diagramme d'un projet, celui qu'on dessine en réunion de cadrage. Si tu prépares un dossier RNCP, c'est aussi lui qui montre au jury que tu as compris le besoin avant de coder.

Le diagramme de séquence, lui, s'adresse aux dev — c'est ton meilleur allié pour concevoir une API. Prends l'exemple d'une connexion : l'utilisateur saisit ses identifiants, le front envoie une requête, le back vérifie le mot de passe haché, consulte la base, génère un jeton et renvoie une réponse. Mis à plat sur un axe vertical du temps, cet enchaînement révèle immédiatement les étapes qu'on aurait oubliées : « et si le mot de passe est faux, qu'est-ce qu'on renvoie ? », « à quel moment on crée la session ? ». Dessiner la séquence avant de coder l'API, c'est écrire sa spécification sans une ligne de code.

Le diagramme d'activité, enfin, brille quand le cœur du sujet n'est ni les acteurs ni la chronologie technique, mais un enchaînement de décisions. Un processus de validation de congés, un tunnel de commande avec ses branchements « panier vide / paiement refusé / stock épuisé », un workflow de modération : autant de cas où les losanges de décision racontent l'essentiel. Une erreur fréquente est de vouloir tout mettre dans un seul diagramme géant. Résiste : un diagramme par scénario, quitte à en faire plusieurs, reste toujours plus utile qu'une fresque illisible que personne n'ouvrira.

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).

Le meilleur outil de modélisation, c'est celui que tu ouvriras vraiment. Inutile d'investir dans une suite payante pour débuter : quelques options gratuites couvrent l'immense majorité des besoins, et le vrai critère de choix est le contexte. Pour de la documentation qui vit dans ton dépôt, privilégie une syntaxe texte. Pour un croquis jeté en réunion, un outil de dessin libre. Pour un diagramme UML avancé, un moteur plus complet.

La bonne pratique qui change tout : versionne les sources texte, pas les images. Un diagramme écrit en Mermaid ou PlantUML est un simple fichier texte — il se compare dans une pull request, se met à jour en une ligne et se régénère automatiquement. Une capture PNG, elle, ne se diffuse pas dans une revue de code et devient fausse dès que le code évolue. Range tes sources dans un dossier docs/diagrams/, lie chaque diagramme à un cas d'usage précis, et mets-le à jour quand le code change (ou supprime-le : mieux vaut pas de schéma qu'un schéma qui ment).

Pour finir, garde en tête la logique d'ensemble de ce cours. Sur une même application — par exemple un service de réservation de salles — tu poses d'abord un MCD Merise (Utilisateur, Réservation, Salle et leurs cardinalités), tu le traduis en tables avec leurs clés étrangères, puis tu décris côté code un diagramme de classes et, pour les parcours sensibles, un diagramme de séquence. Merise structure la donnée, UML éclaire le comportement. C'est exactement ce qu'un jury RNCP attend : une démarche réfléchie, justifiée, où l'on ne code jamais au hasard — on réfléchit d'abord, on modélise ensuite, et on code en dernier.

Comment choisir concrètement ton outil ? Réponds à la question « où ce diagramme va-t-il vivre ? ». S'il doit accompagner ton code et rester à jour, choisis une syntaxe texte : Mermaid pour la majorité des cas, PlantUML si tu as besoin de diagrammes UML plus poussés. S'il s'agit d'un croquis jeté pendant un atelier ou un entretien, un outil de dessin libre comme Excalidraw ou draw.io fait parfaitement l'affaire — l'objectif est de réfléchir vite, pas de produire un livrable. La règle d'or : ne passe jamais plus de temps à mettre en forme un diagramme qu'à réfléchir à ce qu'il représente.

La bonne pratique qui distingue un travail amateur d'un travail pro tient en une phrase : versionne les sources, pas les images. Un diagramme Mermaid est un fichier texte de quelques lignes ; il se compare dans une pull request, se corrige en une ligne, se régénère automatiquement et s'affiche même directement dans le README sur GitHub. Une capture PNG, à l'inverse, ne se relit pas dans une revue de code, grossit ton dépôt et devient fausse dès que le code évolue. Range tes sources dans un dossier docs/diagrams/, relie chaque diagramme à un cas d'usage précis, et supprime sans état d'âme un schéma périmé : un diagramme qui ment est plus dangereux qu'un diagramme absent.

Pour refermer ce cours, remets les pièces dans l'ordre. Sur une même application — mettons un service de réservation de salles — tu poses d'abord un MCD (Utilisateur, Réservation, Salle et leurs cardinalités), tu le traduis en tables avec leurs clés étrangères, puis tu décris côté code un diagramme de classes, et pour les parcours sensibles un diagramme de séquence. Merise structure la donnée, UML éclaire le comportement. C'est exactement la démarche qu'un jury attend : réfléchie, justifiée, traçable. Retiens la formule qui résume tout le cours : on ne code jamais au hasard. On réfléchit d'abord, on modélise ensuite, et on code en dernier.

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)