Transformez code, Terraform et diagrammes en modèle C4 avec MCP

Le plus dur dans la documentation d'architecture, ce n'est pas de dessiner des boîtes. C'est qu'au moment où vous ouvrez l'outil, votre architecture existe déjà — éparpillée dans cinq endroits qui ne se parlent pas.

Un fichier Structurizr DSL que quelqu'un a maintenu pendant huit mois. Des diagrammes Mermaid dans une douzaine de READMEs. Des modules Terraform qui décrivent votre infrastructure réelle mieux qu'aucun diagramme ne l'a jamais fait. Un export PlantUML de l'outil que vous utilisiez avant. Et le code lui-même, la seule source qui ne ment jamais.

Samedi, j'ai montré comment migrer un espace Confluence dans Archyl avec deux serveurs MCP et un prompt. Aujourd'hui, la même astuce avec un prix plus gros : importer l'architecture elle-même.

Deux chemins, à choisir selon la source

D'abord, les chemins intégrés : si votre dépôt est connecté à Archyl, AI Discovery analyse le code et propose un modèle C4 complet — systèmes, conteneurs, composants, relations — que vous relisez et approuvez. Et si vous venez d'un autre outil C4, les exports Structurizr DSL, LikeC4 et IcePanel ont déjà un importeur en un clic. Quand l'un des deux convient, commencez par là.

Le chemin MCP est pour tout le reste : les sources que Discovery ne peut pas voir. Les fichiers de diagrammes-as-code, les définitions d'infrastructure, cette page d'architecture dans le wiki de quelqu'un, ou un dépôt sur un serveur privé. Le serveur MCP d'Archyl expose toute la surface d'écriture du modèle C4 — create_system, create_container, create_component, create_relationship, set_element_technologies, create_adr — donc tout agent capable de lire votre source peut écrire votre modèle.

La configuration est le même one-liner que samedi :

claude mcp add --transport http archyl https://api.archyl.com/mcp \
  --header "X-API-Key: your_api_key"

Recette 1 — Structurizr, Mermaid, PlantUML

Les diagrammes-as-code sont la victoire la plus facile, parce que la sémantique est déjà explicite. Pour un workspace.dsl standard, l'importeur en un clic ci-dessus est plus rapide — l'agent gagne sa place pour Mermaid et PlantUML (aucun importeur n'existe), les variantes de DSL que l'importeur ne sait pas parser, ou quand vous voulez fusionner sélectivement dans un projet qui a déjà un modèle. Ouvrez le dépôt dans Claude Code et :

Lis workspace.dsl à la racine de ce dépôt. Recrée le modèle dans
mon projet Archyl "Aurora Commerce" :

- softwareSystem → create_system (marque les systèmes externes
  comme external_system)
- container → create_container sous le bon système, garde le champ
  technology
- chaque relation → create_relationship avec sa description
- n'invente rien qui ne soit pas dans le DSL ; liste tout ce que tu
  n'as pas pu mapper

Ensuite relis le modèle avec list_systems et list_containers et
montre-moi un résumé pour que je vérifie que rien n'a été perdu.

L'étape de relecture à la fin est l'habitude à garder : l'agent vérifie son propre import contre le modèle réel au lieu de supposer que ça a marché.

Recette 2 — Terraform

Votre code d'infrastructure sait des choses que vos diagrammes ont oubliées. Pointez l'agent vers votre Terraform et laissez-le travailler à la bonne altitude :

Lis infra/ dans ce dépôt. Modélise l'architecture au niveau
déploiement dans Archyl : les services managés (RDS, SQS, S3,
CloudFront...) deviennent des conteneurs ou des systèmes externes,
un par vrai service — pas un par ressource. Câble les relations à
partir des politiques IAM, des security groups et des variables
d'environnement. Tague tout ce que tu crées avec "terraform" pour
que je puisse filtrer la couche importée plus tard.

La ligne « pas un par ressource » fait un vrai travail. Un importateur naïf transforme 400 ressources Terraform en 400 boîtes. Un agent comprend qu'une instance de base de données, son subnet group et son parameter group forment un seul conteneur appelé Orders Database.

Recette 3 — le code lui-même

Pas de DSL, pas de diagrammes, dépôt non connecté à Archyl ? L'agent est déjà assis dans votre code. Demandez-lui de proposer le modèle en partant du bas — les services depuis les manifestes de déploiement, les composants depuis la structure des packages, les relations depuis les clients HTTP et les producteurs de files d'attente qu'il trouve. C'est le travail d'AI Discovery fait à la main, et c'est le bon plan B quand Discovery ne peut pas atteindre la source.

Recette 4 — les diagrammes prisonniers de votre wiki

Combinez les deux serveurs MCP du post de samedi : l'agent lit les pages d'architecture via le serveur MCP d'Atlassian, extrait les systèmes et les flux décrits, et les écrit dans Archyl. La page de wiki qui décrit votre pipeline d'événements devient un modèle réel et navigable de celui-ci — et la page elle-même suit, en tant que documentation liée.

L'import est la partie ennuyeuse — voici le vrai enjeu

Le lendemain de l'import, c'est pour ça que vous l'avez fait. Parce que le modèle est entré par MCP, il reste accessible par MCP :

• Vos agents l'interrogent pendant qu'ils codent — « quels conteneurs parlent à la base de données des paiements ? » est à un appel d'outil.
• Les nouveaux services sont ajoutés par les agents mêmes qui les construisent, donc le modèle suit la réalité au lieu de se dégrader.
• Le scoring de dérive et les règles de conformité s'exécutent contre un modèle qui correspond vraiment à vos systèmes.

Une règle honnête pour conclure : l'agent propose, vous validez. Importez un système à la fois, lisez les résumés, et élaguez ce qui n'a pas sa place — la même discipline que n'importe quelle revue de code. Le modèle que vous obtenez ne vaut que les sources que vous lui avez données, et c'est vous qui savez laquelle des cinq sources disait la vérité.

Votre architecture existe déjà. Arrêtez de la redessiner — importez-la. La liste complète des outils est dans la documentation du serveur MCP.