Comparaison
MapleSpire ou Structurizr : lequel tient à l’échelle d’une gouvernance d’entreprise?
Structurizr et MapleSpire reposent tous deux sur le modèle C4 et sur un vrai modèle, pas sur des dessins. Ils divergent sur une question décisive pour une grande organisation : où vivent les métadonnées partagées, et qui peut les tenir à jour.
Structurizr excelle quand l’architecture est du code, écrite et revue dans Git par des équipes techniques. MapleSpire vise le référentiel gouverné : des catalogues de tags et de technologies uniques pour toute l’organisation, éditables visuellement par tous ceux qui en ont le droit.
Deux philosophies de modélisation
Structurizr est un outil de « modèle en code » : l’architecture s’écrit dans un DSL textuel, se versionne dans Git et se publie vers un serveur qui génère les diagrammes. La documentation recommande un workspace par système logiciel, détenu par l’équipe qui le construit.
MapleSpire est un modèle visuel partagé : objets, relations et vues vivent dans une base de données, se modifient à plusieurs en temps réel et restent consultables hors ligne. Les catalogues de tags et de technologies sont des entités de l’organisation, et non du texte recopié dans chaque fichier.
Aucune des deux approches n’est meilleure dans l’absolu. La différence se voit surtout quand le nombre d’équipes, de systèmes et de contributeurs augmente.
Attribuer des métadonnées : tags, technologies, versions, groupes
| Métadonnée | Structurizr | MapleSpire |
|---|---|---|
| Tags | Texte libre par élément (tags "A,B"); styles liés au texte du tag | Tags et groupes de tags définis une fois pour l’organisation, référencés par identifiant |
| Renommer ou fusionner un tag | Rechercher-remplacer dans chaque workspace | Renommer, recolorer, fusionner ou archiver : appliqué partout, dans tous les paysages |
| Technologies | Texte libre (technology "Java") | Catalogue géré : alias, icônes claires et sombres, liens de documentation |
| Cycle de vie d’une technologie | Non modélisé | Active, dépréciée, retirée ou fusionnée; ajouts soumis à approbation |
| Version utilisée | À ajouter soi-même dans le texte ou dans properties | Version employée enregistrée sur chaque usage d’une technologie |
| Groupes et domaines | Groupes visuels déclarés dans le DSL | Groupes pouvant porter tags et technologies; domaines hiérarchiques |
| Propriétés personnalisées | properties et perspectives (clé-valeur libres) | Prévues dans le modèle, pas encore éditables dans l’interface |
Dans Structurizr, on décrit un élément avec les mots-clés tags, technology, properties et perspectives. Ce sont des chaînes libres, saisies élément par élément. Les archetypes fournissent des valeurs par défaut et les styles s’accrochent aux tags, mais il n’existe pas de registre central qui définit ce qu’est un tag ou une technologie valide.
Conséquence concrète : « PostgreSQL », « Postgres » et « postgresql 16 » peuvent coexister dans différents workspaces. Renommer un tag revient à faire un rechercher-remplacer dans tous les dépôts concernés, et rien n’empêche d’utiliser une technologie que l’organisation a retirée.
Dans MapleSpire, un objet ne stocke pas le texte d’un tag : il stocke une référence vers un tag défini une seule fois pour l’organisation. Les technologies proviennent d’un catalogue géré, avec des alias, des icônes et un cycle de vie.
Et les responsables?
La propriété d’un élément (quelle équipe en répond) est souvent la première métadonnée exigée par une gouvernance. Dans Structurizr, elle passe par une propriété libre, par exemple une clé owner, sans lien avec un annuaire d’équipes.
MapleSpire gère déjà les équipes pour le contrôle des accès, et son modèle prévoit d’associer des équipes propriétaires aux objets. Cette assignation n’est toutefois pas encore exposée dans l’interface : nous préférons le dire clairement plutôt que de la promettre.
Mettre à jour une seule fois, pour tout le monde
Pour une vue d’entreprise, Structurizr propose une démarche en trois temps : regrouper les systèmes dans un catalogue DSL partagé par URL, faire en sorte que chaque workspace d’équipe étende ce catalogue, puis générer un paysage d’ensemble. Ce paysage est produit par un administrateur qui récupère tous les workspaces, lance la génération et publie le résultat. C’est une copie : il faut la régénérer pour qu’elle reflète les changements suivants.
Dans MapleSpire, tags et technologies vivent dans la base de données de l’organisation. Une modification faite dans la console d’administration est visible immédiatement par tous les paysages, sans étape de publication. À l’intérieur d’un paysage, chaque objet existe une seule fois et chaque diagramme y fait référence.
Deux nuances, par souci d’exactitude. Dans MapleSpire, le modèle détaillé reste propre à chaque paysage; seuls les catalogues sont communs à toute l’organisation. Par ailleurs, chaque usage d’une technologie conserve la révision du catalogue avec laquelle il a été saisi, afin qu’une modification du catalogue ne réécrive pas l’historique en silence.
Contrôle des accès et revue des changements
Le cœur open source de Structurizr server n’a ni authentification ni contrôle d’accès par rôle : les workspaces y sont publics. Les rôles, SAML, LDAP et l’API d’administration font partie des binaires pré-construits sous licence. Sa grande force est ailleurs : comme le modèle est du code, chaque changement peut passer par une pull request, une revue et une validation automatisée en intégration continue.
MapleSpire inclut dans son code AGPL-3.0 des rôles d’organisation, des équipes dotées de droits de lecture ou d’écriture par paysage, l’authentification unique OIDC avec Google ou Microsoft et un journal d’audit des actions d’administration. Les évolutions se préparent dans des brouillons, avec une liste des changements et une fusion qui détecte les conflits.
Limite actuelle : les brouillons de MapleSpire n’ont pas encore d’étape formelle d’approbation avant fusion. Si votre gouvernance exige une revue obligatoire de chaque changement, le flux pull request de Structurizr reste aujourd’hui plus strict.
Lequel tient le mieux à l’échelle?
| Critère | Structurizr | MapleSpire |
|---|---|---|
| Cohérence du vocabulaire entre équipes | Dépend de la discipline et des revues | Imposée par des catalogues uniques |
| Contributeurs non développeurs | Doivent apprendre le DSL et Git | Édition visuelle, à plusieurs, en temps réel |
| Vue d’ensemble à jour | Paysage régénéré à la demande | Catalogues partagés en direct; modèle détaillé par paysage |
| Revue obligatoire des changements | Pull requests et CI | Brouillons et fusion, sans approbation formelle pour l’instant |
| Contrôle d’accès et SSO | Binaires sous licence | Inclus dans le code open source |
| Haute disponibilité | Selon le stockage et la licence choisis | Synchronisation sur une seule instance pour l’instant |
Si votre défi est de faire parler toute l’organisation le même langage (mêmes tags, mêmes technologies, mêmes versions) et d’y faire contribuer des architectes, des responsables produit et des équipes qui ne vivent pas dans Git, MapleSpire tient mieux l’échelle de la gouvernance.
Si votre architecture est déjà gérée comme du code, que vos contributeurs sont des développeurs et que la gouvernance passe par la revue de pull requests, Structurizr reste un excellent choix.
Migrer ou faire cohabiter les deux
MapleSpire importe un workspace Structurizr DSL et génère les diagrammes C4 correspondants. Il exporte aussi vers Structurizr DSL, Mermaid, JSON, CSV, SVG, PNG et Markdown. Vous pouvez donc essayer MapleSpire sur un workspace existant sans renoncer à vos fichiers.
Sources
Les affirmations sur Structurizr s’appuient sur sa documentation officielle, consultée le 12 octobre 2026. Les fonctions de MapleSpire décrites ici sont celles du code publié.