Mermaid vs PlantUML : lequel survit au contact d'une présentation
Réponse courte : Mermaid gagne sur la portée et la rapidité — il s'affiche nativement dans GitHub, GitLab, Notion et Obsidian, et sa syntaxe est assez proche du Markdown pour qu'un collègue puisse modifier un diagramme sans apprendre un outil. PlantUML gagne sur la profondeur — un catalogue de diagrammes bien plus large, une conformité UML stricte et un contrôle de la mise en page qui tient la route sur des systèmes réellement volumineux. La plupart des comparatifs s'arrêtent là. Celui-ci pousse la question d'un cran : ni l'un ni l'autre n'anime, et c'est là que tous deux perdent face à une diapositive.
La version honnête du comparatif
PlantUML est un moteur Java qui produit des diagrammes depuis bien plus d'une décennie. Il a fait ses preuves, son catalogue de diagrammes est le plus large de toutes les notations textuelles couramment utilisées, et il gère les diagrammes de déploiement, les diagrammes de composants, les machines à états et l'UML strict là où Mermaid se contente d'approximations ou déclare forfait.
Mermaid, c'est du JavaScript, plus récent et bien plus restreint par choix. Le bénéfice de cette étroitesse, c'est qu'il s'affiche là où votre équipe écrit déjà. Un bloc `mermaid` dans un README GitHub devient un diagramme sans étape de build, sans serveur et sans plugin. Cette seule propriété a davantage fait pour l'adoption du diagramme as code que n'importe quelle fonctionnalité livrée par PlantUML.
La vraie question n'est donc pas de savoir lequel est le meilleur. C'est de savoir quel échec vous préférez : un diagramme que votre outillage ne sait pas exprimer, ou un diagramme que votre équipe ne maintiendra pas.
En quoi Mermaid et PlantUML diffèrent-ils concrètement ?
| | Mermaid | PlantUML | |---|---|---| | Moteur | JavaScript, rendu dans le navigateur | Java, généralement un serveur ou un jar local | | Rendu natif dans GitHub, Notion, Obsidian | Oui | Non, nécessite un plugin ou une image déjà rendue | | Courbe d'apprentissage de la syntaxe | Faible, proche du Markdown | Plus raide, davantage de directives | | Catalogue de diagrammes | Flowchart, séquence, classes, états, ER, Gantt, camembert, parcours, et une liste qui s'allonge | Plus large, avec déploiement, composants, objets, chronogrammes et UML strict | | Contrôle de la mise en page | Limité, le moteur décide pour l'essentiel | Étendu, avec arêtes invisibles et positionnement explicite | | Comportement sur les très grands diagrammes | Se dégrade, la mise en page devient imprévisible | Tient mieux | | Animation | Aucune | Aucune |
La dernière ligne est celle que personne ne met dans le tableau, et c'est elle qui détermine ce qui se passe quand le diagramme arrive sur une diapositive.
Quand faut-il choisir Mermaid ?
Choisissez Mermaid quand le diagramme vit à côté de ce qu'il décrit et sera modifié par quiconque modifie cette chose.
Des notes d'architecture dans un README, un diagramme de séquence dans une pull request, un flowchart dans un document de conception, une esquisse ER dans une page Notion. Dans tous ces cas, la valeur du diagramme est proportionnelle à son actualité, et l'actualité vient d'un faible coût d'édition. Le coût d'édition de Mermaid, c'est une modification de texte dans le fichier que vous avez déjà ouvert.
Choisissez Mermaid aussi quand le public de la source ne se limite pas à vous. Un product manager corrigera volontiers une étiquette dans un flowchart Mermaid. La même personne n'installera pas un runtime Java.
Quand faut-il choisir PlantUML ?
Choisissez PlantUML quand le diagramme est le livrable plutôt qu'une annotation.
De l'UML formel pour une remise en environnement réglementé, un diagramme de composants dans une notation imposée, une topologie de déploiement à cinquante nœuds où la mise en page automatique produirait des spaghettis, une machine à états avec des états composites imbriqués. PlantUML exprime tout cela ; Mermaid, le plus souvent, non, et le forcer donne un diagramme moins bon que le choix du bon outil.
Choisissez-le aussi quand vous avez besoin d'une mise en page déterministe. PlantUML vous donne des arêtes invisibles et des indications de positionnement qui vous permettent d'exiger qu'un diagramme ressemble à ce que vous aviez dessiné au tableau. Mermaid, lui, va réorganiser le tout, et sur un grand graphe ce n'est pas un désagrément mineur.
Que se passe-t-il quand l'un ou l'autre arrive dans une présentation ?
Voici l'échec que les deux notations partagent, et il apparaît dès l'instant où le diagramme quitte la documentation pour entrer dans un deck.
Les deux produisent une image statique complète. Chaque nœud, chaque arête, dessinés d'un coup. Dans un README, c'est le bon comportement — le lecteur parcourt, zoome et relit à son rythme. Dans une présentation, tout s'inverse : le public reçoit l'image entière dès la première seconde, puis passe votre explication à lire en avance, ou pire, à lire le mauvais coin.
En tant qu'orateur, vous le remarquez. Vous vous entendez dire « ignorez la partie droite pour l'instant », vous pointez du doigt un vidéoprojecteur, ou vous découpez un diagramme honnête sur quatre diapositives pour pouvoir le dévoiler par morceaux. Ce dernier contournement est le plus coûteux, car désormais un changement dans le système signifie modifier quatre diapositives qui ont déjà divergé de la source.
Ni Mermaid ni PlantUML n'a de réponse. Mermaid traîne depuis des années des demandes de fonctionnalité ouvertes pour les diagrammes animés. PlantUML n'en a jamais promis. Tous deux décrivent une structure, alors qu'une présentation a besoin d'une séquence.
Nous avons traité le versant format dans Mermaid vers PowerPoint, et le versant présentation dans comment présenter une architecture système.
La troisième option : garder le texte, ajouter la séquence
Vous n'avez pas à choisir entre le diagramme as code et un diagramme présentable.
Le convertisseur Mermaid de FluxDiagram lit les deux notations — définitions Mermaid de flowchart, séquence, classes, Gantt et camembert, ainsi que les blocs `@startuml` PlantUML — en extrait les nœuds et les arêtes, et génère une version animée qui se construit dans le sens de lecture que votre source déclare déjà. Exportez en GIF, MP4 ou WebM et intégrez le résultat dans PowerPoint, Google Slides ou Keynote.
La propriété qui compte : votre définition reste là où elle vit, dans le dépôt, sous revue, à côté du code. La diapositive reçoit un artefact généré plutôt qu'une capture d'écran qui commence aussitôt à se périmer. Quand le système change, vous changez le texte, comme vous le faites déjà, et vous régénérez.
Cela recadre la question Mermaid contre PlantUML. Les deux fonctionnent en entrée. Choisissez donc selon les critères ci-dessus — portée et coût d'édition contre catalogue et contrôle de la mise en page — plutôt que selon celui qui rendra le mieux dans le deck, parce qu'aucun des deux ne le fera, et qu'aucun n'en a besoin. Notre comparatif d'outils plus large se trouve dans FluxDiagram vs les alternatives.
FAQ
Puis-je utiliser Mermaid et PlantUML dans le même projet ?
Oui, et beaucoup d'équipes le font. Une répartition courante : Mermaid pour tout ce qui est rendu dans le README ou le wiki, PlantUML pour les documents de conception formels qui sont exportés de toute façon. Le coût, c'est deux syntaxes dans la tête de l'équipe : mettez-vous donc d'accord sur ce qui va où, et écrivez-le.
La syntaxe de PlantUML est-elle plus difficile que celle de Mermaid ?
Oui, de façon notable, même si l'écart n'est pas énorme pour les diagrammes simples. Un diagramme de séquence PlantUML basique et son équivalent Mermaid se ressemblent. L'écart se creuse avec les skins, les directives de mise en page, les inclusions et les constructions UML plus strictes — c'est précisément là que réside la puissance de PlantUML.
Lequel est le meilleur pour les diagrammes d'architecture en particulier ?
Pour une petite carte de services qui doit rester à jour, Mermaid, parce qu'il s'affiche dans le dépôt. Pour une grande topologie de déploiement ou tout ce qui exige la notation C4 ou l'UML strict, PlantUML, qui dispose de bibliothèques établies pour les deux. Aucun des deux ne se présentera bien sous forme d'image statique ; c'est un problème distinct du choix de la notation.
Essayez avec le diagramme que vous avez déjà
Quelle que soit la notation dans laquelle vous écrivez, le problème de présentation est le même.
Collez votre code Mermaid ou PlantUML dans le convertisseur.
FluxDiagram génère des diagrammes animés que vous intégrez dans le deck que vous avez déjà, dans PowerPoint, Google Slides ou Keynote.