La commande /design est arrivée dans Claude Code mi-août 2026 en research preview, portée par une annonce de Nate Parrott (designer produit chez Anthropic) sur X. Pas de billet officiel dédié, pas de doc stable : c'est une brique expérimentale, susceptible de changer d'une version à l'autre. Mais elle règle un problème concret pour les développeurs qui construisent avec Claude Code : arrêter de jongler entre l'app Claude Design côté web et le terminal côté code.
Si tu débarques sur l'écosystème Claude, commence par le guide complet pour apprendre Claude avant d'attaquer /design : la commande suppose que tu es déjà à l'aise avec Claude Code, les sessions, les artifacts et les permissions.
Ce que fait vraiment /design dans Claude Code
/design génère plusieurs maquettes d'interface éditables (des "artboards") directement dans une session Claude Code, sans quitter le terminal ni ton dépôt. Tu tapes une commande du type /design quelques options pour une page tarifs SaaS, Claude te renvoie plusieurs propositions rendues en HTML interactif via le runtime Artifacts, tu choisis, tu ajustes, puis tu demandes l'implémentation dans ton vrai code.
Point important : le rendu se fait en HTML/CSS interactif, pas en image bitmap. Pas de PNG à exporter, pas de fichier Figma généré. La commande s'appuie sur le flux artboards de Claude Design (l'outil autonome sur claude.ai/design, en research preview depuis avril 2026) et le combine avec le contexte de ta session de code : fichiers ouverts, stack détectée, composants déjà présents dans le repo.
La différence de fond avec Claude Design en web tient à cette continuité : /design n'est pas un outil de brainstorm isolé, c'est une étape dans un pipeline qui va de la maquette au commit dans la même session.
Prérequis : installer et configurer Claude Code pour le design
Avant tout, il te faut Claude Code installé et à jour. Si tu pars de zéro, passe par le setup complet de Claude Code : installation du CLI, authentification, choix du modèle par défaut. La commande /design étant en research preview, les sources publiques ne confirment pas de façon recoupée quels plans (Pro, Max, Team, Enterprise) y ont accès ni la version minimale de Claude Code requise. À vérifier dans ta propre install avec claude --version puis /help pour voir si la commande est listée.
Côté projet, tu profites de /design beaucoup mieux si ton repo est déjà propre. Une stack déclarée dans package.json, des composants shadcn/ui installés si tu vises ce style, Tailwind configuré, framer-motion présent si tu veux des animations : autant de signaux que Claude va lire pour aligner le rendu.
Si la commande native n'est pas dispo dans ta version, tu peux créer une custom command en attendant. Un fichier .claude/commands/design.md à la racine du repo, avec un prompt système qui décrit ce que tu attends, fait office de substitut acceptable pour prototyper le workflow.
# .claude/commands/design.md
Génère 3 propositions de maquette pour : $ARGUMENTS
Contraintes par défaut :
- Stack : Next.js 14 + Tailwind + shadcn/ui
- Responsive mobile-first
- Palette : neutre + un accent défini dans tailwind.config
- Composants shadcn : vérifier l'existence avant import
Sortie : un artifact HTML par proposition, éditable.Anatomie d'un prompt /design efficace
Un prompt /design qui produit du code utilisable tient en quatre blocs, dans cet ordre : quoi, pour qui, contraintes visuelles, contraintes techniques. Si tu sautes un bloc, tu récupères une maquette générique qu'il faudra rejeter.
Trois exemples réels, à copier et adapter :
Landing SaaS B2B : /design page d'accueil pour un outil de facturation destiné aux freelances français, ton confiant pas corporate, hero avec démo produit, section pricing 3 tiers, palette bleu nuit et accent orange, composants shadcn seulement, mobile-first
Dashboard analytics : /design vue dashboard pour un opérateur logistique qui suit 200 livraisons par jour, densité élevée d'info, filtre latéral, tableau principal avec tri, un graphique en haut, éviter les cartes rondes, Tailwind + recharts
Formulaire onboarding : /design formulaire d'inscription en 3 étapes pour une app de coaching, une question par écran, progression visible, boutons larges tactiles, animation framer-motion sur les transitions
Le "pour qui" est ce qui bouge le plus la sortie. "Un dashboard analytics" produit une maquette moyenne ; "un dashboard analytics pour un ops logistique qui traite 200 livraisons par jour" produit une densité, un choix de colonnes, une hiérarchie visuelle radicalement différents.
Exemple pas à pas : générer une landing en 4 minutes
Voilà une session type dans un projet Next.js déjà initialisé avec Tailwind et shadcn.
$ cd mon-saas
$ claude
> /design landing page pour un outil qui transcrit
automatiquement les réunions Zoom en compte-rendu Notion,
cible dirigeants de PME 20-100 salariés, palette sobre,
hero + 3 bénéfices + preuve sociale + CTA essai gratuit,
shadcn seulement, mobile-first
[Claude génère 3 artboards en HTML interactif]
> l'option 2 me plaît mais le CTA hero doit dire
"Essayer 14 jours" pas "Commencer", et la section preuve
sociale doit être 3 logos en ligne pas des témoignages
[Claude ajuste l'artboard 2]
> parfait, implémente cette version dans
src/app/page.tsx en utilisant les composants shadcn
déjà présents dans src/components/uiRésultat : un fichier page.tsx qui compile, des imports shadcn qui existent réellement (à vérifier quand même, voir plus bas), un rendu visuel cohérent avec ce que tu as validé à l'écran. La durée totale dépend de la complexité de la page et du nombre d'itérations : aucune mesure chiffrée fiable n'est disponible à ce jour sur cette fonctionnalité en research preview, ne te fie à aucun chiffre de temps annoncé ailleurs.
Pour un pipeline plus large, où /design n'est qu'une étape parmi d'autres, regarde comment enchaîner brief, wireframe, code et déploiement dans le workflow complet de création de site avec Claude.
/design en terminal vs Claude Design en web : lequel choisir
Les deux outils partagent la même techno d'artboards, mais visent des moments différents du projet.
| Critère | /design (terminal) | Claude Design (web) |
|---|---|---|
| Contexte de départ | Repo existant, stack déclarée | Page blanche, exploration |
| Output principal | Code committable | Maquette partageable |
| Boucle d'itération | Prompt → artboard → code, même session | Prompt → artboard → export PDF/PowerPoint/Canva |
| Bon pour | Ajouter une page à un projet vivant | Brainstorm avec un client non-tech |
| Moins bon pour | Explorer 20 directions visuelles | Générer du code prêt à commit |
La règle en pratique : si le code existe déjà et que tu veux ajouter une vue, /design. Si tu pars de rien et que tu veux montrer trois directions à un client avant même d'ouvrir un éditeur, Claude Design sur le web.
Limites actuelles et pièges à éviter
Trois pièges reviennent souvent, aucun n'est bloquant mais chacun mérite un réflexe.
Hallucination de composants shadcn. C'est le piège numéro un. Claude génère parfois import { DataTable } from "@/components/ui/data-table" alors que shadcn ne fournit pas ce composant en catalogue standard, tu l'as peut-être installé sous un autre nom ou pas du tout. Réflexe : après chaque implémentation, lance npm run build ou tsc --noEmit. Les imports fantômes remontent en 5 secondes.
Contournement plus radical : liste explicitement dans ton prompt les composants shadcn autorisés (uniquement button, card, input, dialog, tabs). Claude se cale sur ta liste plutôt que d'inventer.
Coût en tokens sur les gros composants. Un dashboard complet avec 15 sections en un seul /design consomme lourd, et le résultat est souvent médiocre parce que Claude étale son attention. Découpe : une session /design par écran ou par section importante. Bonus, tu itères plus vite sur chaque brique.
Style qui ne matche pas l'existant. Sur un projet déjà avancé, la maquette générée peut ignorer ton design system. Cite explicitement le fichier de config (tailwind.config.ts) et un ou deux composants existants à prendre comme référence : /design nouvelle page paramètres, style aligné sur src/app/dashboard/page.tsx et les tokens définis dans tailwind.config.ts.
Intégrer /design dans un workflow de site complet
/design n'est pas un outil isolé, c'est une étape d'un pipeline plus large. Sur un projet type de site vitrine ou d'app SaaS avec Claude Code, la séquence qui fonctionne :
- Brief produit et arborescence, en conversation Claude classique ou via Claude Projects.
- Setup du repo Next.js, Tailwind, shadcn, base de données si besoin.
/designpour chaque page ou vue clé, une par session, avec itérations.- Intégration des données réelles (fetch API, contenu Notion, produits Stripe).
- Tests, ajustements accessibilité, déploiement.
Le gain n'est pas seulement de vitesse, c'est de cohérence : la maquette et le code partent de la même source, dans la même fenêtre, avec le même contexte projet. Fini le décalage entre le Figma validé et le code qui ne ressemble pas.
Pour aller plus loin sur cette approche end-to-end (du brief au déploiement Vercel, en passant par le contenu SEO), la formation Maîtriser Claude au quotidien couvre le pipeline complet en 5 modules, avec un site en ligne et des automatisations n8n comme livrables concrets.