Structurizr Cloud ferme le 30 septembre : sortez votre modèle d'abord

Le service cloud de Structurizr est en fin de vie. Leur page de fin de vie liste "Structurizr cloud service (no replacement)" aux côtés de Lite, de la CLI et de l'installation on-premises, tous remplacés par le nouvel outillage consolidé. D'après leur annonce de fin de vie, les workspaces sont passés en lecture seule le 1er juillet 2026, les abonnements mensuels restants ont été arrêtés le même jour, et le service s'éteint le 30 septembre 2026. Cette annonce est derrière Patreon : vérifiez vous-même les dates avant de bâtir un plan autour.

La lecture seule n'est pas l'urgence. L'urgence, c'est ce que la lecture seule masque : les outils dont vous vous serviriez pour extraire votre workspace font partie du service qui ferme. L'onglet DSL de l'éditeur de workspace, le lien d'export sur votre tableau de bord, l'API web. Tout cela, c'est le service cloud. Le 1er octobre, il n'y a plus d'onglet sur lequel cliquer.

La première décision n'est donc pas de choisir l'outil vers lequel vous partez. C'est de mettre un fichier sur votre disque. Ça représente un copier-coller par workspace, et ça ne vous engage à rien. Choisir une destination n'est ni l'un ni l'autre.

Sortez votre modèle

Faites cette partie en premier, avant de lire quoi que ce soit en dessous.

Vos workspaces sont en lecture seule, pas invisibles. La FAQ du service cloud de Structurizr dit des workspaces en lecture seule : "You can still view the workspace content (via the UI and web API) but no changes can be made" — vous pouvez toujours consulter le contenu du workspace (via l'interface et l'API web) mais aucune modification n'est possible. Tout ce qui suit fonctionne aujourd'hui.

Si vous rédigiez en DSL et poussiez avec la CLI, c'est peut-être déjà fait. Votre workspace.dsl est dans Git. Ouvrez-le et vérifiez qu'il est à jour. La seule chose à surveiller : la mise en page que vous avez ajustée à la main dans l'éditeur de diagrammes du navigateur vit dans la copie cloud, pas dans votre DSL. Si ça compte pour vous, prenez aussi l'export JSON de l'étape 2.

Si vous rédigiez dans le navigateur, ou via la Workspace API, votre modèle n'existe que dans la base de données de Structurizr. Dans cet ordre :

Le DSL. Le conseil que Structurizr donne à ses utilisateurs existants est de convertir vers le DSL. Depuis leur page d'aide sur l'éditeur de workspace : "A DSL representation of your workspace (excluding documentation) can be found on the DSL tab" — une représentation DSL de votre workspace (documentation exclue) se trouve sur l'onglet DSL. L'éditeur de workspace lui-même a été abandonné en février 2022 mais reste accessible à une URL de la forme https://structurizr.com/workspace/XXXXX/workspace-editor, où XXXXX est l'identifiant de votre workspace. Ouvrez-le, cliquez sur l'onglet DSL, copiez tout, enregistrez le résultat sous workspace.dsl.

Notez la parenthèse dans leur phrase. La représentation DSL exclut la documentation. Si vous avez écrit de la documentation ou des ADR dans le workspace plutôt que de faire pointer !docs et !adrs vers des fichiers Markdown d'un repository, l'onglet DSL ne vous les rendra pas.
Le JSON. Les conseils de migration de Structurizr vous renvoient vers le lien "export your workspaces" en haut de la page. Il produit workspace.json. Prenez-le même si vous avez déjà le DSL. C'est le format que le playground de Structurizr et local acceptent tous les deux, et local cherche workspace.dsl puis workspace.json, dans cet ordre.
Tout ce que ces deux fichiers laissent de côté. La documentation écrite dans le workspace, les images que vous avez uploadées, les décisions avec leur historique de statut. Ouvrez le workspace dans l'interface et copiez en Markdown ce qui compte pour vous, tant que l'interface existe encore.
Committez les deux fichiers dans un repository. Pas un dossier sur un portable. Un repository, à côté du code qu'ils décrivent, là où la prochaine personne les trouvera.

Répétez pour chaque workspace. Si vous en avez douze, faites-les d'une traite plutôt que de vous promettre d'y revenir.

Une chose que je n'ai pas pu établir : Structurizr n'a publié nulle part, à ma connaissance, si les données des workspaces seront supprimées le 30 septembre ou simplement rendues inaccessibles. Ne partez pas du principe que vous pourrez les redemander en octobre. Ne partez pas non plus du principe inverse. Récupérez les fichiers.

Où le poser

Quatre options honnêtes. Elles conviennent à des équipes différentes, et trois d'entre elles ne sont pas archyl.

Option 1 : l'outillage de Structurizr lui-même

C'est la bonne réponse pour plus d'équipes qu'aucun blog d'éditeur ne vous le dira, et ça devrait être la première chose que vous chiffrez.

Structurizr ne disparaît pas. C'est le service cloud qui disparaît. Leur page EOL fait correspondre les anciens produits aux nouveaux : Lite est remplacé par local, la CLI par pull / push / export, et l'installation on-premises par server. Si vous êtes sur Lite ou sur la CLI aujourd'hui, vous avez vous aussi une migration devant vous, simplement beaucoup plus petite.

local est décrit ainsi dans leur documentation : "the free and open source local command provides a way to view diagrams and modify their layout" — la commande local, gratuite et open source, permet de visualiser les diagrammes et de modifier leur mise en page. Elle tourne sur votre machine, liée à localhost. Leur quickstart tient en deux commandes : docker pull structurizr/structurizr, puis docker run -it --rm -p 8080:8080 -v PATH:/usr/local/structurizr structurizr/structurizr local. Pointez-la vers un répertoire contenant votre workspace.dsl, ouvrez http://localhost:8080, éditez le fichier, rafraîchissez le navigateur.
Le playground est leur suggestion pour un usage occasionnel : uploadez workspace.dsl ou workspace.json, regardez les diagrammes, fermez l'onglet.
server est celui qui remplace ce que le service cloud faisait pour vous : publier des workspaces auprès d'un public plus large. Il a un cœur open source, gratuit si vous le compilez depuis les sources, avec stockage sur système de fichiers, recherche Lucene et aucune authentification. Les binaires précompilés ajoutent SAML, le contrôle d'accès par rôles, les tokens de partage privés, le stockage S3 et Azure Blob, Elasticsearch et une API d'administration, et nécessitent une licence : 300 £ par mois pour 1 à 20 utilisateurs uniques, 600 £ pour 21 à 50, 900 £ pour 51 à 100, facturés annuellement. Leur définition d'un utilisateur unique compte toute personne qui consulte un diagramme, y compris via une iframe ou une image embarquée, et pas seulement les éditeurs.

À qui ça convient : aux équipes dont le modèle est déjà du DSL dans Git, dont les lecteurs sont des ingénieurs, et dont l'usage principal du service cloud était le rendu. Vous gardez votre DSL exactement tel quel, vous gardez les vues de deployment et les vues dynamiques que notre propre importateur laisse tomber, et l'outillage est écrit par la personne qui a inventé le modèle C4. Si c'est votre cas, arrêtez votre lecture ici et allez lancer la commande Docker.

À qui ça ne convient pas : aux équipes qui ont besoin que cent non-ingénieurs consultent les diagrammes sans que vous ayez à opérer un serveur, et aux équipes pour qui 300 £ par mois pour vingt lecteurs se lit plus mal qu'un prix SaaS par éditeur. Et une dernière, qui est l'argument sur lequel repose tout le reste de ce billet : l'auto-hébergement préserve votre modèle, il ne le maintient pas. Le workspace qui s'est périmé dans le cloud se périmera aussi dans local. Personne ne relance le DSL quand le code change.

Option 2 : garder le DSL dans le repo et arrêter de payer un outil

L'option la plus sous-estimée, et la moins chère.

workspace.dsl dans Git, relu en pull request comme n'importe quoi d'autre, rendu à la demande quand quelqu'un a réellement besoin d'une image. local le rend dans un container. Le playground aussi. Si vous préférez quitter complètement la syntaxe de Structurizr, LikeC4 est sous licence MIT, s'écrit dans des fichiers .c4 de votre repository, et se publie via un plugin Vite, des composants React ou des web components : les diagrammes peuvent donc être embarqués dans un site de documentation que vous opérez déjà.

À qui ça convient : aux équipes dont le public des diagrammes se résume à une poignée d'ingénieurs capables de lire un DSL, et où la réponse honnête à « à quelle fréquence quelqu'un ouvre-t-il ça ? » est « à l'onboarding et pendant les incidents ». Vous ne perdez rien de ce que vous utilisiez et votre coût récurrent est nul.

À qui ça ne convient pas : à quiconque dont les diagrammes sont lus par des gens qui ne cloneront pas un repository. Ce qui, si vous payiez pour le service cloud, est peut-être exactement la raison pour laquelle vous payiez.

Option 3 : un autre outil C4 hébergé

Si le service cloud faisait un vrai travail pour vous, le remplacer par un autre outil hébergé est un choix raisonnable, et vous devriez en regarder plus d'un.

IcePanel est l'équivalent le plus proche : un outil C4 visuel avant tout, avec un service hébergé et un palier gratuit de cinq éditeurs, un nombre illimité de lecteurs et jusqu'à 100 objets de modèle, avec des plans payants à partir de 40 $ par éditeur et par mois, facturés annuellement. Leur propre comparaison avec Structurizr dit "model objects can be imported from Structurizr, Backstage, and a REST API" — les objets de modèle peuvent être importés depuis Structurizr, Backstage et une API REST. Je n'ai pas trouvé le format de fichier accepté documenté sur les pages auxquelles j'ai eu accès : avant de vous engager, uploadez le fichier exact que vous avez extrait à la section précédente et vérifiez ce qui survit. Ce conseil vaut pour tous les outils de ce billet, y compris le nôtre.

À qui ça convient : aux équipes qui veulent un éditeur en glisser-déposer et dont les lecteurs ne sont pas des ingénieurs.

À qui ça ne convient pas : aux équipes qui sont passées à Structurizr parce que le modèle était du texte. Abandonner l'architecture-as-code pour échapper à une fermeture de service cloud est un échange étrange, et vous le sentirez passer la première fois que vous voudrez differ un changement.

Option 4 : archyl

Nous avons construit un importateur de DSL Structurizr, c'est donc l'option que je connais le mieux et celle que vous devriez lire avec le plus de scepticisme.

Apportez workspace.dsl, pas workspace.json. Archyl parse le texte du DSL Structurizr. Il n'y a pas de chemin pour le JSON de workspace. Si le lien d'export ne vous a donné que du JSON, lisez la section ci-dessous avant d'essayer.

Ouvrez un projet, choisissez Structurizr DSL dans la modale d'import, uploadez le fichier .dsl ou collez-le. Ce qui passe : person et softwareSystem au niveau racine, les container et component imbriqués, les noms et les descriptions, les chaînes de technologie sur les containers, sur les components et sur les relations, les tags séparés par des virgules, les blocs group à n'importe quelle profondeur aplatis en tags group:<name>, et les relations déclarées n'importe où dans le fichier, y compris à l'intérieur du corps des éléments. Les types de container et de relation sont déduits de vos chaînes de technologie et de vos libellés. Les systèmes externes sont repérés à partir du tag External System ou External. L'importateur est testé contre le workspace d'exemple Big Bank de Simon Brown lui-même.

Ce qui ne passe pas, et qui compte davantage :

Toute la mise en page et tout le style. Les blocs views, configuration et styles sont ignorés. Archyl calcule une mise en page automatique à la place. La mise en page manuelle est l'un des arguments de vente de Structurizr : c'est donc ce que votre ancien outil faisait le mieux, et vous y renoncez.
!docs et !adrs. Les directives sont ignorées. Archyl a des ADR et de la documentation ; l'importateur Structurizr ne les remplit pas.
!include. Les workspaces multi-fichiers doivent être aplatis avant l'import, sinon le contenu inclus n'est tout simplement pas là.
Les environnements de deployment, les deployment nodes et les infrastructure nodes. Pas importés.

L'importateur vous réaffiche la plus grande partie de tout ça sous forme de liste d'avertissements sur l'écran de résultat d'import, dans les termes mêmes du fichier source :

line 42: 'views' block is not supported and was skipped
line 7: directive '!docs' is not supported and was skipped

Deux réserves là-dessus, parce qu'une liste à laquelle on peut se fier vaut mieux qu'une liste qui nous flatte. Premièrement, les environnements et les nœuds de deployment sont ignorés : archyl modélise la structure statique, pas la topologie de déploiement. Le parser les nomme avec leur numéro de ligne dans la liste d'avertissements, donc un bloc deploymentEnvironment "Live" arrive sous forme de ligne lisible plutôt que de découverte tardive. Deuxièmement, un avertissement vous dit ce que le parser a refusé ; il ne vous dit pas que l'import était parfait par ailleurs. Relisez le modèle ensuite.

Le seul argument pour payer ça plutôt que de faire tourner local : archyl revérifie le modèle contre le repository et note l'écart, si bien qu'un modèle qui cesse de correspondre au code le dit, au lieu de devenir silencieusement faux. C'est le drift score, il est déterministe, et il tourne sans appel à une IA. Si votre workspace Structurizr était exact et à jour le jour où le cloud est passé en lecture seule, vous n'en avez pas besoin et je n'essaierais pas de vous le vendre. S'il avait dix-huit mois de retard, l'outil n'a jamais été le problème, et le déplacer ailleurs n'y changera rien.

Deux choses à retenir contre nous. Le plan Developer gratuit plafonne un projet à 100 objets de modèle : un workspace avec cinquante systèmes et leurs containers n'y rentrera pas. Et archyl est cloud-first, l'auto-hébergement n'existant que sur le palier Custom. La raison que Structurizr a donnée pour fermer le service cloud, dans l'annonce même qui porte les dates, est que les équipes d'ingénierie rechignent à publier leurs diagrammes d'architecture dans le cloud et que l'usage déclinait régulièrement. Si ça décrit votre équipe sécurité, l'option 1 vous convient mieux que nous, et vous ne devriez pas passer deux semaines à le découvrir en phase d'achat.

Si tout ce que vous avez, c'est un fichier JSON

Le lien d'export de votre tableau de bord vous donne workspace.json, et c'est le fichier que la plupart des gens auront en main. Où il atterrit :

Structurizr local et le playground le lisent directement. Rien à convertir.
Archyl, non. Récupérez plutôt le DSL depuis l'onglet DSL, et faites-le avant le 30 septembre. Si le workspace a été rédigé via la Workspace API et que l'onglet DSL ne vous donne rien d'exploitable, deux solutions de repli : connectez le repository et laissez la découverte par IA proposer le modèle à partir du code, ou pointez un agent de code sur le JSON et faites-lui écrire le modèle via le serveur MCP, dont la recette est ici.
Partout ailleurs : demandez avant de migrer, pas après.

Choisir, en un paragraphe

Si votre modèle est déjà du DSL dans Git et que vos lecteurs sont des ingénieurs, faites tourner local et dépensez ailleurs l'argent économisé. S'il vous faut une instance partageable et à accès contrôlé et que vous pouvez porter la licence, server est ce qui se rapproche le plus de ce que le service cloud faisait pour vous. Si vous voulez un éditeur visuel et des lecteurs non techniques, regardez IcePanel. Si le workspace que vous venez d'exporter était déjà périmé, et qu'il est périmé parce que le mettre à jour à la main était la quatrième priorité de quelqu'un, alors ce n'est pas l'outil qu'il faut remplacer, et c'est exactement ce qu'archyl défend.

Quelle que soit l'option retenue : sortez les fichiers d'abord. L'onglet disparaît avec le service.

Plus de détails sur la mécanique : importer des projets Structurizr, LikeC4 et IcePanel, la page de migration Structurizr, et un comparatif 2026 des outils C4. Si le modèle lui-même est nouveau pour vous, commencez par le modèle C4 et l'architecture drift.