Mockup UI avec Claude : du brief au prototype cliquable

Un mockup UI, c'est l'écran qui montre à quoi va ressembler une fonctionnalité avant qu'un dev y touche. Pendant longtemps il fallait Figma, un designer, ou les deux. Claude change la donne : tu décris un écran en français, tu reçois du HTML/Tailwind rendu en direct dans un artifact, tu itères en quelques prompts. Pas de fichier .fig, pas de plugin, pas d'export. Juste un brief, du code, et un navigateur. Si tu débutes avec l'outil, le guide complet pour apprendre Claude couvre les bases ; ici on attaque directement la production d'interfaces.

L'angle de cet article : passer d'un brief texte à un prototype cliquable testable, en 30 minutes, sans designer. La méthode marche pour une landing, un dashboard, un onboarding mobile, un formulaire complexe. Elle ne remplace pas un design system mature, mais elle remplace très bien le wireframe Figma que personne n'a le temps de faire.

Ce que Claude sait (et ne sait pas) faire en mockup UI

Claude ne dessine pas. Il ne pousse pas de pixels dans Figma, il ne génère pas d'images d'interface (en tout cas pas de manière utile pour itérer). Ce qu'il fait : il écrit du code d'interface. HTML, CSS, Tailwind, React. Et grâce aux artifacts de Claude.ai, ce code se rend instantanément dans une fenêtre à droite de la conversation. Tu vois ton écran apparaître au fur et à mesure qu'il tape.

Trois niveaux à distinguer, parce qu'ils n'appellent pas les mêmes prompts :

• Wireframe basse fidélité : structure, blocs gris, pas de couleur, pas de typo travaillée. Sert à valider la hiérarchie et le flow.
• Mockup haute fidélité : couleurs, typo, espacement, états visuels. Sert à valider l'esthétique et la densité d'information.
• Prototype cliquable : plusieurs écrans liés, navigation fonctionnelle, états interactifs (hover, sélection, formulaire). Sert à tester un parcours.

Claude couvre les trois, mais avec des prompts différents. Demander un prototype quand tu cherches encore la structure, c'est perdre du temps à itérer sur des détails de couleur alors que le layout n'est pas validé. Si tu veux situer ce travail dans le reste du flux design, regarde la page Claude pour le design : identité visuelle, mockups, wireframes.

Écrire le brief que Claude attend

Un mockup générique vient toujours d'un brief générique. Cinq éléments rendent un brief exploitable :

1. Type d'écran : landing, dashboard, onboarding step 2, modal de confirmation, page produit e-commerce. Sois précis.
2. Audience : qui regarde l'écran, dans quel contexte, sur quel device.
3. Action principale : qu'est-ce que l'utilisateur doit faire ici. Un seul verbe si possible.
4. Contraintes visuelles : couleur dominante, ton (corporate, fun, technique), densité, mode clair/sombre.
5. Références : un site ou une app dont l'esthétique te parle. Claude connaît Linear, Stripe, Notion, Vercel, Airbnb, Apple. Cite-les nommément.

Compare ces deux briefs :

Fais-moi une page d'accueil pour mon app de réservation.

Versus :

Page d'accueil d'une app web de réservation de salles de coworking, audience freelances 25-40 ans à Paris. Action principale : taper une ville et une date, lancer la recherche. Style proche de Linear (typographie sobre, beaucoup d'espace, palette neutre avec un accent vert), mode clair, desktop d'abord. Hero, barre de recherche, 3 villes populaires, 1 témoignage, footer minimal.

Le premier produit un Lorem Ipsum coloré. Le second produit un écran que tu pourrais montrer à un client.

Prompt 1 : générer un premier mockup en HTML/Tailwind

Pourquoi Tailwind plutôt que du CSS custom : tout le style est inline dans le HTML, donc l'itération est immédiate (Claude n'a pas à jongler entre deux fichiers), et n'importe quel dev qui récupère le code peut le lire sans deviner la convention de nommage des classes. Voici un prompt qui marche, à copier et adapter :

Génère un mockup HTML + Tailwind CSS dans un artifact, pour l'écran suivant.

Écran : page d'accueil app de réservation de salles de coworking
Audience : freelances 25-40 ans, Paris
Action principale : rechercher une salle par ville et date
Style : inspiré Linear, palette neutre + accent vert (#10b981), mode clair, typo sans-serif
Device : desktop 1280px

Structure attendue :
- Nav minimale (logo + 2 liens + bouton CTA)
- Hero avec titre, sous-titre, barre de recherche (champ ville + date picker + bouton)
- Section "villes populaires" : 3 cartes avec image placeholder, nom, nombre de salles
- Témoignage unique, court
- Footer 3 colonnes

Utilise Tailwind via CDN. Place le tout dans un fichier HTML autonome.

Claude renvoie un artifact rendu en direct. Tu vois l'écran. Tu n'aimes pas, tu itères. C'est là que la vraie valeur arrive.

Itérer : 4 demandes qui font progresser le mockup

Le piège du débutant : essayer de tout obtenir en un prompt parfait. Ça ne marche jamais. Ce qui marche, c'est 4 à 6 itérations courtes, chacune ciblée sur une dimension.

1. Hiérarchie visuelle : « Le titre du hero n'a pas assez de poids visuel par rapport à la barre de recherche. Augmente la taille, baisse l'opacité du sous-titre, et resserre l'espacement vertical du bloc. »
2. Système de couleurs : « Remplace le vert par un bleu nuit (#1e3a8a) comme accent principal, garde le neutre, et ajoute une nuance chaude sur les CTA secondaires. »
3. Densité : « L'écran respire trop, on dirait une landing SaaS générique. Densifie : 2 sections supplémentaires au-dessus du footer, des cartes plus compactes, un padding hero divisé par deux. »
4. États d'interface : « Ajoute les états hover sur les cartes villes, l'état focus sur le champ de recherche, et un état vide pour quand aucune salle n'est trouvée. Montre l'état vide dans un second artifact. »

Chaque itération est une demande nette, sur un axe. Ne mélange pas. Si tu changes la palette et la structure en même temps, tu ne sais plus ce qui a cassé quoi.

Du mockup statique au prototype cliquable

Pour un vrai prototype, tu sors du HTML statique et tu passes en React. Claude gère ça nativement dans un artifact React. Le prompt type :

Convertis ce mockup en prototype React cliquable avec 3 écrans liés :

1. Accueil (l'écran actuel)
2. Résultats de recherche : liste de 6 salles avec photo, nom, prix, bouton "réserver"
3. Confirmation de réservation : récap salle + date + bouton "confirmer"

Navigation : useState pour gérer l'écran courant. Bouton "Rechercher" sur l'accueil envoie vers l'écran 2. Clic sur "Réserver" envoie vers l'écran 3. Bouton retour sur chaque écran.

Garde le style Tailwind actuel. Pas de routing externe, juste du state local.

Tu obtiens un artifact React où tu cliques réellement entre les écrans. Tu peux le partager via Claude.site (le lien public que Claude.ai génère pour les artifacts), ou copier le code dans un projet local et le lancer. C'est suffisant pour un test utilisateur rapide, une démo à un client, ou une validation interne avant d'investir dans le vrai design.

Récupérer le code pour le passer à un dev (ou à Claude Code)

Le code généré dans l'artifact n'est pas du code de production. Il est lisible, mais il a souvent : des classes Tailwind redondantes, des composants pas découpés, du contenu en dur, pas de gestion d'accessibilité fine. Trois options selon où tu veux aller :

Pour la troisième option, c'est là que Claude Code (l'agent CLI officiel d'Anthropic) prend le relais : il lit tes fichiers, écrit le code, lance les builds. Le pont entre le mockup et le site réel est détaillé dans créer un site web avec Claude. Et si tu n'as pas encore configuré Claude pour ce workflow, commence par configurer Claude pour le travail quotidien.

Limite à garder en tête : Claude exécute une intention claire, il ne la remplace pas. Si tu n'as pas pensé à l'état vide, à l'erreur réseau, ou au comportement mobile, il ne va pas les inventer à ta place. Il fera exactement ce que tu demandes, ni plus, ni moins. C'est une force quand tu sais ce que tu veux, une faiblesse quand tu attends qu'il te dise quoi faire.

Erreurs fréquentes et comment les éviter

• Brief trop court. « Une landing pour mon SaaS » donne une landing Bootstrap 2014. Correction : utilise les 5 éléments du brief, même pour un test rapide.
• Tout vouloir en un prompt. Layout + couleurs + interactions + responsive d'un coup : Claude fait un compromis sur chaque axe. Correction : itère sur un axe à la fois.
• Ignorer les états d'interface. Un mockup sans état hover, focus, vide, erreur, n'est pas un mockup, c'est une carte postale. Correction : demande explicitement les états dès la deuxième itération.
• Ne pas tester sur mobile. Tailwind est responsive par défaut, mais Claude génère du desktop-first par habitude. Correction : ouvre l'artifact en mode mobile via les devtools, puis demande les ajustements (« Sur mobile sub-640px, empile les cartes, réduis le hero à un seul bloc »).
• Confondre mockup et design system. Un mockup est jetable, un design system est durable. Si tu veux un système réutilisable (tokens, composants, doc), c'est un autre projet, beaucoup plus long.

Passer à la pratique cette semaine

Choisis un écran que tu repousses depuis des semaines : la landing de ton side-project, le dashboard interne que personne n'a le temps de designer, l'écran d'onboarding que ton dev attend. Écris le brief en 5 points. Lance le premier prompt. Itère 4 fois. Tu auras un mockup haute fidélité testable dans la journée, et un prototype cliquable d'ici la fin de semaine. La méthode tient sur une page, ce qui compte c'est de la faire tourner sur tes propres écrans, pas de la lire. Pour aller plus loin et intégrer ce workflow design dans une pratique Claude complète (prompts, projets, agents, intégrations), regarde la formation Maîtriser Claude au quotidien.