Une bonne consigne pour un agent IA dit à qui l'application s'adresse, quel problème elle résout et à quels cas concrets tu reconnais qu'elle fonctionne. Si tes premiers essais avec Claude Code ou Codex t'ont déçu, la cause tient souvent moins à l'outil qu'à une consigne qui laisse ces trois points dans le flou.
L'agent comble les trous avec des suppositions. Plus il y a de trous, plus il suppose, et plus le résultat s'éloigne de ce que tu avais en tête. Cet article montre comment construire une consigne, comment la découper en sous-étapes et à quoi cela ressemble avec l'exemple d'une liste de contacts.
Pourquoi une consigne courte donne rarement ce que tu veux
Un premier essai typique ressemble à ceci: «Fais-moi une app pour mes contacts.» L'agent livre quelque chose. Peut-être une liste avec des noms et des numéros de téléphone, peut-être un formulaire de vingt champs, peut-être une page de connexion que tu n'as jamais demandée. Techniquement, ce n'est pas faux. Ça ne correspond simplement pas à ton travail.
Le problème: toi, tu sais qui utilise l'app, combien de contacts il y a et ce qui doit se passer après un entretien. L'agent, lui, ne le sait pas. Il devine. Et comme tu n'as pas fixé à l'avance comment mesurer la réussite, il ne te reste qu'une impression: quelque chose ne va pas. Vient alors l'essai suivant, de nouveau vague, de nouveau deviné.
Une consigne avec un public clair, un problème clair et des cas vérifiables casse cette boucle. Tu peux confronter chaque résultat à tes cas et dire précisément ce qui manque.
Les trois éléments d'une bonne consigne
Public cible: pour qui est l'app?
Décris la personne qui travaille avec l'app et sa situation. «Pour une petite entreprise», c'est un début. Mieux: «Pour une personne à la vente dans une petite entreprise, qui gère des prospects venus de salons et de demandes, et qui veut savoir le lundi qui elle doit rappeler.» De cette phrase, l'agent peut déduire que l'utilisation doit rester simple, que les dates comptent et que personne n'a besoin d'une interface d'administration pour cent utilisateurs.
Problème: qu'est-ce qui doit s'améliorer?
Nomme le problème, pas la solution. «Je veux un tableau avec des filtres» décrit une solution. «Des relances passent à la trappe parce qu'elles sont éparpillées dans des notes et des e-mails» décrit le problème. Quand l'agent connaît le problème, il peut prendre des décisions sensées que tu n'as pas imposées explicitement. Et tu peux vérifier ensuite si la solution s'attaque vraiment au problème.
Cas d'acceptation: comment sais-tu que ça fonctionne?
Les cas d'acceptation sont des situations courtes et concrètes avec un résultat attendu. Une forme éprouvée: situation de départ, action, résultat attendu. Par exemple: «Il existe un contact avec une date de relance fixée à hier. Quand j'ouvre la liste, ce contact est marqué comme en retard.»
Ces cas ont deux avantages. L'agent comprend plus précisément ce que tu veux. Et tu disposes d'une liste de contrôle à parcourir après chaque modification, au lieu de te fier à une impression. Les cas d'acceptation peuvent ensuite être traduits en tests automatiques. Une commande vérifie alors que tout est encore juste.
Pense aussi aux cas d'erreur: que se passe-t-il si un champ obligatoire reste vide, si une adresse e-mail ne contient pas de @, si la liste est vide? Ce sont justement ces cas qu'on oublie au premier essai, et c'est justement là que naissent les erreurs qui te font perdre du temps plus tard.
Comment découper la consigne en sous-étapes
Même une bonne consigne est trop grande si elle décrit toute l'app d'un coup. L'agent produit alors beaucoup de code d'une traite, et si quelque chose cloche, tu ne sais pas où chercher. Mieux vaut diviser le travail en petites étapes, chacune vérifiable pour elle-même.
Voici comment procéder:
- Écris le but de l'app entière en deux ou trois phrases: public cible et problème.
- Rassemble tout ce que l'app doit savoir faire, sous forme de liste libre.
- Ordonne les points pour que chacun s'appuie sur le précédent. D'abord afficher, puis enregistrer, puis modifier, puis connecter.
- Formule pour chaque étape deux à quatre cas d'acceptation, dont au moins un cas d'erreur.
- Donne à l'agent une seule étape à la fois et vérifie les cas avant de continuer.
- Note ce que l'agent a apporté et ce que tu as modifié toi-même.
Le dernier point paraît secondaire. Il t'aide pourtant à expliquer plus tard comment ton app est née, et à attribuer plus vite les erreurs.
Une bonne étape est assez petite pour que tu puisses vérifier le résultat en quelques minutes. S'il te faut une demi-heure pour vérifier une étape, elle était trop grande.
Exemple: une consigne pour une liste de contacts
Voici à quoi pourrait ressembler une consigne pour le premier palier d'une app de contacts et de relances:
Public cible: une personne à la vente dans une petite entreprise. Elle gère
des prospects et veut voir qui elle doit contacter ensuite.
Problème: des relances passent à la trappe parce que les contacts et les
prochaines étapes sont notés à différents endroits.
Cette étape: une liste de contacts et une vue détaillée avec des données
d'exemple. Pas encore d'enregistrement, pas de modification, pas de connexion.
Cas d'acceptation:
1. Il y a cinq contacts d'exemple. Quand j'ouvre l'app,
je vois les cinq avec nom, entreprise et statut.
2. Quand je clique sur un contact, la vue détaillée s'ouvre
avec toutes les informations et la prochaine date de relance.
3. Quand je clique sur «Retour» dans la vue détaillée, je revois
la liste.
4. Il n'y a aucun contact. Quand j'ouvre l'app, je vois
le message «Aucun contact pour l'instant» au lieu d'une surface vide.
Remarque ce que la consigne exclut explicitement. «Pas encore d'enregistrement, pas de connexion» empêche l'agent d'ajouter des fonctions que tu ne pourrais de toute façon pas vérifier à cette étape.
Les étapes suivantes
C'est seulement quand les quatre cas sont remplis que vient la consigne suivante. L'ordre pourrait être celui-ci:
- Enregistrer les contacts et vérifier les saisies: un nouveau contact sans nom est refusé, avec un message compréhensible.
- Changement de statut: un contact passe de «nouveau» à «contacté», et la liste affiche immédiatement le nouveau statut.
- Filtres: quand je filtre sur «en retard», je ne vois que les contacts dont la date de relance est passée.
- Interface: quand le service ne répond pas ou signale une erreur, l'app affiche un message au lieu de planter.
Chacune de ces étapes reçoit à nouveau ses propres cas d'acceptation. L'app grandit ainsi par petits morceaux contrôlés.
Comment savoir si ta consigne ne suffit pas encore
Avant d'envoyer, passe ces questions en revue:
- Est-il écrit qui utilise l'app et dans quelle situation?
- Le problème est-il décrit, et pas seulement une fonction souhaitée?
- Y a-t-il au moins deux cas d'acceptation concrets avec un résultat attendu?
- Y a-t-il au moins un cas d'erreur, par exemple une saisie vide ou une liste vide?
- Est-il écrit ce qui ne doit explicitement pas être construit à cette étape?
- Peux-tu vérifier le résultat en quelques minutes?
Si une réponse est non, complète la consigne avant de l'envoyer. Cela prend quelques minutes et t'épargne plusieurs tours de retouches.
Et si le résultat ne convient toujours pas: confronte-le à tes cas d'acceptation. Dis à l'agent précisément quel cas n'est pas rempli et ce qui se passe à la place. «Le cas 3 échoue: après le clic sur Retour, la vue détaillée reste ouverte» est un retour avec lequel l'agent peut travailler. «Ça ne marche pas» ne l'est pas.
Comment le cours Vibe Coding Foundation entraîne cette méthode
Dans le cours Vibe Coding Foundation, tu construis justement cette app de contacts et de relances, étape par étape, avec Claude Code ou Codex. La formulation de la consigne y fait l'objet d'une mission à part entière: dans la Mission 1, tu décris à qui l'app s'adresse et ce qu'elle doit savoir faire. Le temps prévu est de deux heures. Découper une tâche en sous-étapes vérifiables et la décrire sous forme de cas d'acceptation est l'une des quatre compétences que le programme atteste.
Les missions suivantes s'appuient sur cette base: la liste de contacts avec vue détaillée, la vérification des saisies avec changements de statut et filtres, une interface simulée avec réponses vides, erreurs et temps d'attente. Chaque mission a un objectif, des critères sous forme de tests et des indices en trois niveaux si tu bloques. Sur ton ordinateur, une commande vérifie les critères, ce qui te montre vite si ta consigne a mené au résultat voulu. En parallèle, tu tiens un journal IA où tu notes ce que l'IA a apporté et ce que tu as modifié toi-même.
Toutes les missions et leurs objectifs figurent dans l'aperçu du cours (en allemand). Si tu veux voir à quoi ressemble le début: la Mission 0 pour installer les outils est en libre accès (en allemand). Le déroulement général du cours est expliqué dans la section Déroulement de la page d'accueil. À la fin, il y a un examen de projet écrit. La grille d'évaluation de l'examen montre comment il est noté.