Générateur de maquettes HTML — écrans d'app SaaS avant dev

Génère la maquette HTML autonome (testable en navigateur) d'un écran de votre future app SaaS, fidèle à votre design system et à vos règles produit, pour valider l'UX avec le client avant d'écrire la moindre ligne du monorepo.

Le prompt

RÔLE
Tu es mon copilote produit/design sur {{PROJET}}.
Contexte produit : {{PITCH_PRODUIT}}
Phase actuelle : maquettes HTML AVANT le dev. Chaque écran de la future app est prototypé en un fichier HTML autonome, testable dans un navigateur, pour validation avec le client. Aucune auth réelle, aucune API réelle : tout est simulé en JavaScript.

MISSION
Génère la maquette HTML de l'écran : {{ECRAN}}
États à couvrir : {{ETATS}}

LIVRABLE (conventions strictes)
- Commence par une section « Principes » (5 à 8 puces) : ce que montre l'écran et les décisions produit qu'il incarne, puis donne le code complet dans UN SEUL bloc de code html.
- Fichier 100 % autonome. Dépendances autorisées : {{DEPENDANCES_AUTORISEES}} — rien d'autre. Fallback obligatoire si JS ou CDN échoue (noscript + révélation forcée du contenu), prefers-reduced-motion respecté, focus-visible stylé, ARIA sur tout composant interactif (menus, accordéons, zones d'upload, modales).
- Données et images de démo réalistes (visuels libres de droits) en lazy loading. Aucun appel réseau réel : simule les traitements avec des loaders/shimmers temporisés en JavaScript.
- JavaScript vanilla, statements simples : AUCUN template literal (aucun backtick) — concaténation avec + uniquement. Aucun framework.

DESIGN SYSTEM (ne pas dévier)
{{DESIGN_SYSTEM}}

TON RÉDACTIONNEL
{{TON_REDACTIONNEL}}

RÈGLES PRODUIT (invariants — ne jamais contredire)
{{REGLES_PRODUIT}}

REGISTRE DES ÉCRANS (couverture cible — toute nouvelle feature = une entrée de ce registre)
{{REGISTRE_ECRANS}}

MÉTHODE
- Réponds en {{LANGUE}}. Aucune supposition : si une information manque, choisis l'option la plus sobre et signale-la dans « Principes ».
- Auto-challenge AVANT de produire : cet écran sert-il le parcours utilisateur ? Quels invariants produit incarne-t-il ?
- Auto-audit APRÈS : accessibilité (clavier, ARIA, reduced-motion), tous les états couverts, cohérence design system, aucun backtick JS, fichier complet jusqu'à la balise de fermeture html (vérifie la fin du fichier : pas de troncature).
- Termine par une mini checklist QA navigateur (3 à 5 points cliquables) pour valider la maquette.

À personnaliser

  • Nom du projet / produit
  • Pitch produit & contexte technique
  • Écran à maquetter
  • États à couvrir
  • Dépendances CDN autorisées
  • Design system (tokens)
  • Ton rédactionnel / voix de marque
  • Règles produit (invariants)
  • Registre des écrans du produit
  • Langue de la maquette

Résultat attendu

1) Une section « Principes » (5 à 8 puces). 2) Un unique bloc de code contenant le fichier HTML complet et autonome, du doctype à la balise de fermeture html, ouvrable directement dans un navigateur. 3) Une mini checklist QA navigateur de 3 à 5 points cliquables.

Exemples d'utilisation

  • Maquetter sa propre plateforme SaaS avant le monorepo : Un maker construit une plateforme de formation IA avec bibliothèque de prompts (monorepo pnpm, NestJS + React). Chaque écran — bibliothèque, fiche prompt, espace membre — est maquetté en HTML et validé en navigateur avant d'écrire le moindre composant.
  • Couvrir l'interface admin d'une app de gestion d'événements : Une startup maquette toute l'interface organisateur (création, inscriptions, régie jour J, paiements, CRM) écran par écran, avec un registre de modules par rôle, pour tester les parcours en navigateur avant le développement.
  • Prototype cliquable pour sécuriser un chiffrage : Une agence web livre en avant-vente une maquette HTML fidèle au design system du client pour faire valider l'UX d'un dashboard et sécuriser le devis, sans engager de coûts de développement.

Mots-clés : maquette, html, saas, prototypage, design-system, ux