Créer un prototype interactif avec l’IA à partir des exigences

Un prototype a des cartes soignées et des boutons fonctionnels, mais confirmer une réservation ne change rien. Transformer les exigences en prototype interactif signifie spécifier un comportement, et pas seulement demander un écran.

Définir la seule décision du prototype

Utilisez un exemple fictif de réservation de deux sessions. Un visiteur choisit le matin ou l'après-midi ; chacun commence avec deux places disponibles. La confirmation réserve une place, la confirmation répétée ne doit pas en réserver une autre et l'annulation restaure cette place.

La démo utilise uniquement la mémoire de la page. Le rechargement réinitialise la démo et un autre onglet du navigateur ne partage pas sa capacité. Il s’agit d’une limite de révision explicite, et non d’un système de réservation prêt pour la production.

Ce tableau est plus précis que « rendre le formulaire intuitif ». Il donne au modèle et à l’examinateur une définition commune du succès.

Donner à l'IA le comportement et la portée de sa mise en œuvre

Créez un prototype HTML à fichier unique pour le flux de réservation fourni.
Utilisez les commandes natives d’étiquette/sélection/bouton et le texte d’état visible.
Capacité initiale : matin 2, après-midi 2. Une réservation par session de page.
Aucune sélection : désactiver la confirmation. Confirmez uniquement lorsque la capacité sélectionnée est positive.
Pendant la réservation : bloquez les confirmations répétées et les modifications de sélection.
Annuler : restaurez exactement une place sur le créneau réservé, puis effacez la réservation.
L'annulation répétée ne doit produire aucun effet. Annoncez les mises à jour dans une zone aria-live="polite".
Pas de bibliothèques externes, d'appels réseau, de données personnelles, de paiement ou de persistance.
Renvoie le code HTML complet, les instructions pour l'ouvrir et les cas d'acceptation.
Ne revendiquez pas de garanties de simultanéité ou de réservation de production.

Envoyez la table d’états avec le prompt et demandez un fichier HTML complet. Ouvrez-le et exécutez les cas d’acceptation ci-dessous ; une capture ou la mention « implémenté » ne suffit pas.

De la requête EvoLink au fichier à évaluer

1. Ouvrez la page Gemini 4 sur EvoLink et suivez les instructions Agent ou API. Fournissez le tableau des états et le prompt ensemble. Ajoutez deux scénarios : disponibilité normale 2/2, matin complet 0/2. Changer de scénario efface la sélection et la réservation. Demandez une mise en page lisible, les places restantes et des messages explicites de confirmation, d’annulation et de session complète.
2. Demandez un document HTML complet avec styles et script. Avec un Agent, faites enregistrer booking.html ; avec un client API, enregistrez le texte HTML reçu sans les délimiteurs Markdown. N’enregistrez pas l’enveloppe JSON comme fichier HTML. Vérifiez l’absence de scripts distants ou de requêtes réseau inattendus avant l’ouverture.
3. Ouvrez booking.html dans le navigateur. En scénario normal, choisissez Morning et confirmez : les places passent de 2 à 1 et la confirmation apparaît. Annulez : le compteur revient à 2 et la sélection s’efface. Un second appel du gestionnaire d’annulation dans un test doit laisser le compteur à 2.
4. Passez à Morning full, puis choisissez Morning : 0 place, un message indiquant que la session est complète et une confirmation désactivée. Afternoon reste réservable ; la confirmation fait passer ses places de 2 à 1. Revenir à Normal efface la réservation et rétablit 2/2. Ce contrôle prépare des données de test, sans simuler d’autres utilisateurs ni la concurrence côté serveur.
5. En cas d’échec, renvoyez par la même intégration l’état initial, les clics, le résultat attendu, le résultat obtenu et le HTML. Demandez une correction ciblée, puis rejouez les deux scénarios. Consignez les résultats acceptés et la consommation avant de comparer un autre modèle via la passerelle ; produire un fichier ne prouve ni sa qualité ni un avantage de coût.

Un prototype de référence exécutable complet

La référence suivante est un exemple pédagogique rédigé, pas une réponse issue d’un test de modèle. Son interface reste en anglais dans toutes les versions afin de conserver un fichier exécutable identique. La mise en page et les messages permettent d’évaluer le parcours, sans constituer une conception finale du produit.

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Session booking · Review prototype</title>
<style>
* { box-sizing: border-box; }
body { margin: 0; background: #f4f6f8; color: #172033; font: 16px/1.6 system-ui, sans-serif; }
main { max-width: 640px; margin: 48px auto; padding: 28px; background: white; border: 1px solid #dce2ea; border-radius: 16px; }
h1 { margin: 8px 0; font-size: 30px; line-height: 1.2; }
p { margin: 12px 0; }
.eyebrow { color: #526077; font-size: 13px; text-transform: uppercase; letter-spacing: .08em; }
label { display: block; font-weight: 600; margin: 16px 0 6px; }
select, button { font: inherit; padding: 10px 14px; border: 1px solid #aeb9c8; border-radius: 8px; }
select { width: 100%; background: white; color: #172033; }
.actions { display: flex; flex-wrap: wrap; gap: 10px; margin-top: 20px; }
button { cursor: pointer; background: white; color: #172033; }
#confirm { background: #193e87; color: white; border-color: #193e87; }
button:disabled { opacity: .5; cursor: not-allowed; }
:focus-visible { outline: 3px solid #b56b00; outline-offset: 3px; }
#status { background: #edf3fc; padding: 16px; border-radius: 8px; }
small { display: block; color: #526077; }
fieldset { margin: 28px 0 0; padding: 16px; border: 1px dashed #aeb9c8; border-radius: 8px; }
legend { font-weight: 600; }
@media (max-width: 680px) { main { margin: 16px; padding: 20px; } }
</style>
</head>
<body><main>
<p class="eyebrow">Interactive prototype · Local demo</p>
<h1>Book a workshop session</h1>
<p>Choose a session, confirm your place, or cancel to release it.</p>
<p id="capacity"></p>
<label for="slot">Session</label>
<select id="slot"><option value="">Choose a session</option>
<option value="am">Morning</option><option value="pm">Afternoon</option></select>
<div class="actions">
<button id="confirm" type="button" disabled>Confirm booking</button>
<button id="cancel" type="button" disabled>Cancel booking</button>
</div>
<p id="status" role="status" aria-live="polite"></p>
<small>One booking per page. Refresh resets this demo; other tabs do not share availability.</small>
<fieldset><legend>Review scenarios</legend>
<label for="scenario">Starting availability</label>
<select id="scenario"><option value="normal">Normal · 2 morning / 2 afternoon</option>
<option value="full">Morning full · 0 morning / 2 afternoon</option></select>
<p><small>Changing the scenario clears the current booking and selection. This control is for review only.</small></p>
</fieldset>
</main>
<script>
const capacity = { am: 2, pm: 2 };
const names = { am: "Morning", pm: "Afternoon" };
let selected = "";
let booking = null;
const slot = document.getElementById("slot");
const scenario = document.getElementById("scenario");
const confirmButton = document.getElementById("confirm");
const cancelButton = document.getElementById("cancel");
const status = document.getElementById("status");
const availability = document.getElementById("capacity");
function render(message = "") {
  const valid = Object.hasOwn(capacity, selected);
  confirmButton.disabled = !valid || booking !== null || capacity[selected] <= 0;
  cancelButton.disabled = booking === null;
  slot.disabled = booking !== null;
  availability.textContent = `Available: morning ${capacity.am}, afternoon ${capacity.pm}`;
  status.textContent = message || (booking !== null
    ? `Booked: ${names[booking]}. Your place is reserved in this demo.`
    : valid && capacity[selected] === 0
      ? `${names[selected]} is full. Choose another session.`
      : "Choose a session to book your place.");
}
slot.addEventListener("change", () => { selected = slot.value; render(); });
confirmButton.addEventListener("click", () => {
  if (!Object.hasOwn(capacity, selected) || booking !== null || capacity[selected] <= 0) return;
  capacity[selected] -= 1;
  booking = selected;
  render();
});
cancelButton.addEventListener("click", () => {
  if (booking === null) return;
  const cancelled = names[booking];
  capacity[booking] += 1;
  booking = null;
  selected = "";
  slot.value = "";
  render(`${cancelled} booking cancelled. Your place has been released.`);
});
scenario.addEventListener("change", () => {
  capacity.am = scenario.value === "full" ? 0 : 2;
  capacity.pm = 2;
  booking = null;
  selected = "";
  slot.value = "";
  render("Review scenario reset. Choose a session to test it.");
});
render();
</script>
</body></html>

Testez le comportement avant de peaufiner la mise en page

Commencez sans sélection et vérifiez que la confirmation est désactivée. Choisissez le matin, confirmez et vérifiez que le statut indique réservé. Annulez et vérifiez que les deux capacités reviennent à deux. Répétez l'annulation via l'interface utilisateur ou les contrôles automatisés et assurez-vous qu'elle ne peut pas créer une troisième place.

Essayez ensuite un autre créneau. Vérifiez que la réservation est effacée avant de modifier la sélection suivante. Les vérifications du gestionnaire sont importantes même si le bouton est désactivé : la transition d'état doit rester valide si le code appelle à nouveau le gestionnaire.

Le cas complet se teste désormais directement dans Review scenarios. Les erreurs réseau et les requêtes en cours restent hors du périmètre local ; définissez ces états avant de connecter un vrai service.

Trouvez les lacunes dans les exigences, pas seulement les bugs en HTML

La prochaine phase de mise en œuvre devrait mettre en place une capacité faisant autorité et une logique de réservation sur un backend avec la gestion des conflits requise. Ne considérez pas le compteur local comme une preuve que la réservation simultanée fonctionne.

Pour une véritable application Next.js, utilisez le système de composants et les limites d'état du référentiel au lieu de coller une page autonome en production. Le fichier HTML est un artefact de révision qui rend la décision relative au produit concrète.

Transférer les exigences avec le fichier de travail

Enregistrez la révision des exigences, le prototype, le tableau d'acceptation, les résultats des tests observés et les questions non résolues sur le produit. Si un réviseur modifie la règle d'annulation, mettez à jour la table d'état et l'interface, puis réexécutez les cas de test concernés.

FAQ

Un prototype cliquable a-t-il besoin d'un backend ?

Pas pour démontrer ce flux local. Les réservations partagées et la capacité persistante nécessitent une mise en œuvre faisant autorité.

Que dois-je fournir en plus d'une référence de conception ?

États, actions, résultats attendus, comportement en cas d’échec et portée. Une image à elle seule ne définit pas les règles de transition.

La désactivation du bouton est-elle une validation suffisante ?

Vérifiez également le gestionnaire de transition. L’état de l’interface utilisateur ne devrait pas être le seul élément empêchant les mises à jour non valides.

Pourquoi tester annuler deux fois ?

Il détecte la logique qui restaure la capacité plusieurs fois pour une réservation.

Puis-je copier ceci directement en production ?

Adaptez-le à l'architecture de l'application et implémentez les exigences manquantes en matière de backend, de validation et d'accessibilité avant de vous y fier.

Qu'est-ce qui rend le prototype prêt à être examiné ?

Il s'ouvre, les interactions convenues fonctionnent, les limitations sont visibles dans le transfert et le réviseur peut reproduire les cas d'acceptation.

Sources

• MDN : bouton.
• MDN : aria-live.