Votre premier bon prompt

Un prompt ne remplace pas une décision produit : il la rend visible pour qu'une autre personne ou une intelligence artificielle (IA) puisse agir dessus. La pratique recommandée par OpenAI et Google part d'instructions claires, d'un contexte pertinent, d'exemples lorsqu'ils apportent un motif, et de cycles de relecture. Vous allez appliquer ce plan à un formulaire de création de tâches.

Le cas est petit à dessein. Le formulaire a besoin d'un titre, d'un responsable, d'une échéance et d'une priorité ; il doit refuser les données incomplètes et confirmer l'enregistrement. Ce périmètre permet d'observer si chaque instruction change un comportement concret.

Transformez l'idée en tâche vérifiable

« Fais un gestionnaire de tâches » décrit un produit, mais ne définit pas le prochain changement. Une tâche vérifiable indique ce qui doit apparaître, ce qu'une personne peut faire et comment vous saurez que cela fonctionne. Dans notre cas, le premier objectif est de remplir un formulaire et d'enregistrer une tâche valide.

Formulez la demande avec un verbe et un résultat observable. Par exemple : « Crée le formulaire d'enregistrement d'une tâche avec titre, responsable, échéance et priorité ; à l'envoi, ajoute la tâche à la liste ». Cette phrase a encore besoin de contexte et de validation, mais elle empêche déjà l'IA d'inventer un tableau de bord, un calendrier ou un système de permissions.

Si vous voulez apprendre le cycle complet autour de cette demande, voyez qu'est-ce que le vibe coding. Le prompt lance une itération ; la relecture, les tests et la décision d'accepter le changement restent les vôtres.

N'apportez que le contexte qui change la solution

Un contexte utile réduit les décisions cachées. Nommez le framework s'il existe déjà, les composants à réutiliser, la langue de l'interface et l'endroit où l'état est conservé. Indiquez aussi quels fichiers ou quelles zones ne doivent pas changer.

Pour le formulaire de tâches, le contexte pourrait préciser que l'application possède déjà une liste et un composant bouton, que les textes sont en français et que l'état reste en mémoire. Inutile d'expliquer toute l'histoire du projet. Incluez l'information qui changerait l'implémentation ou la façon de la vérifier.

Quand vous ne connaissez pas la stack, dites-le directement. Demandez d'abord une courte proposition avec ses conséquences et validez-la avant d'autoriser des changements. Cette pause évite qu'un choix technique accidentel devienne une dépendance difficile à retirer.

Décrivez le résultat avant de demander du code

La sortie attendue comprend structure et comportement. Dans l'exemple, il vous faut quatre champs étiquetés, un bouton d'envoi, des erreurs près du champ concerné et une confirmation après l'enregistrement. Vous pouvez aussi demander la liste des fichiers modifiés et les tests exécutés.

Un exemple concret aide quand la forme du résultat compte. Écrivez une tâche valide, comme « Préparer la démo, responsable Ana, échéance 20 juillet, priorité haute », et une entrée invalide avec un titre vide. Le modèle dispose alors d'un motif pour l'état correct et d'un autre pour l'erreur.

N'utilisez pas l'exemple à la place de la règle. Si vous ne montrez qu'une date valide, l'IA peut accepter n'importe quel texte ressemblant. Précisez aussi que la date doit être réelle et non antérieure au jour courant.

Fixez des critères d'acceptation observables

Des critères d'acceptation transforment « ça a l'air prêt » en une relecture reproductible. Pour ce formulaire, chaque critère doit être vérifiable dans l'interface ou par un test. Évitez les formules comme « que ce soit intuitif », car elles ne disent pas quel comportement doit changer.

Vous pouvez définir les résultats suivants. Chacun correspond à un test visible :

1. Titre, responsable et date sont obligatoires.
2. Une date passée affiche un message à côté du champ et n'enregistre pas la tâche.
3. Un envoi valide ajoute une seule tâche avec toutes ses valeurs.
4. Le formulaire n'est vidé qu'après un enregistrement réussi.
5. La navigation au clavier atteint champs, options et bouton dans un ordre logique.

Ces critères limitent aussi le périmètre. Si l'IA ajoute des filtres, une authentification ou une synchronisation distante, elle a travaillé hors de la tâche, même si le résultat paraît soigné.

Améliorez le résultat avec un retour précis

La première version peut échouer même avec un prompt clair. Reproduisez le problème et répondez avec trois informations : ce que vous avez fait, ce qui est arrivé et ce que vous attendiez. Pour le formulaire : « J'ai choisi hier comme date, l'envoi a été accepté et j'attendais une erreur à côté du champ ».

Ajoutez un test qui empêche la régression. Demandez de couvrir une date passée et une date future, de lancer la suite existante et d'afficher le résultat. Cette pratique transforme un retour en preuve et évite une correction visuelle qui laisse la logique intacte.

Ne mélangez pas plusieurs corrections sans rapport. Si vous voulez aussi changer les couleurs et ajouter des libellés, gardez ces tâches pour des itérations distinctes. Vous pourrez alors attribuer chaque résultat à une instruction et revenir en arrière seulement là où c'est nécessaire.

Reconnaissez les limites et les échecs du prompt

Un prompt détaillé ne garantit pas une solution correcte. Le modèle peut supposer un fuseau horaire, ignorer une convention du dépôt, inventer une API ou écrire un test qui ne confirme que sa propre implémentation. Lisez le code et exécutez le flux réel.

Les données sensibles demandent une autre couche de prudence. Ne collez ni identifiants, ni données personnelles, ni contenu privé « pour donner du contexte ». Si le travail exige un accès externe ou des actions irréversibles, définissez des permissions minimales et une validation humaine ; le guide des agents IA explique ce contrat.

La recommandation de découper les tâches et de donner un retour concret est une heuristique pratique, pas une loi universelle. Une migration coordonnée peut exiger un plan large, tandis qu'une correction locale tient dans une demande courte. Ajustez la profondeur au risque et gardez toujours un moyen indépendant de vérifier le résultat.

Relisez le prompt avant de l'envoyer

Utilisez cette liste comme porte d'entrée de la tâche. Chaque case doit correspondre à une phrase ou à un critère visible dans votre demande.

• L'objectif nomme un seul changement achevé.
• Le contexte ne contient que les données, fichiers et décisions pertinents.
• Le résultat attendu décrit les états valides et les états d'erreur.
• Les critères d'acceptation se vérifient sans interpréter des intentions.
• Le périmètre exclut les changements et actions que vous n'avez pas autorisés.
• La tâche contient un test ou un parcours pour valider le résultat.

Si vous ne pouvez pas cocher une case, corrigez le prompt avant de l'élargir. Dans le formulaire de tâches, l'objectif final n'est pas de recevoir beaucoup de code : c'est de pouvoir créer une tâche valide, en refuser une invalide et démontrer les deux comportements.