La boîte la plus difficile à dessiner, c'est la première. Vous savez à peu près à quoi ressemble le système dans votre tête, mais le transformer en formes sur un canevas implique des dizaines de petites décisions avant d'avoir quoi que ce soit à quoi réagir. C'est là que le décrire d'abord avec des mots change vraiment la façon de travailler : vous obtenez une ébauche en quelques secondes, et il est bien plus facile de débattre d'une ébauche que d'un espace vide.
Voici la boucle complète, du début à la fin, sur un exemple réel. Le but n'est pas un diagramme fini comme par magie ; c'est une première version suffisamment bonne que vous rendez ensuite correcte à la main.
Étape 1 : écrire une phrase honnête
Ne réfléchissez pas trop au prompt. Décrivez le système comme vous le feriez à un nouveau collègue. Nommez les éléments et la façon dont ils sont reliés.
A web app with a CDN in front, a load balancer, two stateless API servers, a Postgres primary with one read replica, a Redis cache, and a background worker reading from a queue.
Cette phrase contient tout ce dont une première ébauche a besoin : les composants, la répartition (deux serveurs d'API), la couche de données (primaire plus réplica) et le chemin asynchrone (worker plus file d'attente). Vous ne demandez pas à l'outil d'être malin. Vous lui demandez de placer ce que vous avez déjà dit.
Étape 2 : générer l'ébauche du schéma d'architecture
Collez cela dans la boîte de dialogue de génération et vous obtenez un diagramme disposé, fait de vraies formes modifiables. L'intérêt ici, c'est la vitesse et l'exhaustivité : chaque composant que vous avez nommé est sur le canevas, à peu près dans la bonne relation, en autant de temps qu'il en faut pour lire la phrase.
Étape 3 : corriger ce que la machine a deviné
C'est l'étape qui distingue un outil utile d'un simple tour de passe-passe. L'ébauche est une supposition, et les suppositions se trompent par petites touches. Peut-être que le cache devrait se trouver devant la base de données, pas à côté. Peut-être qu'un seul serveur d'API communique avec le réplica. Comme le résultat est fait de formes modifiables, le corriger consiste à glisser et cliquer, pas à tout recommencer.
- Déplacez les éléments mal placés par la disposition.
- Tracez la connexion qu'elle a oubliée, ou supprimez celle qu'elle a inventée.
- Mettez en évidence le chemin qui compte (le chemin d'écriture, par exemple) pour que l'œil du lecteur s'y pose en premier.
- Regroupez les éléments qui appartiennent à un même service ou à une même équipe.
Le prompt vous mène à une ébauche. Vos modifications vous mènent à la vérité. Une seule de ces étapes a besoin d'un humain, et c'est la seconde.
Étape 4 : affiner en demandant, pas seulement en glissant
Vous n'avez pas à tout faire à la main. Si la forme du système est à peu près juste mais que vous voulez une variante, demandez-la : « ajoute un stockage objet pour les uploads » ou « place une API gateway devant les services ». Considérez la conversation comme un moyen rapide d'atteindre l'ébauche suivante, puis revenez à l'édition. Les deux modes, parler et glisser, se renforcent mutuellement.
Étape 5 : en faire un véritable artefact
Un diagramme qui ne vit que dans votre tête ne sert à personne. Une fois l'image juste, placez-la là où elle sera utilisée. Exportez en PNG, SVG ou PDF pour un document de conception. Intégrez-la dans un README en vue en lecture seule. Ou exportez-la en Mermaid ou en D2 pour qu'une version texte arrive dans la pull request et soit relue comme du code.
Voilà la boucle complète : une phrase devient une ébauche, l'ébauche devient correcte grâce à vos modifications, et le diagramme correct devient quelque chose que votre équipe peut réellement utiliser. L'IA a supprimé la partie la plus lente et la moins utile (placer des boîtes) et vous a laissé celle qui demande du jugement. Décrivez votre prochain système en une phrase et voyez jusqu'où la première ébauche vous mène.