Plan de la formation
Ingénierie agentique : la formation pratique · Module 3: Planification et conception des tâches
Rédiger des briefs avec critères d’acceptation
Un brief, c’est un contrat. Voyez les six parties d’un brief qui fonctionne et comment écrire des critères d’acceptation que l’agent peut vérifier seul.
Leçon 10 / 24 · ⏱ 8 min
Au module 1, vous avez écrit un brief en quatre parties : objectif, contexte, une vérification « terminé quand » et une ligne « ne pas ». Ça marche pour les petites tâches. Pour tout ce qui est plus gros, c’est le « terminé quand » qui fait ou défait le résultat, et il mérite plus d’attention.
Un brief, c’est un contrat. Les critères d’acceptation sont les clauses qu’on peut vraiment faire respecter.
Anatomie d’un brief
Tous les briefs n’ont pas besoin des six parties au long. Une petite tâche peut s’en tirer avec une ligne par partie. Mais quand un résultat me déçoit, je peux presque toujours remonter à une partie manquante, souvent la 4 ou la 5.
Ce qui rend un critère vérifiable
Un bon critère d’acceptation, c’est quelque chose que vous ou l’agent pouvez vérifier sans demander à personne. Les meilleurs sont une commande avec un résultat attendu. Ensuite viennent les comportements observables. Les pires sont des adjectifs.
✕ Vague
- –L’export fonctionne bien
- –Le code est propre
- –Gère les cas limites
- –Assez rapide
✓ Vérifiable
- +GET /reports/export?format=csv retourne un CSV avec une ligne d’en-tête et une ligne par commande
- +Le linter et le vérificateur de types passent sans nouvel avertissement
- +Une plage de dates vide retourne un fichier avec l’en-tête seulement; une plage de plus de 366 jours retourne une 400
- +L’export de 10 000 commandes prend moins de 2 secondes dans le test de performance existant
Remarquez que la colonne de droite nomme les cas limites au lieu d’espérer que l’agent les devine. Les écrire, c’est aussi comme ça que je découvre que je n’avais pas décidé ce qui devait se passer.
Un brief complet
Objectif
Ajouter un export CSV au rapport des commandes pour que la finance
arrête de copier-coller à partir de l'écran.
Contexte
- Endpoint du rapport : src/api/reports/orders.ts
- Suivre la structure de l'export PDF existant : src/api/reports/pdf.ts
- Un utilitaire CSV existe déjà : src/lib/csv.ts
Contraintes
- Aucune nouvelle dépendance
- Réutiliser la requête existante du rapport; ne pas en écrire une nouvelle
Critères d'acceptation
- GET /reports/orders/export?format=csv retourne du text/csv
- La ligne d'en-tête reprend les colonnes affichées à l'écran, dans le même ordre
- Plage vide → fichier avec en-tête seulement; plage > 366 jours → 400 avec un message
- De nouveaux tests couvrent ces trois cas; toute la suite de tests passe
- Le linter et le vérificateur de types passent
Hors périmètre
- Le bouton dans l'UI (tâche séparée)
- Modifier l'export PDF
Compte rendu
- Fichiers modifiés, et toute décision prise qui n'est pas dans ce briefVérifiez vos acquis
🧠 Briefs et critères d’acceptation
Pointage: 0 / 4
1. Quel critère d’acceptation est le plus vérifiable?
2. Pourquoi inclure une section « hors périmètre »?
3. Vous n’arrivez pas à écrire un critère vérifiable pour une tâche. Qu’est-ce que ça veut dire, en général?
4. À quoi sert de demander à l’agent de signaler les décisions absentes du brief?
Avant de continuer
✅ À retenir
0 / 4 complété