Éditeur de diagramme de séquence Mermaid
Un diagramme de séquence montre qui parle à qui et dans quel ordre. Il convient quand l'intéressant est l'échange de messages entre plusieurs parties — une authentification, un paiement, une intégration entre services. S'il n'y a qu'un acteur et que ce sont les bifurcations qui comptent, un organigramme dit la même chose avec moins de bruit.
Un paiement par carte avec authentification forte
L'intérêt de ce diagramme tient aux blocs `alt` : ils montrent que le 3-D Secure n'a pas toujours lieu et qu'il existe deux issues distinctes. Remarquez aussi que la passerelle dialogue avec la banque sans que le marchand en sache rien ; c'est exactement ce qu'un diagramme de séquence rend visible et qu'un organigramme dissimule.
sequenceDiagram
autonumber
participant C as Client
participant M as Marchand
participant P as Passerelle
participant B as Banque émettrice
C->>M: Valider la commande
M->>P: Demander l'autorisation
P->>B: Transmettre l'opération
B-->>P: Authentification requise
alt La banque exige le 3-D Secure
P-->>C: Rediriger vers la banque
C->>B: Saisir le code reçu
B-->>P: Authentification réussie
else La banque ne l'exige pas
B-->>P: Autorisée directement
end
P-->>M: Autorisation accordée
M-->>C: Commande confirmée
M->>M: Enregistrer la venteExemples commentés
1. Deux participants et un message
`->>` est une flèche à pointe pleine, pour un appel. `-->>` est pointillée, pour la réponse. Ce couple couvre la majorité des diagrammes.
sequenceDiagram
Client->>API: Créer la commande
API-->>Client: 201 Created2. Des alias pour les noms longs
`participant X as Nom long` donne un identifiant court à écrire et un nom lisible à lire. Déclarer les participants en tête fixe aussi leur ordre dans le dessin ; sans déclaration, c'est l'ordre d'apparition qui décide.
sequenceDiagram
participant N as Navigateur
participant A as API de commandes
participant S as Service de stock
N->>A: POST /commandes
A->>S: Réserver les articles
S-->>A: Réservation confirmée
A-->>N: 201 Created3. Activations et appels à soi-même
`activate` et `deactivate` dessinent la barre qui indique qu'un participant travaille. Les suffixes `+` et `-` sur la flèche font la même chose en écrivant moins. Une flèche d'un participant vers lui-même représente un traitement interne.
sequenceDiagram
participant A as API
participant D as Base de données
Client->>+A: GET /facture/42
A->>+D: SELECT facture
D-->>-A: Ligne trouvée
A->>A: Calculer la TVA
A-->>-Client: 200 OK4. Alternatives, options et boucles
`alt`/`else` sont des chemins exclusifs, `opt` un bloc qui peut ne pas avoir lieu et `loop` une répétition. Les trois se ferment par `end`, et l'oublier est l'erreur la plus courante de ce type de diagramme.
sequenceDiagram
participant C as Client
participant A as API
participant M as Service de messagerie
C->>A: Demander la création du compte
alt Adresse déjà enregistrée
A-->>C: 409 Conflict
else Adresse disponible
A-->>C: 201 Created
A->>M: Envoyer la vérification
loop Jusqu'à 3 tentatives
M->>M: Réessayer si l'envoi échoue
end
end
opt Le client accepte l'infolettre
A->>M: Inscrire à la liste
end5. Notes et traitements parallèles
`par` montre des branches qui se déroulent en même temps, ce qu'un organigramme suggère sans jamais l'affirmer. Les notes sont le bon endroit pour le détail qui ne tient pas dans une étiquette de message.
sequenceDiagram
participant A as API de commandes
participant F as Facturation
participant L as Logistique
Note over A: La commande est déjà payée
par Prévenir la facturation
A->>F: Émettre la facture
F-->>A: Facture 2026/0431
and Prévenir la logistique
A->>L: Préparer l'expédition
L-->>A: Bon de livraison créé
end
Note over F,L: Chacune suit son propre rythmeRéférence de syntaxe du diagramme de séquence
Les flèches sont ce qu'il faut retenir, et elles sont propres à ce type : le `-->` d'un organigramme signifie ici autre chose, et le `->>` d'ici est une erreur dans un diagramme de classes.
| Syntaxe | Signification |
|---|---|
| sequenceDiagram | Ouvre le diagramme. Sensible à la casse : `sequencediagram` ne marche pas. |
| participant A | Déclare un participant et fixe sa position. |
| participant A as Nom | Identifiant court avec un nom lisible. |
| actor A | Comme participant, mais dessine un personnage. |
| A->>B: texte | Message à pointe pleine — un appel. |
| A-->>B: texte | Trait pointillé — une réponse. |
| A-)B: texte | Pointe ouverte — un message asynchrone. |
| A->>A: texte | Un participant s'appelle lui-même. |
| activate A / deactivate A | Marque la période pendant laquelle A travaille. |
| A->>+B: / B-->>-A: | La même chose en abrégé, sur la flèche elle-même. |
| alt cond ... else ... end | Chemins exclusifs. |
| opt cond ... end | Bloc qui peut ne pas avoir lieu. |
| loop texte ... end | Répétition. |
| par ... and ... end | Branches simultanées. |
| Note over A,B: texte | Note sur un ou plusieurs participants. Aussi `Note left of` et `Note right of`. |
| autonumber | Numérote les messages automatiquement. |
Six erreurs qui cassent un diagramme de séquence
Reproduites avec Mermaid 11.12.2. La plus fréquente de loin est la première, et son message d'erreur est de ceux qui désignent le plus mal l'endroit du problème.
Ce que vous voyez
Parse error signalée à la dernière ligne du diagramme
Pourquoi
Un bloc ouvert et jamais fermé. `alt`, `opt`, `loop` et `par` réclament leur `end`. Mermaid signale l'échec au moment où il arrive au bout de l'entrée : le numéro de ligne désigne donc la fin du fichier et non le bloc resté ouvert. Avec deux blocs imbriqués, cela devient franchement difficile à voir.
Correction
Comptez les blocs ouverts et les `end` écrits. Si l'erreur désigne la dernière ligne, c'est presque toujours cela.
sequenceDiagram
Client->>API: Requête
alt Tout va bien
API-->>Client: 200 OKsequenceDiagram
Client->>API: Requête
alt Tout va bien
API-->>Client: 200 OK
endCe que vous voyez
No diagram type detected matching given configuration
Pourquoi
La casse du mot-clé est fausse. `sequenceDiagram` fonctionne ; `sequencediagram` et `SequenceDiagram` non. Mermaid est sensible à la casse sur tous ses mots-clés.
Correction
D majuscule, le reste en minuscules.
sequencediagram
Client->>API: BonjoursequenceDiagram
Client->>API: BonjourCe que vous voyez
Le diagramme se dessine, mais le message sort sans libellé
Pourquoi
Il manque le texte après le deux-points. Vérifié : Mermaid ne refuse rien — il dessine le message avec un libellé vide, et la flèche reste sans explication. Ce qui échoue vraiment, c'est d'omettre le deux-points : `Client->>API` seul donne `Expecting 'TXT', got 'NEWLINE'`. Le deux-points est donc obligatoire et le texte ne l'est pas, exactement l'inverse de ce qu'on supposerait.
Correction
Écrivez quelque chose après le deux-points, ne serait-ce qu'un mot. Une flèche sans libellé n'est presque jamais ce que vous vouliez.
sequenceDiagram
Client->>API:
API-->>Client: 200sequenceDiagram
Client->>API: Créer la commande
API-->>Client: 200Ce que vous voyez
Parse error après un `alt` à condition longue
Pourquoi
Un retour à la ligne dans la condition du bloc. La condition d'un `alt`, d'un `opt` ou d'un `loop` doit tenir sur une seule ligne ; en la coupant, la seconde moitié est interprétée comme un message et ne se place nulle part.
Correction
Gardez la condition sur une ligne. Si elle est trop longue, raccourcissez-la et mettez le détail dans une note.
sequenceDiagram
alt Le client dispose du solde
suffisant sur son compte
A-->>B: OK
endsequenceDiagram
alt Le client dispose du solde suffisant
A-->>B: OK
end
Note over A,B: Solde vérifié contre le plafond quotidienCe que vous voyez
Le diagramme se dessine, mais un participant que vous n'avez pas déclaré apparaît
Pourquoi
Une faute de frappe dans le nom d'un participant. Mermaid crée le participant la première fois qu'il le voit : `Passerelle` et `Passerele` sont donc deux colonnes distinctes, sans le moindre avertissement. En français, ce sont surtout les accents qui piègent : `Facturation` écrit une fois `Facturatiön`, ou `Émetteur` une fois sans accent, produisent une colonne de plus.
Correction
Déclarez les participants avec `participant` en tête. Cela n'empêche pas la faute, mais rend visibles les noms valides et fait sauter aux yeux la colonne en trop.
sequenceDiagram
Client->>Facturation: Émettre la facture
Facturatio-->>Client: Facture émisesequenceDiagram
participant C as Client
participant F as Facturation
C->>F: Émettre la facture
F-->>C: Facture émiseCe que vous voyez
Le diagramme se dessine, mais l'ordre des colonnes n'est pas celui voulu
Pourquoi
Vous n'avez pas déclaré les participants. Sans déclaration, l'ordre est fixé par la première apparition de chaque nom : un message ajouté en tête du diagramme peut donc redistribuer toutes les colonnes et croiser les flèches. Le diagramme reste juste, mais il se lit beaucoup moins bien.
Correction
Déclarez tous les participants en tête, dans l'ordre où vous voulez les voir.
sequenceDiagram
Banque-->>Passerelle: Autorisée
Client->>Marchand: Valider la commande
Marchand->>Passerelle: AutorisersequenceDiagram
participant Client
participant Marchand
participant Passerelle
participant Banque
Client->>Marchand: Valider la commande
Marchand->>Passerelle: Autoriser
Passerelle->>Banque: Transmettre l'opération
Banque-->>Passerelle: AutoriséeNotes sur le rendu
Mesuré sur le Mermaid 11.12.2 qu'utilise ce site. Le diagramme de séquence se comporte différemment des autres sur deux points précis.
La largeur est dictée par les participants, pas par les messages
Mesuré : deux participants donnent un viewBox de 450 pixels de large, six en donnent 1250, soit environ 200 pixels par colonne ajoutée, quel que soit le texte des messages. Les messages n'ajoutent que de la hauteur, environ 46 pixels chacun. Avec une nuance utile : si l'étiquette d'un message dépasse la largeur minimale de colonne, elle élargit bien le diagramme — le même couple de participants est passé de 450 à 603 pixels rien qu'en allongeant un message. En français, où les étiquettes sont longues par nature, cela se produit plus tôt qu'en anglais.
C'est le seul type dont l'origine du viewBox est négative
Les diagrammes de séquence sortent avec un viewBox qui commence à `-50 -10` et non à `0 0`. Ce n'est pas un défaut : Mermaid réserve cette marge pour les boîtes des participants. Cela ne compte que si vous traitez le SVG avec vos propres outils, car tout calcul supposant une origine à zéro rognera la première colonne.
L'espace insécable avant les deux-points ne casse rien ici
Vérifié, et c'est une bonne nouvelle qui ne vaut que pour ce type de diagramme. Écrire `Client->>API : créer la commande` avec l'espace fine insécable qu'exige la typographie française se dessine correctement : l'espace est absorbée et le message reste intact. Attention toutefois à ne pas généraliser — dans un diagramme de Gantt, la même habitude typographique tronque silencieusement le nom d'une tâche, et dans un organigramme elle provoque une erreur d'analyse.
L'export PNG est exact, ici
Contrairement aux organigrammes, aux diagrammes de classes, d'états et ER, le diagramme de séquence dessine ses étiquettes en texte SVG simple et non dans un `<foreignObject>`. Il peut donc être rasterisé directement : le PNG exporté correspond à l'écran, sans redessin intermédiaire ni décalage typographique.
Le thème change les couleurs, jamais la géométrie
Le même diagramme en thème clair et en thème sombre donne un viewBox identique : les colonnes ne se déplacent pas et les blocs ne changent pas de taille quand on change de thème.
Quand un autre diagramme convient mieux
S'il n'y a qu'un seul participant, il n'y a pas de séquence à montrer. Un diagramme réduit à une colonne et à des flèches vers soi-même est un organigramme écrit de façon malcommode.
Si vous voulez décrire les états par lesquels passe une chose et non la conversation entre plusieurs, prenez un diagramme d'états. Le signe est net : si vous écrivez le même message plusieurs fois avec des conditions différentes, ce que vous avez sous les yeux est une machine à états.
Et si l'échange dépasse la douzaine de messages, découpez-le. Un diagramme de séquence de soixante messages est techniquement correct et humainement inutilisable ; il se lit presque toujours mieux en trois diagrammes, un par phase, reliés par une note.
Autres types de diagrammes
Écrit par Dominik Malsch · Dernière mise à jour: