Chaque équipe a ce fameux diagramme d'architecture. Il était magnifique le jour où quelqu'un l'a fait, et faux environ une semaine plus tard. Un service a bougé, un cache est apparu, une file d'attente a été ajoutée, et personne n'a eu envie de rouvrir l'outil de dessin pour redéplacer des boîtes.
Alors le diagramme se dégrade en silence, et les nouveaux ingénieurs apprennent le système en lisant du YAML. La bonne nouvelle : ce même YAML suffit largement pour dessiner l'image à votre place. LetDraw lit votre fichier Compose ou Kubernetes et dispose l'architecture, si bien que le diagramme provient de la source de vérité au lieu de s'en éloigner.
Le docker-compose.yml en diagramme, en dix secondes
Ouvrez la boîte de dialogue Générer à partir du code, collez votre fichier, et vous obtenez un diagramme disposé, fait de vraies formes modifiables. Pas de boîtes à faire glisser, pas de flèches à relier à la main. Voici un fichier Compose que la plupart reconnaîtront :
services: web: image: nginx depends_on: [api] api: image: app:latest depends_on: [db, redis] db: image: postgres:16 redis: image: redis:7
Collez-le, et LetDraw le transforme en ceci :
La base de données est devenue un cylindre, le cache a reçu sa propre icône, et les liens depends_on sont devenus des flèches qui contournent vos boîtes au lieu de les traverser. C'est un diagramme, pas une capture d'écran d'une configuration.
Ce qu'il fait réellement
La boîte de dialogue fait trois choses qui méritent d'être soulignées :
- Elle détecte automatiquement le format. Vous ne choisissez pas « Compose » ou « Kubernetes » dans un menu. Collez, et LetDraw reconnaît de quoi il s'agit.
- Elle regroupe les éléments liés. Les manifestes Kubernetes sont regroupés pour que la disposition reflète vos namespaces, et non une soupe plate de nœuds.
- Elle appose les bonnes icônes. Les services, bases de données et files d'attente reçoivent des icônes de produits reconnaissables, pour que le diagramme se lise d'un coup d'œil.
Le diagramme provient désormais de la source de vérité : il est juste par construction, et non par discipline.
Pas seulement Compose
La même boîte de dialogue accepte bien plus qu'un seul format, et c'est tout l'intérêt. Si cela décrit une infrastructure ou un système, il y a de bonnes chances que cela se dessine :
- Des manifestes Kubernetes, regroupés par namespace
- Terraform et Helm pour l'infrastructure et les releases
- Graphviz DOT, du DDL SQL, une spécification OpenAPI, ou même un git log
- Mermaid et D2, si vous conservez déjà vos diagrammes sous forme de code
Puis faites-le vôtre
La disposition automatique fait 90 % du chemin, et c'est dans les 10 % restants que se trouve la valeur. Comme le résultat est fait de vraies formes, vous pouvez :
- Décaler une boîte, ajouter une note ou mettre en évidence le chemin risqué
- Regrouper les parties qui appartiennent à une équipe ou à un bounded context
- Exporter en PNG, SVG ou PDF pour un document, ou copier directement dans le presse-papiers
- Retransformer le dessin en Mermaid ou en D2 quand vous voulez retrouver du code
Et si vous voulez que cette image vive dans votre documentation, déposez un extrait d'intégration dans un README ou un wiki : elle reste une vue vivante en lecture seule. Fini le PNG obsolète que quelqu'un doit penser à réexporter.
Pourquoi c'est important pour le DevOps
Les diagrammes d'architecture sont censés être un modèle mental partagé. Dès qu'ils prennent du retard sur la réalité, ils deviennent un piège : ils enseignent la mauvaise chose aux nouveaux venus et donnent une fausse assurance aux relecteurs. Les générer à partir des fichiers que vous maintenez déjà comble cet écart. Le diagramme coûte peu à produire, donc peu à tenir à jour, et un diagramme à jour est le seul qui vaille la peine d'être conservé.
Collez votre docker-compose.yml et regardez votre stack se dessiner toute seule. Cela prend à peu près le temps de lire cette phrase.