Wireframer une app avec Claude : la méthode en 5 prompts

Wireframer une app avec Claude, c'est passer d'une idée floue à quelque chose qu'on peut montrer, en une session. Pas un rendu Figma. Un wireframe basse fidélité : la liste des écrans, leur flow, leur structure, et un HTML gris que tu ouvres dans un navigateur. Cet article donne les 5 prompts exacts à copier, dans l'ordre.

L'approche marche parce qu'on demande à Claude des formats structurés (tableau, Mermaid, ASCII, HTML Tailwind) plutôt que de la prose descriptive. Si tu veux d'abord poser tes bases côté outil, va voir le guide complet pour apprendre Claude. Sinon, ouvre une conversation et on commence.

Pourquoi wireframer avec Claude plutôt que Figma directement

Claude ne remplace pas Figma. Il remplace la page blanche. Ce qu'il produit vraiment : de l'ASCII, des diagrammes Mermaid, du HTML/CSS statique, des specs textuelles structurées. Ce qu'il ne fait pas : rendu pixel-perfect, prototypage interactif natif, composants alignés au demi-pixel près.

Trois cas d'usage où le rapport temps/valeur est imbattable. Le MVP solo, quand tu es seul et que tu veux valider un flow avant de coder. Le brief à un designer, quand tu veux arriver avec 8 écrans structurés au lieu d'un paragraphe. La validation flow avant dev, quand tu veux vérifier qu'un parcours tient debout sans passer trois jours dans Figma. Pour tout le reste (design system existant, animations, prototypage clic), Claude s'articule avec un vrai outil de design, il ne le remplace pas.

Prérequis : ce que Claude a besoin de savoir avant le prompt 1

Sans contexte, les 5 prompts sortent du wireframe interchangeable, applicable à n'importe quelle app SaaS générique. Avant d'ouvrir Claude, remplis ces 5 lignes :

Type d'app : [web / mobile / desktop, responsive ou non]
User principal : [qui, une phrase, avec son contexte]
Proposition de valeur : [une phrase, ce que l'app fait gagner]
Jobs-to-be-done : [3 à 5 tâches concrètes que l'user vient faire]
Contraintes : [stack éventuelle, intégrations obligatoires, langues]

Exemple pour le fil rouge de cet article : app web responsive, freelance solo qui facture entre 40k et 120k€ par an, suivre ses dépenses pro pour préparer sa déclaration sans y passer un dimanche, jobs = ajouter une dépense en 10 secondes / catégoriser automatiquement / exporter en CSV pour le comptable / voir combien il reste de budget par catégorie, contraintes = pas de stack imposée, français d'abord.

Ces 5 lignes se collent en tête de chaque prompt suivant. Toujours.

Prompt 1 : cartographier les écrans

Objectif : sortir la liste exhaustive des écrans avec leur rôle et leur priorité. Pas les composants. Juste les écrans.

Contexte : [colle les 5 lignes de prérequis]

Donne-moi la liste exhaustive des écrans de cette app.
Format : tableau markdown avec 4 colonnes :
- Nom de l'écran
- Rôle (une phrase)
- Priorité (must-have / nice-to-have / v2)
- Écran(s) qui y mènent

Contraintes : entre 6 et 12 écrans pour un MVP. Regroupe ce qui
peut l'être. Ne compte pas les modales ni les états d'erreur
comme des écrans à part.

Sur l'app de dépenses freelance, Claude sort typiquement : Onboarding, Dashboard, Ajouter une dépense, Liste des dépenses, Détail dépense, Catégories, Export, Paramètres. Huit écrans, quatre must-have, une bonne base.

Si la liste dépasse 12, redemande en précisant "regroupe agressivement, un MVP tient en 8 écrans". Si elle est en dessous de 6, tu as probablement oublié un job-to-be-done dans les prérequis. Reviens en arrière.

Prompt 2 : définir le flow utilisateur principal

Un flow, pas dix. Le parcours qui représente 80% de l'usage. Format Mermaid parce que Claude le génère proprement et que ça se colle dans Notion, GitHub, HackMD sans conversion.

À partir de la liste d'écrans ci-dessus, génère le user flow
du parcours principal : [décris en une phrase, ex : "un
freelance ouvre l'app et ajoute une dépense reçue par mail"].

Format : diagramme Mermaid (flowchart TD).
Inclus les décisions (losanges) mais uniquement celles qui
changent réellement le parcours.
N'ajoute PAS d'étape de confirmation systématique après chaque
action. Un utilisateur qui ajoute une dépense n'a pas besoin
de 3 modales de validation.

Cette dernière ligne compte. Sans elle, Claude colle une confirmation modale après chaque clic, comme s'il concevait un logiciel bancaire des années 2000. Tu peux aussi demander un deuxième flow (le parcours d'onboarding, par exemple) dans un message séparé.

Prompt 3 : structurer chaque écran en composants

Un écran à la fois. Si tu demandes les 8 écrans d'un coup, Claude survole et sort du wireframe passe-partout. Un par un, la qualité change du tout au tout.

Prends l'écran "Dashboard" de la liste précédente.

Détaille sa structure en composants, du haut vers le bas :
- Header (logo, nav, actions)
- Zones principales (avec leur but)
- CTA principal (un seul, mis en évidence)
- CTAs secondaires
- États à couvrir : vide (première visite), chargement, erreur,
  cas nominal avec données

Format : ASCII wireframe monospace, largeur 80 caractères.
Utilise [ ] pour les boutons, ___ pour les inputs, ### pour les
titres. Pas de couleur, pas d'icône décorative.

Sortie type pour le Dashboard de l'app dépenses :

+------------------------------------------------------------------------------+
| DépensesPro          Dashboard  Dépenses  Export        [+ Ajouter]  [Menu] |
+------------------------------------------------------------------------------+
| ### Ce mois                                                                  |
| 2 847 € dépensés     Budget restant : 1 153 € / 4 000 €                     |
| [====================barre de progression====================              ] |
+------------------------------------------------------------------------------+
| ### Par catégorie                    | ### 5 dernières dépenses              |
| Matériel      1 200 €  [====      ]  | 12/03  SNCF Paris-Lyon      89,00 € |
| Déplacement     640 €  [==        ]  | 11/03  OVH hébergement      12,00 € |
| Logiciels       310 €  [=         ]  | ...                                  |
+------------------------------------------------------------------------------+

Recommence ce prompt pour chaque must-have. Compte 2-3 minutes par écran. C'est là que passer par Claude gagne le plus de temps face à une session Figma from scratch.

Prompt 4 : générer un wireframe HTML statique visualisable

L'ASCII c'est bien pour toi. Pour montrer à quelqu'un d'autre, il faut du HTML. Claude génère très bien du Tailwind basse fidélité, et tu peux l'ouvrir directement dans le panneau Artifacts.

Convertis la structure ASCII du Dashboard en HTML + Tailwind.

Contraintes :
- Basse fidélité : nuances de gris uniquement (gray-100 à gray-900),
  pas de couleur d'accent, pas de dégradé
- Pas d'icône (ou uniquement des placeholders carrés)
- Tailles réalistes : header 64px, cartes avec padding p-6,
  espacements généreux
- Placeholder de texte réaliste (pas de "Lorem ipsum", utilise
  des chiffres et libellés cohérents avec l'app)
- Responsive : desktop d'abord, mais que ça tienne aussi en mobile
- Un seul fichier HTML autonome, Tailwind via CDN

Claude sort un artifact. Tu cliques, tu as ton wireframe dans le navigateur, screenshot possible, partageable en Loom. Répète pour les 3-4 écrans clés. Pour aller plus loin et transformer ce wireframe en site vraiment déployé, la logique est décrite dans le pilier créer un site web avec Claude.

Prompt 5 : critique et itération

Ce prompt vaut souvent plus que les 4 premiers. Il rattrape 80% des faiblesses. Une condition : le lancer dans une nouvelle conversation, sinon Claude défend son propre travail.

Voici un wireframe HTML pour un [rappelle le contexte en 2 lignes].
[Colle le HTML complet]

Critique ce wireframe selon ces critères, dans l'ordre :
1. Le CTA principal est-il évident en moins de 3 secondes ?
2. La hiérarchie visuelle guide-t-elle vers l'action prioritaire ?
3. Les états critiques (vide, erreur, chargement) sont-ils prévus ?
4. Y a-t-il des redondances ou des zones muettes ?
5. Un utilisateur qui découvre l'app comprend-il quoi faire ?

Pour chaque problème : décris-le en une phrase, propose un fix
concret et actionnable. Ne reformule pas ce qui marche déjà.
Sois sec, pas complaisant.

Sur le Dashboard exemple, Claude remonte typiquement : le CTA "+ Ajouter" est en haut à droite mais la zone chaude du regard est en haut à gauche, le solde restant est plus proéminent que le solde dépensé alors que l'user veut d'abord voir ce qu'il a claqué, l'état vide de "première visite" n'est pas traité. Trois fix, chacun est un nouvel aller-retour de 30 secondes.

Exemple complet : app de suivi de dépenses freelance en 20 minutes

Le déroulé réel, chronométré :

Résultat après 22 minutes : une liste d'écrans priorisée, un user flow, 4 écrans structurés en ASCII, 2 wireframes HTML visualisables, une liste de corrections concrètes. Ce n'est pas un livrable client. C'est un document de travail qu'on peut envoyer à un dev, coller dans un brief Figma, ou utiliser pour tester le concept avec 3 freelances autour d'un café.

Limites et quand passer à un vrai outil

Claude cale sur trois types de sujets. Les interactions complexes : drag and drop, animations, micro-interactions, tout ce qui ne se voit pas dans un HTML statique. Les design systems existants à respecter : si ta boîte a un DS Figma avec 200 composants, Claude ne va pas s'y aligner. Les wireframes haute fidélité : dès qu'il faut du pixel-perfect, du copywriting fignolé, des vraies illustrations, on sort de son terrain.

À ce moment-là, le wireframe Claude devient un input, pas un livrable. Tu ouvres Figma avec les 4 HTML sous les yeux et tu construis proprement. Ou tu envoies le tout à un designer avec un Loom de 5 minutes.

Passer à la pratique

Les 5 prompts sont là, la méthode tient sur une page. Ce qui fait la différence entre un wireframe générique et un wireframe utile, ce sont les prérequis en amont et la discipline d'un écran à la fois au prompt 3. Le reste, c'est du copier-coller assumé. Si tu veux structurer ce type de workflow (design, blog, site, automatisation) comme un vrai processus qui tourne chaque semaine, la formation Maîtriser Claude au quotidien déroule les 5 modules qui couvrent du setup au marketing en passant par le design, avec un projet livré à chaque étape.