Il existe un type de diagramme cloud qui met les relecteurs mal à l'aise sans qu'ils sachent vraiment pourquoi. Tout est un rectangle gris. Le load balancer, la file d'attente, le stockage objet et la base de données managée se ressemblent tous, et ne se distinguent que par les mots tapés à l'intérieur. Techniquement, c'est correct. Mais personne ne peut le parcourir rapidement, et un diagramme qu'il faut lire mot à mot n'est guère plus rapide que le paragraphe qu'il remplace.
Si les bons diagrammes cloud semblent si faciles à lire, c'est qu'ils s'appuient sur un langage visuel partagé. Un ingénieur qui a travaillé sur la plateforme reconnaît la forme d'un service de calcul, d'un stockage objet ou d'une file d'attente managée avant même de lire une étiquette. Quand votre diagramme utilise l'iconographie du fournisseur, il se branche directement sur cette mémoire commune et l'image devient lisible d'un coup d'œil. C'est toute la différence entre un diagramme auquel on fait confiance et un diagramme que l'on déchiffre en plissant les yeux.
Les icônes portent du sens, pas de la décoration
Il est tentant de considérer les icônes comme une finition ajoutée à la fin. Ce n'en est pas une : c'est ainsi qu'un diagramme cloud encode le type. Dès qu'une boîte porte l'icône du stockage objet, le lecteur connaît sa durabilité, son mode d'accès et son modèle de coût sans que vous ayez à l'écrire. Une icône de base de données managée dit « quelqu'un d'autre l'exploite » comme un simple rectangle ne le fera jamais. Retirez les icônes et vous jetez une couche d'information, ce qui explique pourquoi le diagramme tout gris paraît si plat.
Utilisez le vrai jeu d'icônes cloud du fournisseur
LetDraw inclut des bibliothèques d'icônes de style officiel pour les trois grands clouds (AWS, Azure et GCP) : vous n'avez donc pas à représenter approximativement un service de calcul par un pictogramme de serveur générique. Ouvrez la bibliothèque de formes, choisissez votre fournisseur et déposez les vrais services sur le canevas : le load balancer qui ressemble au load balancer de ce fournisseur, la file d'attente qui ressemble à sa file d'attente. Un diagramme construit avec le bon jeu se lit correctement pour quiconque travaille sur cette plateforme, ce qui est généralement le public exact du diagramme.
Mélanger les fournisseurs est tout à fait possible, et honnête quand votre système s'étend réellement sur plusieurs d'entre eux. Les icônes rendent la frontière évidente (cette moitié est sur un cloud, l'autre moitié sur un autre) au lieu de cacher une réalité multi-cloud derrière des boîtes grises uniformes.
La bonne icône dit au lecteur ce qu'est une boîte avant qu'il ne lise un seul mot. C'est tout le rôle d'un diagramme cloud.
Partez de l'infrastructure que vous avez déjà déclarée
Vous n'avez pas à placer chaque service à la main. Si votre infrastructure vit dans Terraform ou une déclaration similaire, ce fichier liste déjà les ressources et leurs connexions. Collez-le dans Générer à partir du code et LetDraw dispose les composants pour vous ; ajoutez ensuite les bonnes icônes du fournisseur sur les boîtes pour que le brouillon généré se lise comme une véritable architecture plutôt que comme un graphe de dépendances.
resource "aws_lb" "web" { # → load balancer icon } resource "aws_ecs_service" "api" { # → compute icon } resource "aws_db_instance" "main" { # → managed DB icon } resource "aws_s3_bucket" "assets" { # → object-store icon }
Restez lisible à mesure qu'il grandit
Les vrais diagrammes cloud se chargent vite, et ce qui les gâche, ce sont les flèches tracées en ligne droite à travers tout ce qui se trouve sur leur passage. Laissez plutôt le canevas faire passer les connecteurs autour de vos services, regroupez chaque niveau ou région dans un conteneur, et l'image reste lisible à trente boîtes comme elle l'était à cinq. Quand vous en avez besoin sous forme de code (pour un document, un wiki, une pull request), exportez en Mermaid ou D2 et commitez-le à côté du Terraform qu'il décrit.
Un bon diagramme cloud n'est pas plus joli qu'un mauvais ; il se lit plus vite. Utilisez les vraies icônes, générez le premier brouillon à partir de votre infrastructure, et offrez à vos relecteurs une image qu'ils reconnaissent immédiatement.