Comment écrire des prompts pour les générateurs d'applications par IA (avec exemples avant et après)
Un bon prompt pour un générateur d'applications par 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 en place, demandez un changement précis par message, indiquez ce qui doit rester identique, et décrivez les problèmes sous la forme « J'ai fait X, j'attendais Y, j'ai obtenu Z ». Ces trois habitudes règlent la plupart des résultats décevants.
Le reste de ce guide détaille ces schémas, avec des exemples avant et après que vous pouvez adapter.
Pourquoi écrire un prompt pour un générateur d'applications diffère d'une discussion avec une IA
Quand vous posez une question à un assistant conversationnel, un prompt vague donne une réponse vague, et vous passez à autre chose. Quand vous écrivez un prompt pour un générateur d'applications par IA, la réponse est un programme en cours d'exécution. 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 que vous devrez ensuite accepter ou défaire.
L'objectif d'un prompt 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 processus et vos règles.
Quoi inclure dans un premier prompt
Avant d'écrire quoi que ce soit, répondez à ces questions. Chacune comble une lacune que l'IA comblerait autrement par une supposition.
| À 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 | « Clients de passage sur téléphone, et le gérant sur ordinateur portable » |
| Le parcours principal, étape par étape | Ce qui doit fonctionner en premier | « Choisir une prestation, choisir un créneau, saisir le nom et le téléphone, recevoir une confirmation » |
| Les données conservées | Deviennent la conception de la base de données | « Prestations, réservations, clients » |
| Qui peut voir ou modifier quoi | Détermine la connexion et les droits d'accès | « Seul le gérant voit toutes les réservations » |
| Style et ambiance, brièvement | Évite un style générique par défaut | « Sombre, sobre, boutons grands » |
| Ce qu'on laisse de côté pour l'instant | Garde la première version légère | « Pas de paiements ni d'avis pour le moment » |
La dernière ligne est sous-estimée. Dire ce que vous ne voulez pas empêche l'IA d'ajouter un blog, une page tarifs et une inscription à une newsletter que vous n'avez jamais demandés.
Avant et après : le premier prompt
Avant :
Fais-moi une application pour ma salle de sport.
Le générateur doit tout deviner : des adhérents ou du personnel ? Des cours ou du coaching individuel ? Des paiements ? Vous obtiendrez quelque chose qui ressemble à un site de salle de sport et ne fait rien de ce dont vous avez besoin.
Après :
Construis une application de réservation de cours pour un petit studio de yoga. Les adhérents voient les cours de la semaine (nom, professeur, horaire, places restantes), réservent une place et peuvent annuler jusqu'à deux heures avant. Les adhérents s'inscrivent avec un e-mail et un mot de passe. Le gérant du studio se connecte pour ajouter des cours, voir qui est inscrit et marquer les présences. Enregistre les cours, les adhérents et les réservations dans une base de données. Design clair et calme, bien adapté aux téléphones. Pas de paiement pour le moment.
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 la modification.
Après :
Quand le gérant clique sur une réservation, ouvre un panneau où il peut changer l'horaire ou l'annuler. Les modifications doivent apparaître immédiatement dans la liste.
Le premier prompt enferme l'IA dans une technique précise qui ne correspond peut-être pas à la façon dont l'application est construite. Le second décrit le résultat attendu et laisse l'IA choisir la bonne approche pour le code qu'elle a déjà écrit. Si vous êtes développeur et que vous avez une préférence forte, dites-la, mais associez-la au résultat attendu.
Soyez concret sur les règles
Les règles métier sont l'endroit où les applications construites par IA se trompent le plus souvent, car elles sont évidentes pour vous et invisibles pour l'IA. Énoncez-les explicitement.
- Limites : « Un adhérent peut avoir au maximum 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 liste d'attente à la place de Réserver. »
- Droits d'accès : « 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 omettre une signifie que l'application ne fera pas respecter la règle, ou inventera sa propre version.
Après la première version : un changement par message
Une fois quelque chose en cours d'exécution dans l'aperçu, passez de la description de l'ensemble du produit à des demandes de changements petits et vérifiables.
Avant :
Le design ne va pas, la réservation ne fonctionne pas bien et je veux une vue calendrier et des e-mails.
Après (en quatre messages distincts) :
- Quand je réserve la dernière place d'un cours, il affiche encore « 1 place restante ». Il doit afficher « Complet » et masquer le bouton Réserver.
- Ajoute une vue calendrier hebdomadaire sur la page du planning, une colonne par jour. Garde la vue liste actuelle comme option.
- Rends les cartes de cours plus compactes sur téléphone : marges réduites, nom du professeur sur la même ligne que l'horaire.
- Envoie à l'adhérent un e-mail de confirmation lors de la réservation.
Pourquoi cela fonctionne :
- Chaque changement est assez petit pour que l'IA le réussisse en une seule passe.
- Vous pouvez tester chacun avant de passer au suivant.
- Si l'un tourne mal, vous pouvez annuler cette seule étape sans perdre les autres.
Précisez ce qu'il faut conserver
Lorsque vous demandez un changement sur quelque chose qui fonctionne déjà, indiquez à 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 se cassent après une modification).
Refais la section d'accueil avec un titre plus grand et une photo à droite. Garde la navigation, les couleurs et tout ce qui se trouve sous cette section exactement tel quel.
La même logique s'applique aux données : « Ajoute un champ numéro de téléphone aux adhérents. Ne supprime ni ne renomme aucun champ existant. »
Utilisez des captures d'écran et le texte exact
Les expressions comme « la chose en haut » sont ambiguës. La plupart des générateurs d'applications par 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 au lieu de le reformuler.
- Citez exactement les libellés affichés : « le bouton Enregistrer les modifications de la page Paramètres ».
Pour les bugs, utilisez cette forme :
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. À la place, rien ne s'est passé et la réservation est toujours là après un rechargement. Corrige-le et vérifie que l'annulation fonctionne.
Notre guide sur comment déboguer une application construite par IA approfondit ce point.
Planifier d'abord pour les gros 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, modifier 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 un point, corriger un paragraphe coûte bien moins cher que corriger une fonctionnalité déjà terminée. De nombreux générateurs ont un mode dédié à cet usage ; sur Mythex, c'est le mode Plan, aux côtés de Build et Ask.
À éviter
| À éviter | Pourquoi | À la place |
|---|---|---|
| « Rends-le meilleur » / « Fais-le ressortir » | Aucune cible, donc l'IA change les choses au hasard | Nommez le changement : « plus d'espace entre les sections, titres plus grands » |
| Un énorme prompt avec dix fonctionnalités | Les erreurs s'accumulent ; difficile à tester | Une fonctionnalité par message |
| Coller des clés d'API dans le chat | Les clés finissent dans l'historique du chat | Utilisez les secrets ou les paramètres d'environnement du générateur |
| Discuter avec un résultat cassé | Chaque correctif s'empile sur le bug | Revenez en arrière, puis reformulez |
| Spécifier du code que vous ne comprenez pas | Impose une solution mal adaptée | Décrivez le comportement souhaité |
| Demander une « sécurité de niveau entreprise » | Ne veut rien dire de précis | Listez les règles réelles : qui peut voir quoi |
Concernant les clés d'API : si vous avez besoin d'un service de paiement ou d'e-mail, placez ses clés dans les secrets du projet plutôt que dans le prompt. Voir ce que sont les variables d'environnement et les secrets si le sujet vous est nouveau.
Modèles de prompts 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]. Enregistre [données] dans une base de données. [Style et ambiance]. Laisse de côté [ce qui est pour plus tard].
Nouvelle fonctionnalité :
Ajoute [fonctionnalité] à la page [page]. Quand [utilisateur] fait [action], [ce qui doit se passer]. Seul [qui] peut [faire quoi]. Garde [éléments existants] tels quels.
Modification de design :
Sur la page [page], remplace [élément précis] par [changement précis]. Conserve [ce qu'il faut garder]. Vérifie que l'affichage est correct sur un écran de largeur téléphone.
Bug :
Sur [page], j'ai [étapes]. Je m'attendais à [attendu]. À la place [réel, avec 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 brief d'une page et de le coller comme premier prompt : 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, puis ajoutez le reste étape par étape.
Prompter dans Mythex
Tout ce qui précède fonctionne dans Mythex. Quelques précisions utiles :
- Modes Build, Plan et Ask. Utilisez Plan pour les changements importants ou risqués, et Ask lorsque vous voulez une explication sans modification.
- Points de contrôle. Après chaque modification réussie, Mythex enregistre un point de contrôle, et Revenir à ce point sur une réponse restaure le projet. Vous pouvez aussi modifier un message précédent et le renvoyer pour essayer un autre prompt à partir de ce point.
- Carte des secrets. Lorsque l'agent a besoin d'une clé d'API, il la demande via une carte dans le chat, afin que la valeur soit enregistrée comme secret du projet au lieu d'être é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 prompts efficaces et une autre sur itérer sans tout reconstruire. Si vous partez de zéro, comment créer une application avec l'IA présente un projet complet, et comment concevoir une application soignée avec l'IA propose des prompts pour le rendu visuel.
Questions
Quelle doit être la longueur d'un prompt pour un générateur d'applications par IA ?
Pour la première version, un paragraphe court 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 prompts plus courts, qui demandent un seul changement à la fois, fonctionnent mieux que les longs.
Dois-je indiquer à l'IA quel framework 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 certaine pile technique. 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 ne lui ai pas demandé de changer ?
En général parce que le prompt était trop vague (« rends-le meilleur ») ou ne précisait pas ce qu'il fallait conserver. Nommez précisément l'élément à modifier, indiquez ce qui doit rester identique et demandez un seul changement par message.
Vaut-il mieux corriger un mauvais résultat avec d'autres prompts ou recommencer ?
Si la dernière modification a aggravé les choses, revenez à la version précédente et reformulez, plutôt que d'empiler des correctifs. Ne démarrez un nouveau projet que si l'idée elle-même a changé.