Comment rédiger des requêtes pour les générateurs d'applications IA (avec exemples avant et après)
Une bonne requête pour un générateur d'applications IA décrit le produit, pas le code : qui l'utilise, ce qu'il fait étape par étape, les données qu'il conserve et qui a le droit de voir quoi. Une fois la première version existante, demandez un changement précis par message, précisez ce qui doit rester identique et décrivez les problèmes sous la forme « J'ai fait X, je m'attendais à Y, j'ai obtenu Z ». Ces trois habitudes règlent la plupart des résultats décevants.
Le reste de ce guide présente les modèles en détail, avec des exemples avant et après que vous pouvez adapter.
Pourquoi rédiger une requête pour un générateur d'applications est différent de bavarder avec une IA
Quand vous posez une question à un assistant conversationnel, une requête vague donne une réponse vague et vous passez à autre chose. Quand vous formulez une requête à un générateur d'applications IA, la réponse est un programme qui fonctionne. Chaque lacune de votre description est comblée par une supposition, et ces suppositions deviennent du code, des tables de base de données et des écrans avec lesquels vous devez vivre ou que vous devez défaire.
Le but d'une requête n'est donc pas de paraître intelligent. Il s'agit de laisser moins de décisions importantes au hasard. Vous n'avez pas besoin de vocabulaire technique pour cela. Vous devez être précis sur ce que vous seul connaissez : vos utilisateurs, votre flux de travail et vos règles.
Ce qu'il faut inclure dans une première requête
Avant d'écrire quoi que ce soit, répondez à ces questions. Chacune comble une lacune que l'IA devinerait autrement.
| Inclure | Pourquoi c'est important | Exemple |
|---|---|---|
| Le produit en une phrase | Pose le cadre de toutes les décisions suivantes | « Un site de réservation pour un salon de coiffure à deux fauteuils » |
| Qui l'utilise | Détermine les écrans et le ton | « Des clients sans rendez-vous sur téléphone, et le propriétaire sur un ordinateur portable » |
| Le parcours principal, étape par étape | La chose qui doit fonctionner en premier | « Choisir un service, choisir une heure, saisir nom et téléphone, recevoir une confirmation » |
| Les données conservées | Devient la conception de la base de données | « Services, réservations, clients » |
| Qui peut voir ou modifier quoi | Détermine la connexion et les permissions | « Seul le propriétaire voit toutes les réservations » |
| L'apparence, brièvement | Évite un style générique par défaut | « Sombre, sobre, gros boutons » |
| Ce qu'il faut laisser de côté pour l'instant | Garde la première version petite | « Pas de paiements ni d'avis pour le moment » |
Cette dernière ligne est sous-estimée. Dire ce que vous ne voulez pas empêche l'IA d'ajouter un blogue, une page de tarifs et une inscription à l'infolettre que vous n'avez jamais demandés.
Avant et après : la première requête
Avant :
Fais-moi une application pour mon gym.
Le générateur doit tout deviner : des membres ou du personnel ? Des cours ou de l'entraînement personnel ? Des paiements ? Vous obtiendrez quelque chose qui ressemble à un site de gym et ne fait pas ce dont vous avez besoin.
Après :
Construis une application de réservation de cours pour un petit studio de yoga. Les membres voient les cours de la semaine (nom, professeur, heure, places restantes), réservent une place et annulent jusqu'à deux heures avant. Les membres s'inscrivent avec courriel et mot de passe. Le propriétaire du studio se connecte pour ajouter des cours, voir qui est inscrit et marquer les présences. Conserve les cours, les membres et les réservations dans une base de données. Design calme et clair, qui fonctionne bien sur téléphone. Pas de paiements pour l'instant.
La seconde version reste courte. Elle répond simplement aux questions du tableau ci-dessus.
Décrire le comportement, pas l'implémentation
Vous obtiendrez souvent de meilleurs résultats en décrivant ce qui doit se passer plutôt que la manière de le construire.
Avant :
Ajoute un useEffect qui récupère les réservations et un composant modal pour les modifier.
Après :
Quand le propriétaire clique sur une réservation, ouvre un panneau où il peut changer l'heure ou l'annuler. Les changements doivent apparaître immédiatement dans la liste.
La première requête impose une technique précise qui ne convient peut-être pas à la façon dont l'application est construite. La seconde décrit le résultat et laisse l'IA choisir l'approche adaptée au code qu'elle a déjà écrit. Si vous êtes développeur et avez une préférence forte, dites-le, mais associez-la au résultat attendu.
Soyez concret sur les règles
Les règles d'affaires sont là où les applications construites par IA se trompent le plus souvent, car elles sont évidentes pour vous et invisibles pour l'IA. Énoncez-les clairement.
- Limites : « Un membre peut avoir au plus trois réservations à venir. »
- Délais : « Les annulations ferment deux heures avant le début du cours. »
- Cas limites : « Si un cours est complet, affiche un bouton de liste d'attente au lieu de Réserver. »
- Permissions : « Les professeurs voient les présences de leurs propres cours, mais pas celles des autres professeurs. »
Chacune de ces règles tient en une phrase. En oublier une signifie que l'application ne l'appliquera pas ou inventera sa propre version.
Après la première version : un changement par message
Une fois que quelque chose fonctionne dans l'aperçu, passez de la description de l'application entière à des demandes de petits changements vérifiables.
Avant :
Le design est bizarre, la réservation ne fonctionne pas bien, et je veux une vue calendrier et des courriels.
Après (en quatre messages distincts) :
- Quand je réserve la dernière place d'un cours, il affiche encore « 1 place restante ». Il devrait afficher « Complet » et masquer le bouton Réserver.
- Ajoute une vue calendrier par semaine sur la page des horaires, une colonne par jour. Garde la vue en liste actuelle comme option.
- Rends les cartes de cours plus compactes sur téléphone : moins de marge intérieure, nom du professeur sur la même ligne que l'heure.
- Envoie au membre un courriel de confirmation lorsqu'il réserve.
Pourquoi cela fonctionne :
- Chaque changement est assez petit pour que l'IA le réussisse en un seul passage.
- Vous pouvez tester chacun avant de passer au suivant.
- Si l'un tourne mal, vous pouvez annuler seulement cette étape sans perdre les autres.
Dire ce qu'il faut conserver
Quand vous demandez une modification d'un élément qui fonctionne déjà, dites à l'IA ce qui ne doit pas changer. C'est le moyen le plus simple d'éviter les régressions (des choses qui fonctionnaient et qui cassent après une modification).
Refais la section d'accueil avec un titre plus grand et une photo à droite. Conserve la navigation, les couleurs et tout ce qui se trouve sous la section d'accueil exactement comme ils sont.
La même règle s'applique aux données : « Ajoute un champ de numéro de téléphone aux membres. Ne supprime ni ne renomme aucun champ existant. »
Utilisez des captures d'écran et le texte exact
Des expressions comme « la chose en haut » sont ambiguës. La plupart des générateurs d'applications IA acceptent les images, et une capture d'écran accompagnée d'une courte note va plus vite qu'un long paragraphe de description.
- Joignez une capture d'écran et dites « le bouton entouré en rouge chevauche le menu sur téléphone ».
- Collez le texte exact de tout message d'erreur plutôt que de le paraphraser.
- Citez exactement les étiquettes à l'écran : « le bouton Enregistrer les modifications de la page Paramètres ».
Pour les bogues en particulier, utilisez cette structure :
Sur la page des réservations, j'ai cliqué sur Annuler pour une réservation de demain. Je m'attendais à ce qu'elle disparaisse de ma liste. Au lieu de cela, rien ne s'est passé et la réservation est toujours là après une actualisation. Corrige-le et vérifie que l'annulation fonctionne.
Notre guide sur comment déboguer une application construite avec l'IA va plus loin à ce sujet.
Planifiez d'abord les grands changements
Pour tout ce qui touche de nombreuses parties de l'application (ajouter des comptes utilisateurs à une application qui n'en avait pas, ajouter des paiements, changer la structure des données), demandez un plan avant toute modification du code.
Avant de changer quoi que ce soit, explique-moi comment tu ajouterais des comptes d'équipe : quelles nouvelles tables, quelles pages changent et ce qui arrive aux utilisateurs existants. Ne modifie pas encore le code.
Lisez le plan. S'il comprend mal quelque chose, corriger un paragraphe coûte beaucoup moins cher que de corriger une fonctionnalité terminée. Plusieurs générateurs ont un mode dédié à cet usage ; sur Mythex, c'est le mode Plan, à côté de Construire et Demander.
Ce qu'il faut éviter
| À éviter | Pourquoi | Plutôt |
|---|---|---|
| « Rends ça meilleur » / « Fais-le ressortir » | Aucune cible, donc l'IA modifie les choses au hasard | Nommez le changement : « plus d'espace entre les sections, titres plus grands » |
| Une énorme requête avec dix fonctionnalités | Les erreurs s'accumulent ; difficile à tester | Une fonctionnalité par message |
| Coller des clés d'API dans le clavardage | Les clés se retrouvent dans l'historique de clavardage | Utilisez les secrets ou les paramètres d'environnement du générateur |
| Discuter avec un résultat brisé | Chaque correction s'ajoute au bogue | Revenez en arrière, puis reformulez |
| Spécifier du code que vous ne comprenez pas | Impose un mauvais choix | Décrivez le comportement souhaité |
| Demander une « sécurité de niveau entreprise » | Ne veut rien dire de précis | Énumérez les vraies règles : qui peut voir quoi |
Sur les clés d'API : si vous avez besoin d'un service de paiement ou de courriel, mettez ses clés dans les secrets du projet plutôt que dans la requête. Voir ce que sont les variables d'environnement et les secrets si c'est nouveau pour vous.
Modèles de requêtes réutilisables
Adaptez-les en remplaçant les parties entre crochets.
Nouvelle application :
Construis une [type d'application] pour [qui]. Ils [parcours principal, étape par étape]. [Deuxième type d'utilisateur] se connecte pour [ce qu'il fait]. Conserve [données] dans une base de données. [Apparence]. Laisse de côté [choses pour plus tard].
Nouvelle fonctionnalité :
Ajoute [fonctionnalité] à la [page]. Quand [utilisateur] fait [action], [ce qui doit se passer]. Seul [qui] peut [faire cela]. Garde [éléments existants] tels quels.
Changement de design :
Sur la [page], change [élément précis] pour [changement précis]. Conserve [ce qu'il faut garder]. Vérifie que cela s'affiche bien sur un écran de la largeur d'un téléphone.
Bogue :
Sur [page], j'ai [étapes]. Je m'attendais à [attendu]. Au lieu de cela [réel, plus le texte exact de l'erreur]. Corrige-le et vérifie que le parcours fonctionne.
Question sans modification :
Ne modifie aucun code. Explique comment fonctionne [partie de l'application] et où [données] sont stockées.
Rédiger une spécification plus longue
Pour les projets plus importants, il peut être utile de rédiger d'abord un bref d'une page et de le coller comme requête d'ouverture : les utilisateurs, les parcours principaux, les données, les règles et ce qui est hors périmètre. Vous pouvez même demander à une IA de vous aider à le rédiger ; notre guide sur la rédaction d'un PRD avec l'IA explique comment faire. Limitez simplement la première demande de construction au parcours principal, et ajoutez le reste étape par étape.
Rédiger des requêtes dans Mythex
Tout ce qui précède fonctionne dans Mythex. Quelques précisions utiles :
- Modes Construire, Plan et Demander. Utilisez Plan pour les changements importants ou risqués et Demander lorsque vous voulez une explication sans modification.
- Points de contrôle. Après chaque changement réussi, Mythex enregistre un point de contrôle, et Revenir à ce point sur une réponse ramène le projet à cet état. Vous pouvez aussi modifier un message précédent et le renvoyer pour essayer une autre requête à partir de ce point.
- Carte des secrets. Lorsque l'agent a besoin d'une clé d'API, il la demande au moyen d'une carte dans le clavardage afin que la valeur soit enregistrée comme secret du projet plutôt qu'écrite dans votre message.
- Images. Joignez des captures d'écran ou des maquettes, et l'agent les examinera.
La documentation contient une courte page sur les requêtes efficaces et une autre sur itérer sans reconstruire. Si vous partez de zéro, comment construire une application avec l'IA présente un projet complet, et comment concevoir une application attrayante avec l'IA couvre les requêtes pour le raffinement visuel.
Questions
Combien de temps doit durer une requête pour un générateur d'applications IA ?
Pour la première version, un court paragraphe de quatre à huit phrases suffit généralement : qui utilise l'application, le parcours principal, les données conservées et qui peut voir quoi. Ensuite, des requêtes plus courtes qui demandent un seul changement à la fois fonctionnent mieux que les longues.
Dois-je indiquer à l'IA quel cadre de développement ou quel langage utiliser ?
Seulement si vous avez une raison, par exemple un développeur qui reprendra le code ou un service qui ne fonctionne qu'avec une pile technique précise. Sinon, décrivez le produit et laissez le générateur choisir des valeurs par défaut raisonnables.
Pourquoi l'IA modifie-t-elle sans cesse des éléments que je n'ai pas demandé de changer ?
Généralement parce que la requête était trop vague (« rends ça meilleur ») ou ne précisait pas ce qu'il fallait conserver. Nommez précisément ce qu'il faut changer, dites ce qui doit rester identique et demandez un seul changement par message.
Vaut-il mieux corriger un mauvais résultat avec d'autres requêtes ou recommencer ?
Si la dernière modification a tout empiré, revenez à la version précédente et reformulez plutôt que d'empiler les corrections. Ne créez un nouveau projet que si l'idée elle-même a changé.