Claude Code /design : le workflow de Claude Design arrive dans le CLI

Claude Code dispose maintenant d’une commande /design. Elle reprend le workflow d’artboards de Claude Design depuis une session de développement et s’appuie sur les Artifacts de Claude Code.

Cette nuance compte. /design ne transforme pas le terminal en copie complète de Claude Design. La commande utilise le dépôt comme contexte, génère une page HTML visuelle, l’ouvre dans le navigateur, puis permet de revenir au code après avoir choisi une direction.

La rupture que j’avais encore dans mon workflow

Dans mon workflow agentique, le design restait une étape à part. Je préparais le produit dans Claude Code, puis je devais :

ouvrir Claude Design sur le web ;
remettre le contexte du produit ;
expliquer le design system et les composants existants ;
générer plusieurs maquettes ;
exporter ou décrire la direction retenue ;
revenir dans Claude Code pour l’implémenter.

Ce passage manuel posait un problème simple : le dépôt et la maquette ne partageaient pas automatiquement le même contexte. Il fallait répéter les contraintes à chaque nouvelle user story et vérifier que la maquette n’inventait pas des composants, des données ou des actions absentes du produit.

Ce que fait réellement `/design`

L’annonce officielle de Claude Developers présente /design comme le workflow d’artboards de Claude Design dans Claude Code, construit sur les Artifacts. Un Artifact est une page web interactive publiée depuis une session Claude Code vers une URL privée sur claude.ai.

Le parcours devient alors :

Claude Code inspecte le dépôt, ses composants et ses tokens ;
/design produit une page HTML autonome avec une ou plusieurs directions visuelles ;
le navigateur affiche les artboards ;
l’utilisateur compare les propositions et demande des corrections ;
Claude Code modifie ensuite les vrais fichiers du projet selon la direction validée ;
les tests et le git diff restent à contrôler avant toute PR.

La valeur vient du contexte du dépôt. Le modèle peut tenir compte du design system, des composants React, des états déjà supportés et des données disponibles au lieu de partir d’une page blanche.

`/design` et Claude Design ne sont pas le même produit

Claude Design	`/design` dans Claude Code
Produit créatif complet	Workflow visuel depuis une session de code
Projets, collaboration et commentaires	Artifact HTML autonome
Design systems partagés	Design system lu dans le dépôt
Édition visuelle avancée	Corrections demandées à Claude dans la session
Exports HTML, PDF, PPTX ou Canva	Retour direct vers les fichiers du projet

La ressemblance se situe dans l’exploration par artboards. La surface technique reste différente : /design génère un Artifact, pas un projet Claude Design synchronisé.

Mon test sur une vraie fonctionnalité SaaS

J’ai testé la commande sur DNS Connects, une fonctionnalité d’AgentMail. Le backend et les états existaient déjà : domaine vide, vérification en cours, succès, échec et indisponibilité de SES.

Je ne voulais pas une simple landing page inventée. Le design devait respecter les composants du produit, afficher les vrais enregistrements DNS et conserver les actions déjà disponibles.

Voici le type de prompt que j’ai utilisé :

/design
Analyse le parcours DNS Connects existant, ses composants,
ses tokens et les données disponibles.

Propose trois directions réellement différentes.
Réutilise le design system existant.
Couvre uniquement les états supportés par le backend.
N’implémente rien avant ma validation.

La dernière ligne est importante. Attendre la sélection avant de coder est une contrainte du prompt, pas une garantie automatique de la commande. Je veux d’abord comparer les directions, corriger les libellés et vérifier le responsive.

Le contrôle humain reste nécessaire

Une belle maquette ne prouve pas que la fonctionnalité est correcte. Après implement that, je vérifie encore :

les composants réellement réutilisés ;
les états métier couverts ;
les actions branchées sur le backend existant ;
le responsive et l’accessibilité ;
les tests ciblés ;
les fichiers modifiés dans git diff.

Cette étape évite de confondre qualité visuelle et qualité logicielle. L’Artifact sert à choisir une direction. Le dépôt, les tests et la revue déterminent si cette direction peut partir en production.

Les limites des Artifacts

La documentation Claude Code fixe plusieurs limites utiles à connaître :

un Artifact est une seule page HTML ou Markdown ;
il n’a pas de backend propre ;
les requêtes externes sont fortement limitées par la politique de sécurité ;
le fichier rendu doit rester sous 16 Mio ;
la publication nécessite un compte claude.ai compatible et une version récente de Claude Code ;
le résultat n’est pas automatiquement synchronisé avec un projet Claude Design.

Pour une maquette, un comparatif ou un tableau interactif, ce format fonctionne bien. Pour une application multi-page avec authentification, persistance et API, il faut toujours implémenter le produit dans son infrastructure réelle.

Mon verdict

/design réduit le transfert manuel entre le dépôt, la maquette et l’implémentation. C’est particulièrement utile quand le projet possède déjà un design system et des composants que Claude peut inspecter.

La commande ne remplace ni Claude Design complet, ni les tests, ni la revue du diff. Elle rapproche simplement la décision visuelle du code qui devra l’exécuter.

Voir le test complet de /design en vidéo

Recevoir mes prochains workflows IA et développement dans The Agentic Dev