Mockup UI avec Claude : du brief au prototype cliquable

Un brief, un prompt, trois passes d'itération, quatre pages liées et une URL publique. La méthode pour produire un mockup UI exploitable avec Claude en deux à trois heures, sans passer par un designer ni écrire une ligne de code de production.

Un mockup UI avec Claude, c'est un HTML+Tailwind autonome que tu ouvres dans le navigateur trente secondes après l'envoi du prompt. Pas un fichier Figma, pas du code de production. Un artefact intermédiaire : assez propre pour valider une direction avec un client, assez rapide pour tester trois versions du hero avant de te décider. Si tu débutes, commence par le guide complet pour apprendre Claude, l'article que tu lis ici suppose que tu sais déjà envoyer un prompt correct.

L'objectif de ce qui suit : partir d'un brief écrit et arriver à un prototype cliquable de 3 ou 4 pages, déployable sur une URL publique, en deux à trois heures. On va passer sur ce que Claude sait vraiment faire, comment écrire un brief qu'il peut transformer, le prompt de génération, la boucle d'itération sans tout casser, l'ajout de la navigation, et ce qu'on en fait ensuite.

Pourquoi Claude est bon pour les mockups UI (et où il coince)

Claude génère du HTML, du Tailwind, du JSX React, du SVG. Il tient une hiérarchie visuelle cohérente sur une page dense, il sait poser une grille de features, un pricing à trois colonnes, un dashboard avec sidebar. Sur du contenu réel bien fourni, la mise en page tombe juste du premier coup dans 7 cas sur 10.

Là où il coince : le rendu Figma natif (il ne produit pas de .fig), le pixel-perfect si tu compares à une maquette existante au pixel près, les animations complexes multi-étapes, et les illustrations sur mesure. Il ne remplace pas un designer sur une refonte à 40k € avec design system, recherche utilisateur et 12 rounds de revue. Il remplace le moment où tu ouvres Figma pour tester si l'idée tient debout.

Le bon cas d'usage : tu veux montrer une landing à un cofondateur ce soir, ou envoyer un prototype à un client pour valider un flow avant de lancer le dev. Deux à trois heures, un fichier partageable, itérable. Pour aller plus loin sur les usages design, la page pilier design couvre logos, wireframes, identité visuelle.

Écrire un brief que Claude peut réellement transformer en UI

La différence entre un mockup utile et une bouillie générique se joue avant le premier prompt, dans le brief. Six sections suffisent :

  • Objectif de la page : une phrase. "Convertir un freelance en essai gratuit de 14 jours sur un outil de facturation."
  • User : une phrase. "Freelance français, 1 à 3 ans d'activité, facture 5 à 20 clients par mois, tient sa compta sur un Excel qui déborde."
  • Action prioritaire : le CTA principal, formulé mot pour mot. "Commencer 14 jours gratuits", pas "S'inscrire".
  • Contenu réel : les titres, les 3 bénéfices, les 3 features détaillées, les 2 lignes de FAQ, le prix. Vrais mots, pas des placeholders.
  • Contraintes de style : "palette proche de Stripe, tonalité sobre, une accentuation orange sur les CTA, pas d'illustrations 3D".
  • Références visuelles : 1 à 3 sites que tu aimes, avec ce que tu aimes précisément.

Pourquoi le contenu réel change tout : Claude cale les proportions typographiques sur le texte fourni. Si tu écris "Facture tes clients en 30 secondes", il te sort un hero équilibré. Si tu écris "Lorem ipsum dolor sit amet", il te sort une maquette qui explosera dès que tu remplaceras. Un titre de 42 caractères et un titre de 12 caractères ne donnent pas la même mise en page, jamais.

Le prompt de génération : format de sortie, stack, contraintes

Le prompt qui marche 8 fois sur 10 tient en une douzaine de lignes. La stack : HTML+Tailwind CDN dans un seul fichier, autonome, ouvrable en double-cliquant. Pas de build, pas de npm install, pas de dépendance externe autre que le CDN Tailwind et Lucide en inline SVG.

Génère un mockup HTML complet pour la landing décrite dans le brief ci-dessus.

Contraintes techniques :
- Un seul fichier index.html, autonome, ouvrable en double-clic
- Tailwind via CDN (https://cdn.tailwindcss.com)
- Icônes en SVG inline (style Lucide, stroke-width 1.5)
- Images placeholder via https://placehold.co/WIDTHxHEIGHT/COLOR/COLOR
- Responsive : mobile-first, breakpoint md à 768px
- Pas de JS externe, un peu de JS inline pour le menu mobile OK

Structure attendue, chaque section dans une balise section avec un id explicite :
- section#hero (titre H1, sous-titre, CTA primaire + secondaire, capture placeholder)
- section#logos (bandeau de 5 logos clients)
- section#features (3 features en grille, icône + titre + 2 lignes)
- section#pricing (2 plans, mensuel + annuel toggle)
- section#faq (4 questions, accordéon fermé par défaut)
- section#cta-final (CTA de reprise)
- footer

Palette : slate-900 pour le texte, orange-500 pour les CTA, blanc et slate-50 pour les fonds.
Rends le fichier complet, pas de résumé, pas d'explication.

Les quatre lignes qui évitent 80% des ratés : "un seul fichier autonome", "icônes SVG inline", "placeholders via placehold.co avec dimensions", et surtout "chaque section avec un id explicite". Ce dernier point est la clé de l'itération.

Itérer sur le mockup sans tout casser

La règle : ne demande jamais "refais tout en mieux". Claude va tout réécrire, changer la palette, décaler les proportions, et tu perds la version d'avant. Demande toujours une modification ciblée sur une section nommée.

Boucle qui marche :

  1. "Sur #hero uniquement, remplace le CTA secondaire par un lien texte 'Voir une démo', et ajoute une ligne de rassurance sous les CTA : sans carte bancaire, annulable en un clic."
  2. "Génère 3 variantes de #hero seulement, dans 3 blocs de code distincts. Variante A : hero centré. Variante B : split gauche texte, droite screenshot. Variante C : hero pleine largeur avec fond dégradé."
  3. Screenshot du rendu, envoyé en vision avec annotation : "L'espacement entre #features et #pricing est trop serré, double-le. Le titre de #pricing manque de poids, passe-le en text-4xl font-bold."

Cette dernière technique (vision + annotation) fait gagner un temps fou. Tu ouvres le mockup dans le navigateur, tu fais une capture, tu entoures le problème dans Preview ou n'importe quel outil, tu colles dans Claude. Il voit exactement ce que tu vois. Cette logique de dialogue itératif avec vision est aussi ce qui fait la différence dans un travail de logo avec Claude ou sur un portfolio généré.

Passer du mockup statique au prototype cliquable

Un mockup, c'est une image en HTML. Un prototype, c'est plusieurs pages qu'on peut traverser en cliquant. La différence prend 20 minutes de plus.

Demande : "Génère maintenant 3 pages liées à la landing : pricing.html (extension du bloc pricing en page dédiée avec comparateur détaillé), signup.html (formulaire d'inscription email + mot de passe), dashboard.html (aperçu du produit après connexion, mock avec 3 factures en tableau). Réutilise les mêmes composants (nav, footer, boutons, couleurs) que index.html. Les liens entre pages sont relatifs (href='/blog/pilier/design')."

Tu récupères 4 fichiers HTML dans un même dossier. Tu double-cliques sur index.html, tout le monde tient. Pour partager un lien à un client : glisse-dépose le dossier sur Netlify Drop, tu récupères une URL publique en 30 secondes. Tu peux aussi passer par Vercel ou Cloudflare Pages, même logique, drag and drop d'un dossier statique.

ÉtapeOutilTemps
Génération du mockupClaude (Sonnet ou Opus)10 min
Itération 3 passesClaude + captures annotées30 à 60 min
Pages supplémentairesClaude20 min
Déploiement URL publiqueNetlify Drop2 min

Pour un site à mettre en prod pour de vrai après cette étape de validation, la démarche complète de site avec Claude décrit le passage du prototype au site déployé.

Exporter vers Figma ou passer la main au dev

Deux sorties possibles selon ce que tu comptes faire du mockup.

Vers Figma. Si l'équipe design travaille en Figma et veut récupérer le mockup pour continuer, des outils comme html.to.design importent une URL et reconstruisent les calques Figma. Le rendu est correct pour des layouts simples, moins fiable pour des composants imbriqués. L'autre voie : reconstruire dans Figma en s'appuyant sur le mockup Claude comme référence visuelle, ce qui va souvent plus vite que d'importer puis nettoyer.

Vers un dev. Le HTML+Tailwind produit par Claude est une excellente référence pour un développeur. Il voit la structure, les classes utilitaires, la hiérarchie des composants. Il ne recopie pas ce code en prod (c'est du prototype, pas du code de production : pas d'accessibilité vérifiée, pas de tests, pas d'optimisation d'images), il l'utilise comme spec visuelle et réécrit dans le framework du projet (Next.js, Nuxt, SvelteKit, ce que tu voudras). Le gain : le dev part avec une compréhension exacte de ce que tu veux, tu évites 3 allers-retours "c'est presque ça mais".

Pour un flux de contenu qui accompagne le site (blog, SEO), la chaîne éditoriale complète avec Claude se branche naturellement sur le prototype validé.

Passer à la pratique

Écris ton brief ce soir, six sections, contenu réel. Envoie le prompt de génération, ouvre le fichier, fais trois passes d'itération sur zones nommées. Génère 3 pages liées, glisse le dossier sur Netlify Drop. Tu envoies une URL publique à ton client avant demain midi.

Si tu veux structurer une pratique quotidienne de Claude (design, site, blog, automatisation, marketing) plutôt que de picorer, la formation Maîtriser Claude au quotidien couvre les cinq blocs sur cinq semaines, un projet livré par semaine, cohorte à effectif limité.

Pilier 2 · Mastery

Claude pour le design : identité visuelle, mockups, wireframes

Générer des identités visuelles, des wireframes UI et des mockups d'application en quelques prompts, sans Photoshop ni Figma.

Découvrir le pilier complet →Formation Claude Mastery →