Quatre. C'est à peu près là qu'un build passe sa propre vérification pour la première fois et produit quelque chose qui fonctionne réellement — une page opérationnelle, un endpoint qui répond, un flux de connexion qui connecte quelqu'un. Onze est le nombre médian de prompts qu'un build accumule au moment où quelqu'un le déclare terminé et le déploie. Soixante-huit pour cent est la part de tous les prompts envoyés après cette première version fonctionnelle qui ne change rien qu'un utilisateur remarquerait dans la logique sous-jacente. Et trente est le point où la plupart des gens s'arrêtent discrètement, non pas parce que le produit est terminé, mais parce qu'ils n'ont plus rien à en dire.
Ces quatre chiffres décrivent sans cesse la même forme : les builds deviennent fonctionnels rapidement, puis passent l'essentiel du reste de leur existence à être commentés plutôt que reconstruits.
Le mur n'est pas là où on l'attendrait
Si on m'avait demandé, avant que je m'y intéresse, où les créateurs se retrouvaient bloqués, j'aurais deviné les intégrations — fournisseurs de paiement, callbacks d'authentification, l'API SMS qui exige un identifiant d'expéditeur vérifié. Ce sont de vrais points de friction, mais ce n'est pas là que le nombre de prompts explose. Ils coûtent généralement un ou deux tours supplémentaires puis se résolvent.
Le mur apparaît plus tard, une fois que la chose fonctionne. Un build atteint sa première vérification propre — les pages s'affichent, le flux principal se déroule de bout en bout, rien ne génère d'erreur — et au lieu de s'arrêter, les prompts continuent d'arriver. « Agrandis l'en-tête. » « Essaie une autre couleur d'accent. » « Peux-tu arrondir un peu plus le bouton. » « En fait, reviens à la première version. » Aucun de ces prompts ne touche à un modèle de données, une route ou un contrôle de permission. Ce sont tous des ajustements de surface.
Pourquoi « terminé » ne ressemble pas à un point d'arrêt
Une partie de ce phénomène tient simplement à la façon dont on vit l'itération de l'intérieur. Quand un build est cassé, on sait exactement quoi demander — corriger l'erreur, ajouter le champ manquant, connecter ce qui ne l'est pas. Quand il fonctionne, la cible disparaît. Aucun message d'erreur ne vous dit que la teinte de bleu est mauvaise. Vous faites désormais des choix de goût sans vérité de référence, et les choix de goût sont infiniment révisables, contrairement aux bugs.
L'autre partie tient au fait que prompter est bon marché et instantané, donc le coût d'un « essayons juste encore une chose » se rapproche de zéro sur le moment, même s'il ne l'est pas en cumulé. Une douzaine de passes cosmétiques de quelques minutes chacune représente un véritable après-midi, mais aucun prompt de cette douzaine ne semblait assez coûteux pour être évité.
Ce que les prompts tardifs changent réellement
| Plage de prompts | Cible typique | Changement fonctionnel ? |
|---|---|---|
| 1–4 | Pages principales, modèle de données, flux principal | Oui — c'est là que le produit se construit |
| 5–7 | Cas limites, états d'erreur, champs manquants | Généralement oui — de vraies lacunes découvertes à l'usage |
| 8–15 | Mise en page, texte, couleur, espacement, ton | Rarement |
| 16+ | Revenir sur des choix esthétiques antérieurs ou les retenter | Presque jamais |
C'est cette troisième ligne qui mérite qu'on s'y attarde. Ce n'est pas que la finition esthétique soit une perte de temps — un build qui a l'air générique performera moins bien qu'un autre soigné, et cette étape compte vraiment. C'est plutôt qu'elle n'a rarement besoin de huit à quinze prompts distincts pour être réussie, et que si elle en prend autant, c'est généralement par indécision, pas par itération. Vous ne convergez pas vers une meilleure réponse au onzième prompt ; vous oscillez entre deux réponses que vous aviez déjà obtenues au neuvième.
J'ai vu quelqu'un passer quarante minutes à déplacer un bouton d'appel à l'action entre trois positions sur une landing page, décider au quatorzième prompt que la première position était la meilleure, et demander à l'agent de build de la remettre. L'agent n'a rien fait de travers à aucun de ces échanges. Le bouton n'a simplement jamais eu besoin de quatorze avis.
Ce que l'écart entre vingt et trente prompts révèle vraiment
Voici ce qui m'a le plus surpris : les builds qui s'arrêtent autour du onzième prompt et ceux qui dépassent trente n'affichent pas de différence de qualité notable. J'ai cherché — plus d'itérations devrait forcément donner un produit plus abouti — et je n'ai globalement rien trouvé de tel. Ce que j'ai trouvé à la place, c'est que les créateurs qui s'arrêtent plus tôt ont tendance à avoir fixé leurs choix esthétiques une seule fois, en amont, dans le prompt lui-même (« épuré, minimaliste, une seule couleur d'accent, pas de photos de banque d'images ») plutôt que de découvrir leur goût au fil de vingt allers-retours d'essais-erreurs après coup.
Les builds les plus longs n'étaient pas les plus ambitieux. C'étaient ceux dont le prompt d'origine laissait le plus de choses en suspens — pas de ton défini, pas de référence, pas de public cible énoncé — si bien que chaque vide se comblait un petit prompt à la fois au lieu d'être tranché une fois pour toutes, par écrit, avant le premier lancement.
Ce qu'il faut en retenir concrètement
Si vous en êtes à quatre ou cinq prompts et que tout fonctionne, ce n'est pas une simple étape intermédiaire — c'est l'essentiel du travail qui est déjà fait. Ce qu'il reste à faire est réel, mais limité : vérifier les cas particuliers que personne n'avait pensé à décrire, relire les textes, et faire une seule passe délibérée sur le ton visuel plutôt qu'une douzaine d'essais exploratoires. Et si vous vous surprenez au vingtième prompt à encore ajuster un rayon de bordure, ce n'est généralement pas le signe que le build est inachevé. C'est plutôt le signe que le prompt initial aurait dû préciser ce que vous vouliez dès le départ — et cette correction a sa place dans le premier message du prochain build, pas dans le quarantième message de celui-ci.
