Comment écrire le prompt d'une application
Le prompt d'une application n'est pas une rédaction. C'est une demande, et une bonne demande répond à quatre questions avant de décrire le moindre écran.
Les quatre choses qui ne peuvent pas manquer
- Qui l'utilise. Une personne concrète, pas "les utilisateurs". Tout change selon que celui qui ouvre est le client, l'employé ou le patron.
- Ce qu'elle y fait. Un verbe à la fois : commander, réserver, enregistrer, approuver, consulter.
- Ce qui est stocké. C'est ce qui devient ensuite la liste, le filtre, la recherche et le rapport. C'est la partie la plus oubliée et la plus coûteuse à réparer.
- Qui voit quoi. Une phrase suffit, et elle évite le défaut le plus cher : un client qui voit la commande d'un autre.
Un modèle court qui marche
Une application pour que [qui] puisse [ce qu'il fait]. Chaque [enregistrement] stocke [champs]. [Qui] ne voit que le sien ; [qui] voit tout. Quand [quelque chose arrive], l'application [prévient quelqu'un / change l'état].
Quatre lignes couvrent plus qu'une page de souhaits épars. Le reste se règle mieux devant l'écran terminé.
Ce qu'il faut laisser hors de la première demande
- la technologie, sauf raison précise ;
- couleurs et typographie, sauf si la marque existe déjà. Le visuel est la partie facile à changer ensuite ;
- les fonctions de la version 3. Rapports avancés, tableau de métriques et intégrations viennent quand la version 1 a des utilisateurs ;
- le login, s'il n'y a encore personne à connecter.
Le deuxième prompt compte plus que le premier
La première demande génère l'application. Les suivantes sont celles qui la rendent juste, et elles ont une autre forme : au lieu de tout décrire, elles pointent un endroit.
Une bonne demande de correction a trois parties :
- où : l'écran ou le bouton ;
- ce qui se passe aujourd'hui ;
- ce qui devrait se passer.
"Sur la liste des commandes, le filtre de date ne change rien quand je choisis un mois ; il devrait montrer seulement les commandes de ce mois." Cette demande change très peu. "Améliore l'écran des commandes" invite à réécrire ce qui allait déjà bien.
Quand le problème est la mise en page, la capture vaut mieux que le paragraphe.
Les erreurs qui reviennent chaque semaine
- tout demander d'un coup. L'application naît grande, fausse à plusieurs endroits, et il devient difficile de savoir quelle correction a cassé quoi ;
- décrire la solution au lieu du problème. "Ajoute un champ caché qui garde le statut" retire à l'IA la chance de faire mieux ;
- changer de sujet en cours de route. Une demande, un sujet ;
- ne pas énoncer la règle de permission, et le découvrir devant un client.
Le résumé
- qui l'utilise, ce qu'il fait, ce qui est stocké, qui voit quoi ;
- quatre lignes valent mieux qu'une page ;
- laissez technologie et visuel pour plus tard ;
- une correction porte où, ce qui se passe et ce qui devrait se passer ;
- une demande, un sujet, et une capture quand c'est la mise en page.