Que faut-il vraiment mettre dans une requête de build ?
Quatre choses, et je le dis après avoir vu quelque chose comme deux cents de ces requêtes se transformer en sites terminés : ce que c'est, à qui c'est destiné, les incontournables et — en option — une ambiance. Tout le reste, c'est du bruit que le constructeur comblera de toute façon avec des valeurs par défaut, donc le vrai savoir-faire n'est pas d'écrire plus, mais de repérer sur lesquels de ces quatre points vous avez réellement un avis, et de ne dire que cela.
Commencez par ce que c'est, et limitez-vous à une catégorie, pas un cahier des charges. « Un site de réservation pour un studio de yoga » l'emporte sur « un site où les gens voient les horaires et cliquent sur un bouton pour réserver un créneau et recevoir une confirmation », même si la deuxième formulation contient plus d'informations. La catégorie active des valeurs par défaut que le constructeur possède déjà — les horaires ressemblent à des horaires, les parcours de réservation ressemblent à des parcours de réservation — tandis que la description l'oblige à reconstruire la catégorie à partir de rien.
Dois-je préciser à qui c'est destiné ?
Ce n'est pas obligatoire, mais c'est la ligne que les gens omettent alors qu'ils ne devraient pas. « Pour les élèves actuels du studio » et « pour des personnes qui découvrent le studio pour la première fois » produisent des sites différents sur presque tous les points qui comptent — le ton du texte, la présence d'un grand visuel marketing ou d'une mise en page directement orientée réservation, la mise en avant des tarifs (les nouveaux visiteurs en ont besoin) ou leur discrétion (les habitués les connaissent déjà). Une seule phrase ici peut résoudre une centaine de petites ambiguïtés qu'une page entière de demandes de fonctionnalités ne résoudrait jamais. Si le public est vraiment générique, ne le précisez pas — n'en inventez pas un juste pour remplir la case.
Combien d'incontournables dois-je lister ?
Deux ou trois. Le test que j'utilise : rejetteriez-vous le premier build s'il manquait cet élément ? « Planning des cours, paiements en ligne, biographies des professeurs » passe ce test pour un studio de yoga — sans planning, ce n'est pas une version plus petite du site, c'est un site différent. « Une inscription à la newsletter dans le pied de page » ne passe presque jamais ce test ; c'est un plus agréable, et les plus agréables ont leur place dans la discussion de suivi une fois que vous avez vu un plan, pas entassés dans la requête initiale où ils entrent en concurrence avec ce qui compte vraiment.
C'est franchement l'ingrédient que les gens ratent le plus, dans les deux sens. Zéro incontournable, et le constructeur devine, parfois à tort. Huit incontournables, et le constructeur les traite tous comme également essentiels, et le résultat ressemble à une liste de fonctionnalités déguisée en site web — sans hiérarchie, sans espace pour respirer. Si je devais insister sur un seul ingrédient à ne pas sauter, ce serait celui-ci. Même une seule phrase sur « les deux choses qui font que c'est le vôtre » évite presque à chaque fois un aller-retour, car c'est la seule information que le constructeur n'a aucun moyen de déduire de la catégorie seule.
Dois-je préciser une ambiance ?
Uniquement si vous en avez une. De nombreux bons prompts s'en passent complètement, et c'est très bien ainsi — le directeur artistique s'engage sur une direction artistique que vous en précisiez une ou non. Une ambiance en deux mots (« chaleureux et fait main », « clinique et rapide », « comme une salle d'arcade des années 90 ») ne fait que rediriger cet engagement quelque part au lieu de le laisser aux valeurs par défaut de la catégorie. Si vous avez une réaction forte — vous savez que vous voulez des fonds crème et une typographie serif chaleureuse, ou vous savez que vous détestez les coins arrondis — utilisez cette clause. « Propre et moderne » ne compte pas, d'ailleurs. Ce n'est pas une ambiance, c'est l'absence d'ambiance, et cela n'oriente rien tout en vous coûtant quand même un emplacement.
Pourquoi ne pas simplement décrire tout ce à quoi je pense ?
Parce que le générateur s'exécute à la lettre. C'est le véritable mode de défaillance, et ce n'est pas ce à quoi on s'attend — ce n'est pas que trop d'informations embrouillent le générateur, c'est que chaque phrase que vous écrivez est lue comme une instruction, y compris les idées à moitié formées que vous abandonneriez volontiers en y repensant. J'ai vu quelqu'un écrire « peut-être une section témoignages, pas sûr » et obtenir en retour une section témoignages avec trois citations d'exemple, parce que « peut-être, pas sûr » est une réserve pour un lecteur humain et une demande de fonctionnalité pour un système qui vous prend au mot.
Cela n'aurait pas d'importance si sous-spécifier coûtait cher, comme c'est le cas avec une équipe de développeurs humains, où l'ambiguïté vous coûte deux semaines avant que quelqu'un ne remarque que la mauvaise chose a été construite. Ce n'est pas coûteux ici. Le générateur planifie avant de construire — vous voyez une proposition concrète avant que quoi que ce soit ne soit engagé dans le code — donc sous-spécifier ne coûte qu'une correction de cinq minutes dans le chat, tandis que sur-spécifier expose d'emblée toutes vos idées les plus faibles et à moitié formées, précisément au moment où vous avez le moins d'informations pour savoir lesquelles valent la peine d'être conservées. Dix mots d'exigences réelles valent mieux que deux cents mots de flux de conscience, non pas parce que plus d'informations est mauvais dans l'absolu, mais parce que dans cette interface spécifiquement, chaque mot supplémentaire est un engagement.
Il y a aussi un coût plus discret : cela aplatit la hiérarchie. Énumérez douze fonctionnalités avec la même emphase et le générateur n'a aucun signal pour savoir lesquelles des trois vous tenez vraiment à cœur, donc il donne soit un poids visuel égal aux douze (résultat chargé), soit devine une priorité (parfois à tort, et vous voilà en train de déboguer une supposition au lieu d'exprimer une préférence). Trois incontournables énoncés simplement protègent cette hiérarchie. Douze dans un paragraphe l'effacent.
À quoi ressemble un bon prompt en pratique ?
| Prompt | Pourquoi ça marche |
|---|---|
| « Un carnet d'entraînement pour grimpeurs — séances, cotations, graphiques de progression. » | Le quoi plus trois incontournables, dix mots d'exigences au total. Pas de mention du public, car « des grimpeurs qui suivent leur propre entraînement » est une évidence liée à la catégorie — il omet à juste titre le seul ingrédient qui ne servait à rien ici. |
| « Une page d'accueil pour mon podcast sur l'agriculture urbaine, chaleureuse et éditoriale, avec une liste d'épisodes et un formulaire d'abonnement. » | Le quoi, le public implicite dans « mon podcast », l'ambiance, deux fonctionnalités. Cela ne précise pas quel lecteur intègre les épisodes ni combien s'affichent par page — ce sont des questions pour un second tour, pas pour le prompt initial. |
| « Un jeu de air hockey à deux joueurs, physique réaliste, un seul clavier. » | Les jeux rendent ce schéma évident : le genre plus la seule contrainte qui définit vraiment la jouabilité. « Physique réaliste » et « un seul clavier » ne sont pas tant des fonctionnalités que les deux décisions qui déterminent si le jeu ressemble à celui que vous aviez en tête. Couleur de la table, traînées du palet, interface de score — le générateur propose, vous réagissez. |
Ce qui relie ces trois exemples, ce n'est pas la concision pour elle-même, c'est que chaque mot a un rôle. Supprimez « chaleureuse et éditoriale » du prompt du podcast et vous obtenez une page de podcast générique ; supprimez « agriculture urbaine » et le mot d'ambiance n'a plus rien à viser. C'est le vrai test pour savoir si un prompt est bien construit — pas le nombre de mots. Je préférerais un prompt de 40 mots où chaque proposition a sa raison d'être plutôt qu'un prompt de 15 mots concis pour la forme et qui omet discrètement un incontournable.
Et si j'ai déjà des couleurs de marque ou de vraies photos ?
Joignez-les. Ne les décrivez pas. J'ai vu des gens rédiger un paragraphe méticuleux pour fixer une palette de marque dans un langage approximatif — « un vert forêt profond, plutôt sourd » — alors que la véritable charte graphique se trouvait dans un PDF sur leur bureau depuis le début. Une couleur décrite est une supposition que le générateur doit reconstruire ; une couleur jointe est simplement correcte. Menus réels, vraies photos, ressources de marque — les fonctionnalités de connaissances et de références les injectent directement dans la construction, et les faits l'emportent toujours sur les descriptions de faits.
