C4 en code : Structurizr DSL, Mermaid C4 et C4-PlantUML

40 min
Quiz · 6 questions

Par Stéphane Robert mis à jour le 14 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Structurizr DSL permet de décrire une fois le modèle C4 de la boutique en texte, puis d'en tirer plusieurs vues (contexte, conteneurs, composants, dynamique, déploiement) que l'on valide, visualise et exporte. Cette leçon facultative s'adresse aux équipes qui ont lu la leçon sur le modèle C4 et Diagrammes as code. Il faut Docker pour Structurizr ; Mermaid C4 n'exige rien de plus que ce que Diagrammes as code a montré. Les commandes ont été jouées le 2026-10-13, sauf les exports png, static et websequencediagrams et les commandes inspect et list, signalés comme non rejoués. Le rendu C4-PlantUML a été rejoué le même jour dans la leçon PlantUML, et le serveur MCP de Structurizr, présenté en complément, l'a été le 2026-10-14.

Ce que vous allez apprendre

Décrire le modèle de la boutique en Structurizr DSL, un modèle pour plusieurs vues.
Valider le fichier avec la commande validate et le visualiser avec local.
Exporter les vues vers Mermaid, C4-PlantUML, JSON et SVG.
Mesurer ce qu'on peut attendre de Mermaid C4, un format expérimental.
Diagnostiquer les erreurs courantes des commandes et de Mermaid C4.

Pourquoi un modèle plutôt qu'un dessin par diagramme ?

Un modèle décrit les éléments et leurs relations une seule fois, et les diagrammes n'en sont que des vues : modifier un élément met à jour toutes les vues qui le montrent. La leçon sur le modèle C4 a posé la distinction de c4model.com entre outils de modélisation et outils de dessin (« boxes and lines »). Voici ce que cette distinction change quand on écrit les diagrammes en texte.

Le schéma ci-dessous oppose les deux démarches. À gauche, un seul fichier de modèle, workspace.dsl, alimente Structurizr, qui produit les vues par export, par affichage local ou via Kroki. À droite, chaque fichier d'un outil de diagramme recopie les mêmes boîtes.

Un modèle, plusieurs vues, contre un fichier par diagramme. Source · SVG

Pour la revue, l'écart se voit dans la pull request, la demande de fusion où l'équipe relit une modification avant de l'accepter. Renommer l'« API » en « Service commandes » devient une ligne modifiée dans le modèle, et toutes les vues suivent. Avec un dessin par diagramme, le relecteur doit retrouver chaque fichier concerné et vérifier qu'aucun n'a été oublié. Le modèle déplace la cohérence du relecteur vers l'outil.

Comment décrire la boutique en Structurizr DSL ?

Le Structurizr DSL (langage dédié, domain-specific language) est un texte qui décrit un workspace : un espace de travail contenant un model (les éléments et leurs relations) et des views (les vues, c'est-à-dire les diagrammes à produire). Voici le modèle complet de la boutique, celui qui a été validé, avec les mêmes noms que les autres leçons du module. Copiez-le dans un fichier workspace.dsl.

workspace "Boutique en ligne" "Modèle C4 de la boutique, fil rouge de la formation Documenter" {

    !identifiers hierarchical

    model {
        client = person "Client" "Parcourt le catalogue, passe commande et suit sa livraison"
        gestionnaire = person "Gestionnaire de boutique" "Met à jour le catalogue et les stocks, suit les commandes"

        boutique = softwareSystem "Boutique en ligne" "Vend le catalogue et encaisse les commandes" {
            web = container "Interface web" "Affiche le catalogue, le panier et le suivi de commande" "Application monopage JavaScript"
            api = container "API" "Porte la logique métier : catalogue, commandes, paiement" "Node.js" {
                controleur = component "Contrôleur HTTP" "Reçoit les requêtes de l'interface web et vérifie la session" "Express"
                catalogue = component "Service Catalogue" "Liste les produits et leurs stocks" "Module Node.js"
                commandes = component "Service Commandes" "Crée la commande, enchaîne paiement et confirmation" "Module Node.js"
                paiementClient = component "Client Paiement" "Dialogue avec le service de paiement" "Module Node.js"
                notifications = component "Notifications" "Compose et envoie les e-mails" "Module Node.js"
            }
            base = container "Base de données" "Garde le catalogue, les clients et les commandes" "PostgreSQL" {
                tags "Base de données"
            }
        }

        paiement = softwareSystem "Service de paiement" "Encaisse les cartes bancaires" {
            tags "Externe"
        }
        mail = softwareSystem "Service de mail" "Envoie les e-mails transactionnels" {
            tags "Externe"
        }

        client -> boutique.web "Consulte le catalogue et commande" "HTTPS"
        gestionnaire -> boutique.web "Gère le catalogue et les stocks" "HTTPS"
        boutique.web -> boutique.api.controleur "Appelle" "JSON/HTTPS"
        boutique.api.controleur -> boutique.api.catalogue "Transmet les demandes de catalogue"
        boutique.api.controleur -> boutique.api.commandes "Transmet les commandes"
        boutique.api.catalogue -> boutique.base "Lit" "SQL/TCP"
        boutique.api.commandes -> boutique.base "Lit et écrit" "SQL/TCP"
        boutique.api.commandes -> boutique.api.paiementClient "Demande le débit"
        boutique.api.commandes -> boutique.api.notifications "Demande la confirmation"
        boutique.api.paiementClient -> paiement "Débite la carte" "JSON/HTTPS"
        boutique.api.notifications -> mail "Envoie les e-mails de commande" "SMTP"

        production = deploymentEnvironment "Production" {
            deploymentNode "Poste du client" "" "Navigateur web" {
                containerInstance boutique.web
            }
            deploymentNode "Serveur applicatif" "" "Ubuntu 24.04" "" 2 {
                deploymentNode "Node.js 22" {
                    containerInstance boutique.api
                }
            }
            deploymentNode "Serveur de données" "" "Ubuntu 24.04" {
                deploymentNode "PostgreSQL 17" {
                    containerInstance boutique.base
                }
            }
        }
    }

    views {
        systemContext boutique "Contexte" "Diagramme de contexte de la boutique en ligne" {
            include *
            autoLayout lr
        }

        container boutique "Conteneurs" "Diagramme de conteneurs de la boutique en ligne" {
            include *
            autoLayout lr
        }

        component boutique.api "Composants" "Diagramme de composants de l'API" {
            include *
            autoLayout lr
        }

        dynamic boutique "PasserCommande" "Passer une commande" {
            client -> boutique.web "Valide le panier"
            boutique.web -> boutique.api "POST /commandes"
            boutique.api -> boutique.base "Enregistre la commande en attente"
            boutique.api -> paiement "Débite la carte"
            boutique.api -> mail "Envoie la confirmation"
            autoLayout lr
        }

        deployment boutique production "Deploiement" "Déploiement en production" {
            include *
            autoLayout lr
        }

        styles {
            element "Person" {
                shape person
            }
            element "Externe" {
                background #999999
            }
            element "Base de données" {
                shape cylinder
            }
        }
    }
}

Le fichier se lit de haut en bas en trois blocs. Le bloc model déclare d'abord les éléments : person pour les personnes, softwareSystem pour les systèmes, container et component imbriqués dans leur parent. Chaque élément prend un nom, une description et, pour un conteneur ou un composant, une technologie, les propriétés que la leçon sur le modèle C4 demande sur chaque boîte.

La ligne !identifiers hierarchical change la façon de nommer les éléments : un identifiant s'écrit avec le chemin de son parent, d'où boutique.web ou boutique.api.controleur. Les tags (étiquettes) marquent les externes et la base, pour que les styles les retrouvent. Une relation s'écrit source -> destination "description" "technologie" : le verbe et le protocole demandés par c4model.com tiennent sur une ligne.

Le bloc deploymentEnvironment décrit l'environnement « Production » avec des deploymentNode imbriqués, c'est-à-dire des machines ou des environnements d'exécution qui s'emboîtent. Une containerInstance y place un conteneur du modèle. Le chiffre 2 après la technologie indique deux instances du « Serveur applicatif ». Les guillemets vides "" sautent la description, sans décaler la technologie.

Le bloc views fixe les diagrammes. systemContext boutique "Contexte" produit le niveau 1, container le niveau 2, component boutique.api le niveau 3. include * y met tous les éléments pertinents, autoLayout lr laisse l'outil placer les boîtes de gauche à droite. La vue dynamic liste les étapes numérotées d'un scénario, et deployment projette le modèle sur l'environnement choisi. Le bloc styles donne la forme de personne, le cylindre de la base et le gris des systèmes externes.

Quelques règles de syntaxe évitent les erreurs de débutant. Une instruction par ligne, l'accolade ouvrante { sur la ligne de l'instruction et l'accolade fermante } seule sur la sienne. Les commentaires commencent par // (ou #). Les noms de personnes et de systèmes sont uniques. Les guillemets sont facultatifs pour un mot sans espace, et "" saute une propriété. Enfin, donnez toujours une clé à chaque vue ("Contexte", "Conteneurs") : sans clé, l'outil en génère une qui n'est pas stable d'une exécution à l'autre.

Comment valider et visualiser le modèle avec Structurizr ?

Pour valider et visualiser le modèle, on lance l'image Docker officielle structurizr/structurizr, qui embarque Java 21 : rien d'autre à installer. La version documentée ici est la 2026.09.19, désignée aussi par son digest : la fin @sha256:… est l'empreinte du contenu exact de l'image, qui reste la même quand l'étiquette de version est déplacée sur une autre image. La documentation classe Structurizr Lite et le CLI parmi les produits en fin de vie, et la commande local remplace Lite. Toutes les commandes sont gratuites, sauf server, qui demande une licence.

Chaque commande monte le dossier courant dans le conteneur avec -v "$PWD":/usr/local/structurizr : c'est un volume, un dossier de votre machine que le conteneur voit et où il peut écrire. Or l'image tourne avec l'utilisateur 65532, qui n'est pas le vôtre. Sur un volume appartenant à votre compte, export et local échouent avec une erreur d'écriture (les messages exacts figurent dans le dépannage). La parade, testée : ajouter --user "$(id -u):$(id -g)" aux docker run qui écrivent. Cette option transmet le numéro de votre compte et de votre groupe, pour que le conteneur écrive avec votre identité.

La commande validate vérifie le fichier sans rien produire. Une sortie vide et un code de retour 0 signifient que le modèle est valide. L'essai l'a jouée sans --user, forme donnée ci-dessous ; avec --user, le résultat n'a pas été mesuré.

docker run --rm \
  -v "$PWD":/usr/local/structurizr \
  structurizr/structurizr:2026.09.19@sha256:721136283c2f9cf1ba69037bc9de136c579d66fdcb2d771cb60546ec68def1a5 \
  validate -workspace workspace.dsl

Sur un fichier casse.dsl où la ligne 8 écrit api -> base "Lit et écrit" "SQL" sans que base ait été déclaré, la commande rend le code 1 et ce message, qui indique la ligne fautive :

ERROR com.structurizr.command.ValidateCommand -- The destination element "base" does not exist at line 8 of /usr/local/structurizr/casse.dsl: api -> base "Lit et écrit" "SQL"

Pour voir les diagrammes, lancez local. Cette commande sert le dossier courant sur le port 8080 du conteneur, celui du quickstart officiel. L'essai l'a publié sur le port 8089 de votre machine (-p 127.0.0.1:8089:8080) ; gardez 8080 s'il est libre, sinon adaptez le port et l'URL. Le conteneur se lance en tâche de fond (-d), et le port est publié sur 127.0.0.1 seulement : personne d'autre sur le réseau n'y accède.

docker run -d --name structurizr-lab --user "$(id -u):$(id -g)" \
  -p 127.0.0.1:8080:8080 -v "$PWD":/usr/local/structurizr \
  structurizr/structurizr:2026.09.19@sha256:721136283c2f9cf1ba69037bc9de136c579d66fdcb2d771cb60546ec68def1a5 \
  local

Le serveur est prêt en une douzaine de secondes. Ouvrez http://localhost:8080 (ou le port que vous avez choisi) : la page redirige vers /workspace/1, et les diagrammes se trouvent sous /workspace/1/diagrams. Le chemin sans le 1 (/workspace/diagrams) répond une erreur 400. On y voit d'abord la vue « System Context View: Boutique en ligne #Contexte » : le Client et le Gestionnaire, la Boutique en ligne au centre, le Service de paiement et le Service de mail en gris comme systèmes externes, et chaque relation étiquetée. Des vignettes donnent accès aux autres vues.

Trois points d'usage. L'accès est limité à localhost et sans authentification : c'est un poste de travail, pas un serveur partagé. Après une modification du DSL, rafraîchissez le navigateur. Enfin, local écrit un dossier .structurizr/ et un fichier workspace.json à côté du DSL : ignorez-les dans Git avec un fichier .gitignore. L'arrêt se fait avec docker rm -f structurizr-lab.

Comment exporter les vues : Mermaid, C4-PlantUML, JSON, SVG ?

La commande export transforme le modèle en fichiers d'un autre format, un fichier par vue. Elle prend -workspace et -format (obligatoires) et -output (le dossier de sortie, facultatif). Structurizr crée le dossier de sortie s'il manque, même imbriqué (rejoué avec la 2026.09.19) ; le mkdir ci-dessous le crée avec votre identité et rend l'intention visible. Pour Mermaid :

mkdir export-mermaid
docker run --rm --user "$(id -u):$(id -g)" \
  -v "$PWD":/usr/local/structurizr \
  structurizr/structurizr:2026.09.19@sha256:721136283c2f9cf1ba69037bc9de136c579d66fdcb2d771cb60546ec68def1a5 \
  export -workspace workspace.dsl -format mermaid -output export-mermaid

Le dossier contient cinq fichiers structurizr-<clé>.mmd : Contexte, Conteneurs, Composants, PasserCommande et Deploiement. Attention, le Mermaid exporté n'est pas un C4Container : c'est un graph LR, un flowchart ordinaire, dont voici les premières lignes pour la vue Conteneurs.

graph LR
  linkStyle default fill:#ffffff

  subgraph diagram ["Container View: Boutique en ligne"]
    style diagram fill:#ffffff,stroke:#ffffff

    1["<div style='font-weight: bold'>Client</div><div style='font-size: 70%; margin-top: 0px'>[Person]</div><div style='font-size: 80%; margin-top:10px'>Parcourt le catalogue, passe<br />commande et suit sa livraison</div>"]
    style 1 fill:#ffffff,stroke:#444444,color:#444444

Les nœuds sont numérotés, les libellés contiennent du HTML en ligne et la base reste un cylindre. Ce format passe par le rendu Mermaid ordinaire : Kroki l'a rendu en HTTP 200 avec un XML valide. Pour que les forges l'affichent, la configuration de Mermaid doit avoir "securityLevel": "loose", selon la documentation de Structurizr.

Les autres formats suivent la même commande, avec un autre -format et son propre dossier -output (par exemple -format plantuml/c4plantuml et -output export-c4plantuml).

Format	Résultat	État dans l'essai
`mermaid`	`structurizr-<clé>.mmd` par vue, en flowchart	Rejoué, 5 fichiers
`plantuml/c4plantuml`	`structurizr-<clé>.puml` par vue	Rejoué, 5 fichiers
`json`	un seul `workspace.json` (25 Ko)	Rejoué
`svg`	`<clé>.svg` et `<clé>-key.svg` (légende)	Rejoué avec l'image `-playwright`, 10 fichiers
`png`, `static`, `websequencediagrams`	selon la documentation	Non rejoué

Le SVG (image vectorielle, lisible dans un navigateur) demande l'image structurizr/structurizr:2026.09.19-playwright@sha256:c89b54231c42da90484e6bf4e398f36a40123cb4b12c9d5f09c27eef3dc9644c, qui embarque un navigateur : elle pèse 6,24 Go, et son téléchargement a pris environ 2 min 30. L'export, lui, dure environ 4 secondes (-format svg -output export-svg).

Après les exports Mermaid et C4-PlantUML et un passage par local, le dossier de travail ressemble à l'arbre ci-dessous : le DSL, un dossier par export, et le répertoire .structurizr/ avec workspace.json que local a ajoutés. Les exports json et svg ont leurs propres dossiers, que l'arbre n'affiche pas.

workspace.dsl
Répertoireexport-mermaid/
- structurizr-Contexte.mmd
- structurizr-Conteneurs.mmd
- structurizr-Composants.mmd
- structurizr-PasserCommande.mmd
- structurizr-Deploiement.mmd
Répertoireexport-c4plantuml/
- structurizr-Contexte.puml
- structurizr-Conteneurs.puml
- structurizr-Composants.puml
- structurizr-PasserCommande.puml
- structurizr-Deploiement.puml
Répertoire.structurizr/
- …
workspace.json

Un dernier chemin évite le fichier intermédiaire : un Kroki local sait rendre le DSL directement, en passant par PlantUML. L'en-tête Kroki-Diagram-Options-View-Key choisit la vue. Sans lui, Kroki rend la première vue du fichier, ici le Contexte. Les cinq vues ont rendu un SVG valide avec Kroki 0.30.0.

# Kroki local, ici sur le port 8000
curl -s -X POST http://localhost:8000/structurizr/svg \
  -H 'Content-Type: text/plain' \
  -H 'Kroki-Diagram-Options-View-Key: Conteneurs' \
  --data-binary @workspace.dsl -o conteneurs.svg

Pour installer Kroki, voir la section sur l'hébergement dans Diagrammes as code.

Peut-on valider le DSL depuis un assistant de code ?

Oui : Structurizr publie un serveur MCP qui donne à un assistant de code les commandes validate, inspect et export sans Docker sur votre poste. MCP (Model Context Protocol) est le protocole par lequel un assistant comme Claude Code appelle des outils externes. C'est un complément pratique pendant l'écriture du DSL, pas un remplaçant de l'image Docker : il ne sert ni les diagrammes (local) ni le SVG.

L'instance publique, https://mcp.structurizr.com/mcp, expose six outils d'après la documentation de Structurizr, ce que l'essai du 2026-10-14 a confirmé : validate, parse et inspect sur le DSL, puis export-mermaid, export-plantuml et export-c4plantuml pour une vue désignée par sa clé. Dans Claude Code, une commande l'ajoute, et claude mcp get vérifie la connexion (état Connected dans l'essai, avec Claude Code 2.1.208) :

claude mcp add --transport http structurizr https://mcp.structurizr.com/mcp
claude mcp get structurizr

Sur le workspace.dsl de la boutique, l'outil validate a répondu OK, et une destination inconnue a donné le même message que l'image Docker, avec la ligne fautive. Piège à connaître : ce message d'erreur de modèle revient comme une réponse normale de l'outil, sans le drapeau isError du protocole. C'est donc le texte de la réponse qui dit si le modèle est valide. export-mermaid renvoie le même flowchart graph LR que la commande export, et inspect liste des recommandations préfixées ERROR (relation sans technologie, système sans documentation) sur un modèle pourtant valide.

Une réserve avant de l'adopter : l'instance publique reçoit le texte complet de votre modèle, donc une architecture interne ou confidentielle ne s'y envoie pas. La documentation propose alors de faire tourner son propre serveur avec l'image Docker structurizr/mcp, que cette leçon n'a pas essayée. Retirez le serveur de votre configuration avec claude mcp remove structurizr -s local (portée local, celle que claude mcp add utilise par défaut).

Que valent Mermaid C4 et C4-PlantUML ?

Mermaid C4 et C4-PlantUML décrivent un diagramme par fichier, sans modèle partagé : on y écrit la vue elle-même, boîte par boîte. Ils conviennent quand on veut un seul schéma lisible dans une forge, sans installer Structurizr. Leur limite est celle de tout outil de dessin : la cohérence entre deux fichiers reste à votre charge.

Mermaid C4 est le diagramme C4 de Mermaid. La documentation le déclare sans détour : « This is an experimental diagram for now. The syntax and properties can change in future releases. » Il propose cinq types (C4Context, C4Container, C4Component, C4Dynamic, C4Deployment) et des mots-clés comme Person, System_Ext, Container, ContainerDb, Container_Boundary et Rel. Chaque signature place la technologie avant la description, par exemple Container(alias, label, ?techn, ?descr) et Rel(from, to, label, ?techn) (le point d'interrogation marque un paramètre facultatif). Les Lay_* de PlantUML ne sont pas pris en charge : la disposition suit l'ordre d'écriture.

Voici les conteneurs de la boutique, tels que l'essai les a rendus.

C4Container
    title Conteneurs de la boutique en ligne
    Person(client, "Client", "Parcourt le catalogue, passe commande")
    Person(gestionnaire, "Gestionnaire de boutique", "Gère le catalogue et les stocks")
    System_Ext(paiement, "Service de paiement", "Encaisse les cartes bancaires")
    System_Ext(mail, "Service de mail", "Envoie les e-mails transactionnels")
    Container_Boundary(boutique, "Boutique en ligne") {
        Container(web, "Interface web", "JavaScript, navigateur", "Affiche le catalogue, le panier et le suivi")
        Container(api, "API", "Node.js", "Porte la logique métier")
        ContainerDb(base, "Base de données", "PostgreSQL", "Garde catalogue, clients et commandes")
    }
    Rel(client, web, "Consulte le catalogue et commande", "HTTPS")
    Rel(gestionnaire, web, "Gère le catalogue et les stocks", "HTTPS")
    Rel(web, api, "Appelle", "JSON/HTTPS")
    Rel(api, base, "Lit et écrit", "SQL/TCP")
    Rel(api, paiement, "Débite la carte", "JSON/HTTPS")
    Rel(api, mail, "Envoie les e-mails de commande", "SMTP")

L'essai a mesuré deux comportements. Premier point, le rendu. Kroki répond HTTP 200, mais le SVG n'est pas un XML valide (unbound prefix sur xlink:href, l'icône des personnes) : placé dans une balise <img>, il s'affiche cassé. mermaid-cli 12.0.0 produit un SVG valide, avec la commande ci-dessous, où puppeteer.json contient {"args": ["--no-sandbox"]}. Diagrammes as code détaille ces deux outils de rendu.

npx -y -p @mermaid-js/mermaid-cli@12.0.0 mmdc -p puppeteer.json -i conteneurs.mmd -o conteneurs-mmdc.svg

Second point, les erreurs de syntaxe. Une faute franche, comme Relation( au lieu de Rel(, est signalée : Lexical error on line 15. Unrecognized text. côté Kroki (code HTTP 400) comme côté mermaid-cli (code 1). Mais une parenthèse fermante oubliée sur une ligne Rel( ne produit aucune erreur : Kroki répond 200, mermaid-cli sort avec le code 0, et la relation suivante disparaît du dessin. Comptez les flèches du rendu contre les Rel du texte.

C4-PlantUML est une bibliothèque de macros PlantUML pour le C4. C'est le format plantuml/c4plantuml de l'export Structurizr, et Kroki sait le rendre avec son moteur c4plantuml. Le rendu a été rejoué le 2026-10-13 dans la leçon PlantUML, avec PlantUML 1.2026.8 et la bibliothèque standard C4 2.13.0 : c'est là qu'il est montré, avec l'installation de PlantUML et ses pièges.

Quel outil choisir : Structurizr, Mermaid C4 ou C4-PlantUML ?

Choisissez Structurizr dès que plusieurs vues doivent rester cohérentes, et Mermaid C4 pour un seul schéma dans une forge. Le tableau compare les quatre options selon ce que vous voulez conserver.

Outil	Modèle partagé	Rendu	Réserve
Structurizr DSL	oui, plusieurs vues	image Docker, exports, Kroki	Docker requis
Mermaid C4	non, un fichier par vue	natif dans les forges qui rendent Mermaid, selon leur version	expérimental, erreur silencieuse
C4-PlantUML	non, un fichier par vue	PlantUML requis	Java ou conteneur, voir la leçon PlantUML
Mermaid flowchart ou D2	non	portable	pas de sémantique C4, la forme est à vous

Que faire quand ça échoue ?

Quand une commande échoue, le message d'erreur suffit presque toujours à trouver la cause. Les sept cas du tableau sont ceux rencontrés pendant l'essai de cette leçon, avec la correction essayée. Pour les erreurs de dessin (boîte sans technologie, flèche sans verbe), quel que soit l'outil, voir la section sur les erreurs fréquentes de la leçon sur les conteneurs.

Symptôme	Cause	Correction
`java.nio.file.AccessDeniedException: export-mermaid/structurizr-Contexte.mmd`	L'image tourne en utilisateur 65532	Ajouter `--user "$(id -u):$(id -g)"`
`Data directory /usr/local/structurizr is not writable`	Même cause, avec `local`	Ajouter `--user "$(id -u):$(id -g)"`
`The destination element "base" does not exist at line 8`	Identifiant jamais déclaré	Déclarer l'élément avant la relation
Les vues changent de clé d'une exécution à l'autre	Clé de vue absente dans le DSL	Donner une clé à chaque vue (`"Contexte"`)
`/workspace/diagrams` répond 400	Il manque le numéro de workspace	Utiliser `/workspace/1/diagrams`
SVG de Mermaid C4 cassé dans `<img>`	Rendu Kroki, XML non valide	Rendre avec mermaid-cli, ou injecter le SVG en ligne
Une relation Mermaid C4 disparaît sans erreur	Parenthèse fermante manquante sur la ligne `Rel(` précédente	Compter les flèches du rendu contre les `Rel`

À retenir

Un modèle décrit les éléments une fois et produit plusieurs vues ; c4model.com le recommande face aux outils de dessin.
Structurizr DSL déclare model et views, avec !identifiers hierarchical, des relations -> et une clé par vue.
L'image structurizr/structurizr:2026.09.19 s'utilise avec validate, local et export, et avec --user "$(id -u):$(id -g)" sur un volume personnel.
Une sortie vide de validate signifie un modèle valide ; une erreur nomme l'identifiant et la ligne.
export produit un fichier par vue ; le Mermaid exporté est un flowchart, pas un C4Container.
Mermaid C4 reste expérimental : Kroki rend un SVG invalide en XML, et une parenthèse oubliée fait disparaître une relation sans message.
C4-PlantUML est le format plantuml/c4plantuml ; son rendu se pratique dans la leçon PlantUML.
Le serveur MCP de Structurizr valide et exporte le DSL depuis un assistant de code ; son instance publique reçoit tout le modèle, donc jamais une architecture confidentielle.
Quel que soit l'outil, une boîte porte son type et sa technologie, une flèche un verbe et un protocole (voir la leçon sur les conteneurs).

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin