Deep Dive : Générer des diagrammes AWS avec un agent IA et Draw.io MCP

Pour y voir clair dans une infrastructure, un bon schéma c’est toujours appréciable. Mais les créer à la main prend du temps : trouver les bonnes icônes, positionner les éléments, tracer les connexions… Ce qui me passionne aujourd’hui, c’est de pouvoir automatiser tout ça avec l’IA.

Dans cet article, je vous montre qu’il est possible d’utiliser un agent IA avec le MCP Draw.io pour générer automatiquement des diagrammes d’architecture AWS. J’utilise Claude Code dans mon contexte, mais cette approche fonctionne avec n’importe quel agent compatible MCP.

Le point de départ : mettre à jour un vieux schéma

J’avais déjà un article sur l’infrastructure de ce blog datant de 2018 avec un schéma fait manuellement dans Draw.io. L’infrastructure n’a pas énormément changé depuis — j’ai essentiellement ajouté OAC (Origin Access Control) et une CloudFront Function — mais les icônes AWS ont évolué et je voulais mettre à jour le schéma avec les dernières versions.

En cherchant des solutions pour automatiser ça, je suis tombé sur le Draw.io MCP Server avec son extension Chrome. J’ai testé… et j’ai trouvé ça tellement cool que j’ai décidé d’en faire un article pour partager l’info !

Le MCP Draw.io : contrôler Draw.io avec l’IA

Le Draw.io MCP Server créé par Ladislav (lgazo) est un serveur MCP (Model Context Protocol) qui permet de contrôler Draw.io programmatiquement. Concrètement, ça veut dire qu’un agent IA peut créer, modifier et organiser des éléments dans un diagramme Draw.io.

Les outils disponibles

Configuration requise

Pour que l’agent IA puisse communiquer avec Draw.io, il faut configurer deux éléments comme indiqué dans la documentation du projet :

1. Un serveur MCP local — configuré dans le fichier de settings de votre agent (ex: .mcp.json pour Claude Code)
2. L’extension Chrome Draw.io MCP — qui fait le pont entre le serveur MCP et l’application Draw.io dans le navigateur

Une fois ces deux éléments en place, l’agent peut directement manipuler le canvas Draw.io : créer des shapes, les positionner, tracer des connexions, tout ça de manière programmatique.

En testant le MCP Draw.io, j’ai constaté qu’il fallait guider l’agent pour obtenir un résultat propre : ne pas inventer de ressources, utiliser les bonnes icônes AWS, respecter un positionnement cohérent, appliquer les couleurs par catégorie, éviter le HTML dans les textes… C’est pour ça que j’ai créé un skill Claude Code qui encode ces règles.

Création du skill /aws-diagram

Un skill Claude Code, c’est un fichier Markdown qui définit un workflow et des règles. Quand on invoque /aws-diagram, Claude Code charge ces instructions et les applique automatiquement.

Le workflow

Le skill suit un processus en 4 étapes :

1. Lire le code infrastructure (Terraform, CloudFormation)
2. Extraire les ressources AWS et leurs relations
3. Construire le diagramme avec les icônes officielles AWS
4. Ajouter les connexions avec des labels descriptifs

## Workflow

1. **Read infrastructure code** (Terraform, CloudFormation, etc.)
2. **Extract AWS resources** and their relationships
3. **Build diagram** with official AWS icons
4. **Add connections** with descriptive labels

Les règles critiques

J’ai dû encoder plusieurs règles importantes dans le skill :

1. Ne jamais inventer de ressources

C’était le piège principal. Les LLMs ont tendance à “compléter” ce qui leur semble logique. “Il y a CloudFront, donc il devrait y avoir Lambda@Edge pour…” — Non ! Le diagramme doit représenter exactement ce qui existe dans le code, rien de plus.

### NEVER invent resources

**Only diagram what actually exists in the infrastructure code.**

| Situation                  | Wrong                                         | Correct                                      |
| -------------------------- | --------------------------------------------- | -------------------------------------------- |
| No Lambda in Terraform     | Add Lambda@Edge because "it would make sense" | Don't add Lambda                             |
| CloudFront Function exists | Use Lambda icon                               | Use CloudFront icon with "CF Function" label |
| No WAF configured          | Add WAF for "security"                        | Don't add WAF                                |

2. Les utilisateurs sont externes

Les “Users” ne sont pas des ressources AWS. Ils doivent apparaître en dehors du groupe AWS Cloud.

### Users OUTSIDE the AWS Cloud

**Users are NOT AWS resources.** They represent external actors.

WRONG:
┌─────────────────────────────────┐
│ AWS Cloud │
│ [Users] → [Route53] → [CF] │ ❌ Users inside cloud
└─────────────────────────────────┘

CORRECT:
[Users] → ┌─────────────────────────┐
│ AWS Cloud │
│ [Route53] → [CF] → [S3] │ ✅ Users outside
└─────────────────────────┘

3. Pas de HTML dans les textes

Draw.io ne rend pas le HTML. Si vous écrivez text: "S3<br>Private", vous verrez littéralement <br> dans le diagramme.

### NEVER use HTML in text parameters

Draw.io does NOT render HTML tags in text fields. They display as raw text.

**FORBIDDEN (will show ugly raw HTML):**

text: "S3 Bucket<br>Private" ❌ Shows "<br>" literally
text: "Route 53&nbsp;DNS" ❌ Shows "&nbsp;" literally
text: "<font color='red'>ACM</font>" ❌ Shows raw HTML tags

**CORRECT (clean text):**

text: "S3 Bucket" ✅ Single line, clean
text: "Route 53" ✅ Service name only
text: "ACM" ✅ Simple label

4. Planifier le layout pour éviter les collisions

Les edges qui se croisent rendent le diagramme illisible. Le skill recommande de placer le flux principal sur une ligne horizontale, et les services auxiliaires au-dessus ou en-dessous.

### Rule 1: Main Flow on a Horizontal Line

Place the primary data flow (request path) on a single horizontal row:

[Entry] → [Service A] → [Service B] → [Service C]
y=300 y=300 y=300 y=300

### Rule 2: Auxiliary Services Above or Below

Services that connect TO a main service (not part of the flow) go above or below:

        [Auth]     [Edge Logic]     ← Auxiliary row (y=150)
           \           /
            \         /
             ↓       ↓

[Entry] → [Gateway] → [Compute] → [Storage] ← Main flow (y=300)

5. Annotations à droite, pas en dessous

Les icônes AWS ont leur label automatiquement placé en dessous. Si vous ajoutez des annotations en dessous aussi, elles chevaucheront la ligne suivante. Placez-les à droite de l’icône.

### Annotation Placement Rules

**CRITICAL: Place annotations to the RIGHT of icons, not below.**

**WRONG - Annotations below icons:**

[CloudFront] [S3]
|
"Cache Policies" ← Overlaps with next row!
"Security Headers"
|
[CloudFront Preview] ← Collision!

**CORRECT - Annotations to the RIGHT:**

[CloudFront] ── "Cache Policies: HTML 0s | Assets 1y"
| "Security: CSP | HSTS"
↓
[CloudFront Preview] ← No collision

Le système de couleurs

J’ai défini une palette cohérente avec les conventions AWS :

Pour les flux de données, j’utilise des couleurs d’environnement :

• Production : vert #4CAF50
• Preview : orange #FF9800
• Configuration : gris #AAAAAA (dashed)

### Colors by Category

| Category       | Color               | Services                                   |
| -------------- | ------------------- | ------------------------------------------ |
| **Networking** | `#8C4FFF` (violet)  | Route53, CloudFront, VPC, ELB, API Gateway |
| **Compute**    | `#ED7100` (orange)  | Lambda, EC2, ECS, Fargate                  |
| **Storage**    | `#7AA116` (green)   | S3, EFS, EBS                               |
| **Database**   | `#C925D1` (magenta) | RDS, DynamoDB, ElastiCache                 |
| **Security**   | `#DD344C` (red)     | ACM, IAM, WAF, Cognito                     |
| **General**    | `#232F3D` (gray)    | Users, Generic                             |

### AWS Icon Style Template

sketch=0;outlineConnect=0;fontColor=#232F3E;fillColor=<COLOR>;strokeColor=#ffffff;
dashed=0;verticalLabelPosition=bottom;verticalAlign=top;align=center;html=1;
fontSize=12;fontStyle=0;aspect=fixed;shape=mxgraph.aws4.resourceIcon;
resIcon=mxgraph.aws4.<SERVICE>;

### Edge Colors by Environment

| Environment   | Color     | Usage                  |
| ------------- | --------- | ---------------------- |
| Production    | `#4CAF50` | Main production flow   |
| Preview       | `#FF9800` | Staging environments   |
| Configuration | `#AAAAAA` | Dashed, non-data links |

Application concrète : l’infrastructure jls42.org

Pour tester le skill, je l’ai utilisé sur l’infrastructure de ce blog.

Le code Terraform analysé

terraform/
├── cloudfront-astro.tf    # Distribution CloudFront prod
├── s3-astro.tf            # Bucket S3 privé avec OAC
├── acm-astro.tf           # Certificat SSL
├── route53.tf             # DNS
└── variables.tf           # Variables

L’architecture extraite

Le diagramme généré

Voici le résultat final :

À partir d’un simple prompt en langage naturel :

« Analyse en profondeur l’infrastructure de ce projet puis réalise un super schéma de l’architecture AWS comme un pro. Juste l’infra de prod, pas preview ni legacy. »

Claude Code a d’abord analysé les fichiers Terraform pour identifier l’infrastructure, puis a chargé le skill /aws-diagram dont les instructions ont permis de :

1. Créer les composants principaux (Users, Route53, CloudFront, S3, ACM)
2. Ajouter les annotations détaillées (cache policies, security headers, bucket config…)
3. Tracer les connexions avec labels (HTTPS, DNS Alias, OAC, TLS Cert…)
4. Ajouter les services externes (Plausible Analytics, Gandi pour les emails)
5. Générer une légende par catégorie

Le tout en respectant un layout propre avec :

• Le cloud AWS dimensionné automatiquement (900×420px)
• Les Users à gauche du cloud
• Les services externes à droite
• Une légende sous le diagramme

Le workflow complet : de Terraform à la vidéo

J’ai poussé l’expérience plus loin en créant une vidéo de démonstration.

Enregistrement

J’ai enregistré la génération du diagramme en temps réel : 4 minutes 10 secondes de Claude Code qui lit le Terraform, crée les éléments un par un, et construit le diagramme sous mes yeux.

Post-production avec FFmpeg

4 minutes c’est long pour une démo. J’ai utilisé FFmpeg pour créer une version accélérée avec des vitesses variables :

Résultat : une vidéo de 42 secondes au lieu de 4 minutes, en gardant les moments clés à vitesse normale.

Narration avec HeyGen

Pour ajouter une voix off, j’ai écrit un script de narration, découpé la vidéo en segments de 30 secondes (limite HeyGen) et généré la voix en français. Les voix de base ne me convenaient pas, j’ai donc utilisé leur fonction de design vocal qui permet de créer une voix à la volée en ajustant un prompt jusqu’à trouver le ton parfait.

Le résultat final est la vidéo que vous pouvez visionner en haut de cet article.

Deuxième exemple : Architecture EKS Haute Disponibilité

Pour illustrer à quel point le MCP Draw.io fonctionne bien, voici un second exemple plus complexe : une architecture EKS (Elastic Kubernetes Service) hautement disponible. Le MCP fait tout le travail de création dans Draw.io — je n’ai eu qu’à fournir un prompt détaillé.

Cette fois, j’ai fourni un prompt détaillé décrivant l’architecture souhaitée :

Architecture EKS Hautement Disponible

Génère un diagramme d'architecture AWS EKS avec les composants suivants :

## Services AWS à inclure

### Externes (gauche du cloud)

- Users (icône utilisateurs générique)

### Networking

- Route 53 (DNS)
- Application Load Balancer (ALB) - dans les subnets publics
- NAT Gateway (3x, un par AZ)
- VPC avec 3 AZ

### Compute (subnets privés)

- EKS Control Plane (géré par AWS - représenter séparément)
- 3 Node Groups (un par AZ) avec pods à l'intérieur

### Storage

- EFS (stockage partagé cross-AZ)

### Security

- ACM (Certificate Manager)
- IAM (pour Pod Identity / IRSA)

### Observability

- CloudWatch (logs et métriques)

## Connexions à tracer

| Source            | Target      | Label               | Style       |
| ----------------- | ----------- | ------------------- | ----------- |
| Users             | Route 53    | HTTPS               | Solid green |
| Route 53          | ALB         | DNS Alias           | Solid green |
| ALB               | Node Groups | Traffic             | Solid green |
| ACM               | ALB         | TLS                 | Dashed gray |
| Node Groups       | EFS         | NFS Mount           | Solid green |
| EKS Control Plane | Node Groups | kubectl API         | Solid green |
| EKS Control Plane | IAM         | IRSA / Pod Identity | Dashed gray |
| Node Groups       | CloudWatch  | Logs / Metrics      | Dashed gray |

Le résultat généré

Ce diagramme illustre une architecture Kubernetes production-ready avec :

• 3 Availability Zones pour la haute disponibilité
• NAT Gateways redondants (un par AZ) pour la sortie internet
• Node Groups répartis avec pods dans chaque AZ
• EFS cross-AZ pour le stockage partagé persistant
• Control Plane AWS-managed séparé visuellement
• IRSA (IAM Roles for Service Accounts) pour la sécurité des pods

Le MCP Draw.io a correctement interprété la structure en créant les groupes VPC et AZ, positionnant les NAT Gateways dans les subnets publics et les Node Groups dans les subnets privés. Le résultat donne une excellente base de travail à peaufiner ensuite selon ses préférences visuelles, ou corriger d’éventuelles erreurs — bien plus rapide que de partir de zéro.

Ce que ce projet révèle

Cette expérience illustre plusieurs aspects de ma façon de travailler :

• Automatiser la documentation : le code est la source de vérité, le diagramme devrait en découler automatiquement
• Utiliser les bons outils : le MCP Draw.io était exactement ce qu’il me fallait, je n’ai pas réinventé la roue
• Encoder les règles : les skills permettent de capturer l’expertise et d’éviter les erreurs courantes — applicable à tout type de diagramme Draw.io, pas seulement AWS
• Tester sur du concret : j’ai utilisé ma propre infrastructure comme terrain d’expérimentation
• Pousser l’exploration : de la génération automatique à la vidéo narrée, chaque étape a été une occasion d’apprendre

Le skill est maintenant intégré à mon workflow. La prochaine fois que je modifie l’infrastructure, je pourrai regénérer le diagramme en un simple prompt.

Ressources

• Draw.io MCP Server par Ladislav (lgazo)
• MCP - Model Context Protocol par Anthropic
• Claude Code — l’outil CLI que j’utilise au quotidien

Si vous utilisez un agent de codage compatible MCP et que vous avez des infrastructures à documenter, je vous encourage à essayer cette approche. C’est satisfaisant de voir un diagramme propre se construire automatiquement sous vos yeux.

Merci d’avoir lu, j’espère que cet article vous aura donné envie d’expérimenter !