Gratuit · Sans inscription · Compatible fichiers .mmd

Éditeur d'organigramme Mermaid

Un organigramme montre comment un processus avance : quelles étapes existent, où il bifurque et où les branches se rejoignent. Il convient quand l'ordre des décisions est le sujet — un déploiement, le trajet d'une requête, un circuit de validation. Si le sujet est plutôt qui parle à qui et quand, prenez un diagramme de séquence.

Ouvrir dans l'éditeur →Lire le guide

Un pipeline de déploiement avec deux chemins d'échec

La plupart des organigrammes de ce site partent de cette forme : un chemin nominal rectiligne d'où se détachent des losanges de décision. Regardez les guillemets de l'avant-dernier nœud. Les parenthèses dans une étiquette doivent être mises entre guillemets, et l'oubli est l'erreur la plus fréquente de toutes.

flowchart TD
    Push[Push sur main] --> Lint[Analyse statique et types]
    Lint --> Test{Les tests passent-ils ?}
    Test -->|Non| Alerte[Prévenir l'auteur du commit]
    Test -->|Oui| Build[Construire l'image]
    Build --> Scan{Scan sans vulnérabilité ?}
    Scan -->|Non| Blocage["Bloquer la livraison (revue manuelle)"]
    Scan -->|Oui| Deploy[Déployer en production]
    Deploy --> Fumee[Tests de fumée]
    Fumee --> Fin[Livraison terminée]

Ouvrir dans l'éditeur

Exemples commentés

1. L'organigramme minimal

Deux nœuds et une flèche. `TD` va de haut en bas, `LR` de gauche à droite ; un diagramme plus large que haut se lit presque toujours mieux en `LR`.

flowchart TD
    Recevoir[Recevoir la requête] --> Repondre[Envoyer la réponse]

Ouvrir dans l'éditeur

2. Une bifurcation avec étiquettes

Les accolades dessinent un losange. Ce qui est encadré par des barres verticales étiquette l'arête, pas le nœud. Cette distinction ressert plus bas, dans la section des erreurs.

flowchart TD
    Debut[Recevoir la requête] --> Auth{Le jeton est-il valide ?}
    Auth -->|Oui| Traiter[Exécuter le gestionnaire]
    Auth -->|Non| Refuser[Renvoyer 401]
    Traiter --> Ok[Renvoyer 200]

Ouvrir dans l'éditeur

3. Donner du sens aux formes

Les formes sont la façon la moins coûteuse d'ajouter de l'information à un organigramme. Les extrémités arrondies marquent le début et la fin, le losange une décision, le cylindre un stockage de données.

flowchart LR
    Debut([Lancer le traitement]) --> Lire[(Lire depuis Postgres)]
    Lire --> Reste{Reste-t-il des lignes ?}
    Reste -->|Non| Fin([Terminer sans rien faire])
    Reste -->|Oui| Transformer[/Transformer les données/]
    Transformer --> Ecrire[(Écrire vers S3)]
    Ecrire --> Fin

Ouvrir dans l'éditeur

4. Des sous-graphes pour regrouper par responsable

Un sous-graphe encadre des nœuds liés. Là où il rend le plus, c'est en regroupant non par étape mais par responsable : dès qu'on voit quelle équipe ou quel service possède quoi, les points de passage apparaissent.

flowchart TD
    subgraph client [Navigateur]
        UI[Soumettre le formulaire]
    end
    subgraph api [Service de commandes]
        Valider[Valider la saisie]
        Enregistrer[Enregistrer la commande]
    end
    subgraph async [Traitements en arrière-plan]
        Courriel[Envoyer la confirmation]
        Facture[Générer la facture]
    end
    UI --> Valider
    Valider --> Enregistrer
    Enregistrer --> Courriel
    Enregistrer --> Facture

Ouvrir dans l'éditeur

5. Une boucle de reprise plafonnée

Les organigrammes gèrent bien les cycles. Une boucle de reprise est l'endroit où ils se montrent utiles, parce que le dessin laisse voir d'un coup d'œil si la boucle a vraiment une sortie.

flowchart TD
    Envoyer[Envoyer le webhook] --> Reponse{Réponse 2xx ?}
    Reponse -->|Oui| Ok[Marquer comme livré]
    Reponse -->|Non| Essais{Moins de 5 tentatives ?}
    Essais -->|Oui| Attente[Attente exponentielle]
    Attente --> Envoyer
    Essais -->|Non| File[Vers la file des échecs]

Ouvrir dans l'éditeur

Référence de syntaxe de l'organigramme

Tout ce qui suit est propre à l'organigramme. Les flèches surtout : elles ne se transposent pas aux autres types. Le `->>` d'un diagramme de séquence est ici une erreur de syntaxe.

Syntaxe	Signification
flowchart TD	De haut en bas. `TB` est identique. Le sens habituel de lecture d'un processus.
flowchart LR	De gauche à droite. `RL` existe aussi. Pour les flux larges et peu profonds.
A[Texte]	Rectangle — une étape ordinaire.
A(Texte)	Rectangle à coins arrondis.
A([Texte])	Forme de stade — par convention, un début ou une fin.
A[(Texte)]	Cylindre — un stockage de données.
A{Texte}	Losange — une décision.
A[/Texte/]	Parallélogramme — une entrée ou une sortie.
A --> B	Flèche.
A --- B	Trait sans pointe.
A -.-> B	Flèche pointillée — par convention, asynchrone ou facultatif.
A ==> B	Flèche épaisse — par convention, le chemin principal.
A -->\|texte\| B	Arête étiquetée. Avec des parenthèses, il faut des guillemets.
A["Texte (avec parenthèses)"]	Étiquette entre guillemets — nécessaire pour les parenthèses, les guillemets et tout caractère qui est de la syntaxe de forme.
subgraph nom [Titre] ... end	Regroupe des nœuds dans un cadre. Se ferme par `end`.
%% commentaire	Ligne de commentaire. Non dessinée.

Six erreurs qui cassent vraiment un organigramme

Toutes reproduites avec le moteur qu'utilise ce site (Mermaid 11.12.2). Collez la version cassée dans l'éditeur et vous obtiendrez exactement l'erreur décrite ; la version corrigée se dessine. Pour lire une erreur Mermaid, le raccourci est d'en regarder la fin : après `got` figure le jeton sur lequel l'analyseur a buté.

Ce que vous voyez

Parse error, se terminant par : got 'PS'

Pourquoi

Une parenthèse ouvrante dans une étiquette entre crochets. Les parenthèses sont de la syntaxe de forme — `A(texte)` est un nœud arrondi —, donc une parenthèse nue entre crochets est lue comme le début d'une forme.

Correction

Mettez toute l'étiquette entre guillemets droits. Entre guillemets, tout est traité comme du texte.

Cassé

flowchart TD
    A[Réessayer (5 fois maximum)] --> B[Terminé]

Corrigé

flowchart TD
    A["Réessayer (5 fois maximum)"] --> B[Terminé]

Ce que vous voyez

Parse error, se terminant par : got 'STR'

Pourquoi

Un guillemet droit au milieu de l'étiquette. L'analyseur y voit le début d'une chaîne, puis tombe sur le crochet fermant là où il attendait le guillemet de fermeture.

Correction

Encadrez toute l'étiquette de guillemets droits et utilisez des guillemets français à l'intérieur, ou écrivez le caractère `#quot;`.

Cassé

flowchart TD
    A[Le statut est "en attente"] --> B[Terminé]

Corrigé

flowchart TD
    A["Le statut est « en attente »"] --> B[Terminé]

Ce que vous voyez

Parse error, se terminant par : got 'NODE_STRING'

Pourquoi

Une espace dans l'identifiant d'un nœud. L'identifiant est le jeton qui précède la flèche, et l'espace le termine : il reste donc un mot orphelin que l'analyseur ne sait pas placer. Le cas proprement français est l'espace insécable, ordinaire (U+00A0) ou fine (U+202F), que la typographie réclame avant `: ; ! ?` et que les traitements de texte insèrent d'eux-mêmes. Vérifié : elle échoue exactement comme une espace ordinaire, avec le même jeton — le message ne laisse donc rien deviner du caractère invisible, et on relit la ligne sans comprendre ce qui cloche.

Correction

Un identifiant en un seul mot, sans espace d'aucune sorte, et le texte lisible dans l'étiquette. Les accents, la cédille et même l'apostrophe passent sans problème dans un identifiant : seule l'espace pose problème.

Cassé

flowchart TD
    service auth --> base de données

Corrigé

flowchart TD
    auth[Service d'authentification] --> db[(Base de données)]

Ce que vous voyez

Parse error, se terminant par : got 'end'

Pourquoi

Vous avez utilisé `end` comme identifiant de nœud. En minuscules, `end` ferme un sous-graphe : l'analyseur voit donc une fin de bloc là où il attendait un nœud. Cela arrive plus souvent qu'on ne croit, parce qu'en suivant des exemples anglais on finit par appeler `end` le dernier nœud même quand le reste du diagramme est en français.

Correction

Mettez une majuscule, ou donnez un autre identifiant au nœud et mettez le mot dans l'étiquette. `Fin` ne pose aucun problème.

Cassé

flowchart TD
    Debut[Démarrer] --> end

Corrigé

flowchart TD
    Debut[Démarrer] --> Fin[Terminé]

Ce que vous voyez

Parse error sur une étiquette d'arête entre barres

Pourquoi

Des parenthèses dans l'étiquette de l'arête. Ce qui est entre `|…|` subit la même contrainte qu'une étiquette de nœud : les parenthèses y sont de la syntaxe, pas du texte.

Correction

Mettez aussi l'étiquette d'arête entre guillemets.

Cassé

flowchart TD
    A -->|oui (toujours)| B

Corrigé

flowchart TD
    A -->|"oui (toujours)"| B

Ce que vous voyez

Lexical error on line 1. Unrecognized text.

Pourquoi

La direction n'est pas valide. Un organigramme n'accepte que TB, TD, BT, LR et RL ; tout le reste échoue à l'analyse lexicale, avant même la lecture d'un seul nœud. C'est pourquoi l'erreur désigne la ligne 1 et non l'endroit de la faute.

Correction

Utilisez l'une des cinq. TD et LR couvrent presque tout.

Cassé

flowchart HAUTBAS
    A --> B

Corrigé

flowchart TD
    A --> B

Notes sur le rendu

Rien de tout cela n'est recopié de la documentation : tout est mesuré sur le Mermaid 11.12.2 qu'utilise ce site. Ce sont les comportements qui comptent dès que le diagramme cesse d'être un jouet.

L'espace insécable est refusée ici et acceptée ailleurs

Mesuré, et la différence entre types de diagrammes vaut d'être connue. Dans un organigramme, une espace insécable — ordinaire (U+00A0) ou fine (U+202F) — dans un identifiant de nœud provoque une erreur d'analyse : vous êtes prévenu tout de suite, même si le message est identique à celui d'une espace ordinaire et ne mentionne rien d'invisible. Dans un diagramme d'états, la même insécable au même endroit ne provoque rien du tout : le diagramme se dessine et l'état se scinde silencieusement en deux. Comme la typographie française produit ces caractères sans qu'on les demande, c'est le piège le plus spécifiquement français de ce site.

Les étiquettes ne se coupent qu'aux espaces

Mesuré : une étiquette de nœud s'élargit jusqu'à un plafond de 276 pixels de viewBox, puis passe à la ligne et gagne en hauteur, environ 24 pixels par ligne. Le français étant plus long que l'anglais, un diagramme traduit gagne de la hauteur sans gagner un seul nœud. Le détail surprenant est que la coupure n'a lieu qu'aux espaces : un mot unique de 40 caractères ne se coupe jamais et étire le nœud jusqu'à 432 pixels, ce qui déforme tout le diagramme.

La hauteur augmente d'environ 105 pixels par nœud, la largeur ne bouge presque pas

Dans un organigramme de haut en bas, trois nœuds donnent un viewBox d'environ 126×278. Avec quarante, on passe à 135×4126 : la largeur a pris 9 pixels et la hauteur a été multipliée par quinze. Un long organigramme est une bande étroite qui ne tient sur aucun écran. C'est à cela que sert le bouton de recentrage de l'aperçu. Quand ça s'allonge trop, passer en `flowchart LR` divise souvent la proportion par deux.

Les étiquettes sont du HTML, et c'est pourquoi l'export PNG était cassé

Les étiquettes d'un organigramme sont dessinées comme du vrai HTML dans un `<foreignObject>` du SVG. C'est ce qui permet `<br>` et un peu de Markdown. C'est aussi pourquoi le navigateur refuse de peindre ce SVG sur un canvas : l'export PNG de ce site a longtemps renvoyé un fichier SVG sans rien dire. Il redessine désormais le diagramme avec des étiquettes en texte SVG avant d'exporter, et le PNG sort correct. En contrepartie, la typographie du PNG diffère très légèrement de celle de l'écran.

Le thème change les couleurs, jamais la géométrie

Le même organigramme rendu en thème clair et en thème sombre donne un viewBox rigoureusement identique. Changer de thème ne recompose rien et ne fait déborder aucune étiquette. Ce qui paraît étrange en sombre l'est tout autant en clair.

Quand un autre diagramme convient mieux

Si l'essentiel est qui envoie quoi à qui, et que la chronologie compte plus que les bifurcations, un diagramme de séquence se comprend mieux et continue de se comprendre quand il grossit. Un organigramme où six intervenants sont écrits comme des noms de nœuds est un diagramme de séquence qui s'ignore.

Si vous décrivez non pas une procédure mais les états par lesquels passe une chose, prenez un diagramme d'états. Le repère est simple : si les étiquettes des nœuds sont des états — « commande en attente », « commande expédiée » —, c'est une machine à états ; si ce sont des actions — « valider la saisie », « envoyer le courriel » —, c'est un organigramme.

Et au-delà d'une quarantaine de nœuds, honnêtement, aucun diagramme ne sauve la situation. Soit vous le découpez en plusieurs schémas partageant une même entrée, soit vous acceptez que ce que vous essayez d'expliquer est trop complexe pour une seule image. Cette conclusion-là est elle aussi une information utile.

Autres types de diagrammes

Écrit par Dominik Malsch · Dernière mise à jour: 8 septembre 2026

Ouvrir l'éditeur →