Comment écrire des prompts pour les créateurs d'applications IA (avec exemples avant/après)

Regardez deux personnes utiliser le même créateur d'applications IA pendant une heure. L'une a une application fonctionnelle ; l'autre a un chantier et l'opinion que « le codage par IA est surcoté ». L'outil était identique. Les prompts, non.

Prompter un créateur d'applications est une compétence différente de prompter un chatbot. Vous ne posez pas des questions — vous donnez des ordres de travail à un agent qui prendra des dizaines de décisions en fonction de ce que vous avez dit et n'avez pas dit. Voici ce qui fonctionne vraiment, avec des exemples avant/après tout du long.

Le premier prompt : chargez les décisions en amont, sautez l'implémentation

Votre prompt d'ouverture pose la fondation du projet. L'agent comble chaque vide que vous laissez par une supposition, et si les bons agents supposent raisonnablement, chaque supposition est un pile ou face sur votre intention réelle.

Avant :

Fais-moi une application de fitness.

Après :

Crée un suivi d'entraînement pour haltérophiles. Données : les entraînements ont une date ; chaque entraînement a des entrées avec nom d'exercice, séries, répétitions et poids. Écrans : (1) le journal du jour avec saisie rapide, (2) l'historique groupé par semaine, (3) un graphique de progression par exercice. Un seul utilisateur, pas de connexion nécessaire. Design sombre et minimal.

La version « après » décide de l'audience, du modèle de données, des écrans, du périmètre d'authentification et de la direction visuelle — les cinq décisions coûteuses à changer plus tard. Notez ce qu'elle n'inclut pas : pas de stack technique, pas de choix de base de données, pas de bibliothèques de composants. Une bonne plateforme fait ces choix mieux qu'un prompt ne le peut, et encombrer votre brief de termes techniques à moitié compris nuit activement (« utilise MongoDB » quand la plateforme est bâtie autour de Postgres ne crée que des frictions).

Une structure qui fonctionne de manière constante :

1. Ce que c'est, en une phrase, avec l'audience.
2. Les données, en substantifs et champs simples.
3. Les écrans, numérotés.
4. Les exclusions explicites — « pas de connexion », « pas de paiements ». Les exclusions empêchent le périmètre que l'agent inventerait autrement par serviabilité.

Les prompts d'itération : un changement, ancré à un endroit

Après la première construction, vos prompts changent de nature : de l'architecture à la chirurgie. Deux règles font l'essentiel du travail.

Un changement par message. Les demandes groupées échouent en bloc — quand l'un des cinq changements tombe à côté, vous devez re-prompter en contournant les quatre autres.

Ancrez chaque changement à un emplacement.

Avant :

Les dates ont l'air fausses.

Après :

Sur la page d'historique, les en-têtes de semaine affichent « Semaine 32 ». Affiche plutôt une plage de dates, comme « 4 août – 10 août ».

Nommez l'écran, citez le texte fautif, décrivez le texte attendu. L'agent trouve l'endroit exact au lieu de chercher — moins de suppositions erronées, moins de crédits.

Décrivez des résultats, pas des implémentations

Vous serez tenté de parler comme un développeur. Résistez, sauf si vous en êtes un.

Avant :

Ajoute un useEffect qui refetch au montage et mémoïse le rendu de la liste.

Après :

Quand je reviens sur le tableau de bord après avoir ajouté une dépense, le total affiche encore l'ancien montant jusqu'à ce que je rafraîchisse. Il devrait être à jour.

La première version engage l'agent sur votre diagnostic, qui peut être faux. La seconde lui donne le défaut réel — la chose dont vous êtes sûr — et le laisse trouver la cause. Décrivez les symptômes avec l'assurance d'un utilisateur ; laissez les diagnostics à ce qui peut lire le code.

Utilisez des références — elles battent les adjectifs

« Moderne et épuré » ne veut rien dire ; tous les designs depuis 2010 le revendiquent. Les références transportent des ordres de grandeur d'information en plus :

Fais que la section tarifs ressemble à la page de tarifs de Linear : beaucoup d'espace blanc, des bordures fines, une seule couleur d'accent.

Mieux encore, joignez une capture d'écran — d'une application que vous aimez, d'un croquis à la main, de la mise en page cassée que vous décrivez. Les plateformes qui acceptent les pièces jointes image (Massvai le fait) lèvent l'ambiguïté visuelle bien plus vite avec une image qu'avec de la prose. Une capture d'écran du bug avec une légende d'une ligne est le format de prompt à la plus haute valeur qui existe.

Quand ça dérape : arrêtez de creuser

L'erreur de prompt la plus coûteuse n'est pas un mauvais prompt — c'est la quatrième tentative consécutive de rafistoler une direction fondamentalement mauvaise.

Si deux tentatives du même correctif n'ont pas fonctionné, changez de stratégie :

• Revenez en arrière. Restaurez le point de sauvegarde d'avant le chantier (Massvai capture chaque génération) et réabordez avec une description différente. Reculer donne l'impression d'une perte ; c'est généralement le chemin le plus rapide vers l'avant.
• Prenez du recul. Au lieu de redécrire le correctif, décrivez l'objectif : « Oublie les instructions précédentes sur le menu déroulant de filtre. Voici ce que je veux permettre aux utilisateurs de faire : … » Les agents gèrent mieux des objectifs frais que des instructions de rafistolage accumulées.

Un aide-mémoire

Rien de tout cela n'est exotique. C'est la même clarté que vous devriez à un prestataire humain — sauf que ce prestataire lit attentivement, ne s'agace jamais des détails et commence le travail en quelques secondes. Donnez-lui un brief à la hauteur.