Comment écrire une tâche pour un assistant IA dont vous pourrez vérifier le résultat ?
Demandez un seul changement, dites où il va et ce qui ne doit pas changer, donnez une vérification qui réussit ou échoue, et demandez un compte rendu.
Demandez un seul changement, assez petit pour l'essayer en quelques minutes. Dites où il va, ce qui doit rester tel quel, comment vérifier qu'il fonctionne et ce que vous voulez entendre en retour. Une tâche écrite ainsi revient sous une forme que vous pouvez juger : une courte liste de fichiers modifiés, une vérification qui a réussi ou échoué, et un jeu auquel vous pouvez jouer pour le confirmer. Une tâche vague revient sous la forme d'un grand changement qui « a l'air fini », et toute la vérification vous reste.
Qu'est-ce qui rend une tâche vérifiable ?
Cinq parties. La plupart des tâches ont besoin des cinq, et chacune tient en une ou deux phrases.
| Partie | Ce qu'il faut écrire | Pourquoi cela aide à vérifier |
|---|---|---|
| 1. Le changement | Une chose que le jeu doit faire autrement | Vous voyez s'il a eu lieu |
| 2. Où | Le fichier, l'écran ou la fonction concernés | Le changement reste à un seul endroit |
| 3. Ce qui ne doit pas changer | Commandes, sauvegardes, autres écrans, bibliothèques | Tout ce qui sort de la liste se remarque |
| 4. La vérification | Un test, une commande ou des étapes à jouer | Elle donne réussi ou échoué, pas une impression |
| 5. Le compte rendu | Fichiers modifiés, vérifications lancées, ce qui n'a pas été testé | Vous lisez des preuves au lieu de refaire le travail |
Rien de tout cela n'est nouveau. Le guide de GitHub pour écrire des prompts pour Copilot demande une requête simple et précise, découpée en étapes, avec un ou deux exemples de ce que vous attendez. Les bonnes pratiques de Claude Code placent en premier une vérification que l'assistant peut lancer lui-même, car sans elle « a l'air fini » est le seul signal dont il dispose. Les deux pages se lisaient ainsi le 25 octobre 2026. La suite les applique à un petit jeu.
Quelle taille doit avoir une tâche ?
Assez petite pour décrire le changement en une phrase et l'essayer en quelques minutes. « Ajoute un écran de pause » est une tâche. « Ajoute un écran de pause, un menu de réglages et du son » en est trois, et quand quelque chose casse, vous ne saurez pas laquelle en est la cause.
Si une tâche demande une description plus longue, demandez d'abord un plan et gardez le code pour plus tard. La page de Claude Code propose exactement cela : laissez l'assistant lire le code et proposer les fichiers qui changeraient, lisez le plan vous-même, et seulement ensuite laissez-le écrire. Un plan qui touche la moitié du projet indique qu'il faut découper la tâche.
C'est la même règle que pour garder votre premier jeu petit : chaque fonctionnalité doit marcher avec toutes les autres, donc une tâche qui en ajoute trois multiplie la vérification.
À quoi ressemble une tâche vague à côté d'une tâche vérifiable ?
Voici une même demande pour un petit jeu de tir, écrite deux fois.
| Vague | Vérifiable |
|---|---|
| « Rends le jeu plus difficile. » | « Dans le code des vagues, rends chaque nouvelle vague 10 % plus rapide que la précédente, jusqu'à deux fois la vitesse de départ. Ne change pas la vitesse du joueur, les vies ni les commandes. » |
| « Corrige le bug du score. » | « Après un redémarrage, le score repart de l'ancien score au lieu de 0. Trouve où le redémarrage réinitialise le jeu, fais-lui aussi réinitialiser le score, et ajoute un test qui redémarre deux fois et attend 0. » |
| « Ajoute des commandes mobiles. » | « Sur les écrans tactiles, affiche des boutons gauche, droite et tir qui envoient les mêmes événements de touches que le clavier. Le jeu au clavier ne doit pas changer. Dis-moi quels écrans n'ont toujours pas de commande tactile. » |
La colonne de droite est plus longue, mais chaque ligne s'y vérifie. La troisième est proche de ce que nous avons fait en ajoutant des commandes tactiles à KittenGalaxy : les boutons envoient les événements de touches que le clavier enverrait, si bien que le jeu lui-même n'a pas eu à changer.
Comment dire à l'assistant de vérifier son travail ?
Donnez-lui quelque chose qui répond par oui ou par non.
- Un test que l'assistant peut lancer, avec les cas écrits en toutes lettres : « un redémarrage remet le score à 0 ».
- Une commande dont on peut lire le résultat : la compilation se termine, la page se charge sans erreur dans la console.
- Des étapes que vous jouerez vous-même, écrites avant le changement : « démarrer, perdre toutes les vies, appuyer sur redémarrer, le score affiche 0 ».
Demandez à l'assistant de lancer la vérification et de montrer le résultat, pas de dire qu'elle a réussi. Un résultat de test collé ou un journal de console sans erreur se lit en quelques secondes ; une phrase disant « tout fonctionne » ne prouve rien.
Certaines choses, seule une personne peut en juger : si un saut est agréable, ou si un niveau est juste. Pour celles-là, écrivez ce que vous allez regarder et jouez vous-même. Ne laissez pas le compte rendu de l'assistant en tenir lieu.
Que doit vous dire l'assistant quand il a fini ?
Demandez, dans la même tâche, un court compte rendu dans cet ordre :
- quels fichiers ont changé et, en une ligne chacun, pourquoi ;
- quelles vérifications il a lancées et ce qu'elles ont donné ;
- ce qu'il n'a pas testé, et pourquoi ;
- tout ce qu'il a changé sans que vous l'ayez demandé.
Le dernier point compte le plus. Un changement au-delà de la demande n'est pas toujours faux, mais c'est toujours quelque chose que vous n'aviez pas prévu de vérifier. Comparez la liste des fichiers avec la partie 3 de votre tâche : un fichier qui n'aurait pas dû changer est le premier endroit où regarder.
Que mettre dans un fichier du projet plutôt que dans chaque tâche ?
Tout ce que vous répéteriez sinon : comment lancer le jeu et les tests, les dossiers à ne pas toucher, les règles du code. La plupart des assistants lisent un tel fichier au début d'une session (Claude Code l'appelle CLAUDE.md). Gardez-le court ; la page de Claude Code prévient que dans un long fichier, les règles importantes se perdent.
Une règle y a sa place quand l'oublier casse le jeu. Les notes que nous tenons pour KittenGalaxy disent qu'à chaque ajout d'une touche, d'un écran ou d'un état du jeu, sa commande tactile est ajoutée dans le même changement, sinon les joueurs sur téléphone ne peuvent pas l'atteindre. Une tâche n'a alors plus qu'à dire ce qui est nouveau.
Que faire quand le résultat est faux ?
Revenir en arrière, puis redemander avec une meilleure tâche.
Sauvegardez une version qui marche avant chaque tâche, sous forme de commit dans la gestion de versions, pour qu'un mauvais changement s'annule en une étape. Quand une vérification échoue, vous pouvez demander une correction une ou deux fois. Si deux corrections échouent, la page de Claude Code conseille de commencer une nouvelle session avec une meilleure première demande plutôt que de corriger encore et encore, car les tentatives ratées restent dans la conversation. Annulez le changement, ajoutez à la tâche ce que vous avez appris, et renvoyez-la.
Questions fréquentes
Faut-il être programmeur pour écrire des tâches comme celles-ci ? Non. Les parties 1, 3 et 5 portent sur ce que fait le jeu, en mots simples. Pour la partie 2, demandez à l'assistant où va le changement avant de lui demander de le faire.
Une longue tâche vaut-elle mieux qu'une courte ? Pas en soi. Une longue tâche qui demande beaucoup de changements est plus difficile à vérifier qu'une courte qui en demande un seul. La longueur aide quand elle ajoute une vérification ou une limite.
Faut-il demander des tests pour un petit jeu ? Pour les règles qu'on peut énoncer exactement (le score, les vies, un minuteur, les sauvegardes), oui. Ils coûtent peu à relancer après chaque changement ultérieur. Les sensations et le plaisir demandent toujours de jouer.
Et si l'assistant me pose des questions ? Répondez-y dans la tâche avant qu'il commence à écrire. Une question posée tôt coûte moins qu'un mauvais changement.
Quand le jeu est-il prêt à être montré ? Quand un inconnu peut le lancer depuis un lien et le finir sans votre aide. Vous pouvez alors le proposer à HeapPlay, et les développeurs vérifiés peuvent enregistrer chaque nouvelle version et ce qui a changé.
ai-assistants workflow testing
Vous créez un jeu ? Proposez-le à HeapPlay et découvrez ce que reçoivent les développeurs.