Comment briefer un agent IA pour qu'il fasse un travail utile : objectif, entrées, contraintes, définition de terminé, relecture
Un brief d'agent IA a cinq parties : objectif, entrées, contraintes, définition de terminé et relecture. Modèle, exemple réel et les erreurs les plus fréquentes.
Sur cette page
Un brief utile pour un agent IA comporte cinq parties : l'objectif en une phrase, les entrées qu'il peut utiliser, les contraintes qu'il ne doit pas franchir, une définition de terminé qu'il peut vérifier lui-même, et une personne nommée qui relit le résultat avant que quoi que ce soit ne parte. Retirez l'une des cinq et vous obtenez un résultat assuré, plausible et faux d'une façon que personne ne remarque avant plus tard. Le brief prend dix minutes à écrire et épargne des heures de reprise.
Cet article est le modèle que nous utilisons chez Atrix pour chaque exécution de notre propre agent et pour les agents de code que pilotent nos ingénieurs, avec un exemple réel et les modes de défaillance rencontrés.
Pourquoi les agents sans brief produisent un mauvais résultat
Un agent est une boucle : lire la tâche, choisir un outil, agir, lire le résultat, recommencer jusqu'à décider que c'est terminé. Chacune de ces décisions se prend contre le texte que vous lui avez donné. Si le texte ne dit pas à quoi ressemble « terminé », l'agent le décide seul, et il le décide tôt, parce que s'arrêter coûte moins cher que continuer. Si le texte ne dit pas ce qu'il ne peut pas toucher, il touche ce qui est le plus proche.
Mi-2026, le consensus des praticiens a convergé vers le même point par plusieurs chemins : les équipes qui tirent de la valeur des agents les briefent comme un prestataire et relisent le résultat comme une pull request ; les équipes qui tapent une phrase dans un chat et acceptent ce qui revient reçoivent un flot de travail plausible à refaire. L'outillage s'est amélioré ; le besoin d'un brief n'a pas disparu. Il a plutôt augmenté, parce que les agents tournent maintenant plus longtemps et touchent à plus de choses.
Un brief n'est pas une astuce de prompt. C'est le document que vous écririez pour une nouvelle recrue qui ferait la tâche son premier jour, raccourci parce que l'agent n'a pas besoin du contexte social.
Les cinq parties d'un brief
| Partie | Ce à quoi elle répond | Test en une ligne |
|---|---|---|
| Objectif | Quel résultat, pour qui, pourquoi maintenant | Un inconnu saurait-il quand c'est atteint ? |
| Entrées | Ce qu'il peut lire et sur quoi s'appuyer | Chaque source est-elle nommée, avec son emplacement ? |
| Contraintes | Ce qu'il ne doit ni faire ni changer | Une violation serait-elle évidente à la relecture ? |
| Définition de terminé | Ce que contient et respecte le livrable | L'agent peut-il vérifier chaque point lui-même ? |
| Relecture | Qui regarde quoi avant que quoi que ce soit ne parte | Une personne est-elle nommée, pas un rôle ? |
Objectif : une phrase, avec le résultat et non l'activité
« Écrire un document d'exigences pour les rappels de réservation » est une activité. « Produire les exigences des rappels de réservation pour que l'ingénierie puisse les estimer à la planification de jeudi » est un résultat avec un lecteur et une échéance. La seconde version dit à l'agent quel niveau de détail compte et qui jugera.
Entrées : nommer les sources, et dire laquelle l'emporte
Listez les documents, tickets, pages et données que l'agent peut utiliser, où chacun se trouve, et quoi faire quand ils se contredisent. « Le PRD dans /pages/booking-reminders est la référence ; le fil Slack n'est que du contexte ; en cas de conflit, le PRD l'emporte et signale le conflit. » Sans cela, l'agent mélange les sources et perd le fil.
Contraintes : ce qu'il ne faut pas toucher, ce qu'il ne faut pas supposer
Trois types comptent. Le périmètre : « ne propose pas de changements à la synchronisation d'agenda ». Les faits : « n'invente pas de noms de clients, de prix ni de dates ; écris “inconnu” ». Les actions : « lecture seule ; ne crée pas de tickets et ne publie pas de mises à jour ». La dernière correspond directement aux périmètres que vous accordez à l'agent, raison pour laquelle brief et permissions devraient s'écrire ensemble.
Définition de terminé : une liste que l'agent peut dérouler seul
Pas « un bon document », mais « un document avec des sections objectif, user stories, non-objectifs, questions ouvertes ; chaque user story a des critères d'acceptation ; aucune section vide ; moins de 1 200 mots ». L'agent vérifiera ces points avant de s'arrêter, et votre relecteur vérifie la même liste : vous regardez tous les deux la même chose.
Relecture : une personne nommée et un artefact nommé
« Moeid relit la page d'exigences avant la création de tout ticket. » Une relecture confiée à un rôle (« le PM ») plutôt qu'à un nom est sautée. Une relecture sans artefact (« relire le travail ») devient un coup d'œil.
Un modèle de brief à copier
Objectif : <résultat, lecteur, échéance>
Entrées :
- <source 1, emplacement, rôle : référence | contexte>
- <source 2 ...>
En cas de conflit : <laquelle l'emporte ; signaler le conflit>
Contraintes :
- Périmètre : <ce qui est exclu>
- Faits : ne pas inventer <noms, chiffres, dates> ; écrire « inconnu »
- Actions : <lecture seule | peut créer X | ne peut pas Y>
Définition de terminé :
- [ ] <section ou livrable 1 présent>
- [ ] <chaque élément a ...>
- [ ] <limite de longueur ou de format>
- [ ] questions ouvertes listées, pas résolues en devinant
Relecture : <personne> relit <artefact> avant <action suivante>.
Restez sous 200 mots. Un brief long signale que la tâche en est deux.
Exemple réel : une exécution Develop dans Atrix
Notre propre agent IA prend un brief et renvoie trois choses d'une exécution Develop : un document d'exigences, un document d'architecture et un ensemble de tickets planifiés, le tout pour qu'une personne l'approuve avant que rien ne devienne du vrai travail. Une exécution consomme l'un des runs IA de l'offre (100 par mois en Builder, 500 en Studio) ; discuter avec l'agent n'en consomme pas. Le brief que nous lui avons donné la semaine dernière, légèrement édité :
Objectif : Exigences, architecture et tickets planifiés pour « rappels de
réservation » afin de planifier le prochain cycle vendredi.
Entrées :
- Page « Rappels de réservation : notes » (référence)
- Tickets étiquetés « rappels » dans le produit Agenda (contexte)
En cas de conflit, la page l'emporte ; lister le conflit dans les questions ouvertes.
Contraintes :
- Périmètre : courriel et in-app seulement ; pas de SMS ce cycle.
- Faits : ne pas inventer de taux de délivrabilité ni de citations clients.
- Actions : exécution de planification ; créer uniquement des tickets
planifiés, aucun changement de statut sur les tickets existants.
Définition de terminé :
- [ ] Exigences avec user stories et critères d'acceptation
- [ ] Architecture nommant les composants touchés et ceux non touchés
- [ ] Tickets planifiés assez petits pour une personne en un cycle,
chacun lié à l'exigence qu'il implémente
- [ ] Questions ouvertes listées
Relecture : Moeid approuve la page d'exigences, puis les tickets planifiés,
avant leur entrée dans le backlog.
Ce qui est revenu : onze tickets planifiés, deux questions ouvertes (dont un vrai conflit entre la page de notes et un vieux ticket), et un document d'architecture qui a correctement laissé la couche de synchronisation tranquille. L'audit d'exigences a ensuite comparé les tickets livrés à cette référence gelée et rapporté la couverture ; il vérifie les exigences contre le plan, pas le code, donc la partie « le document d'architecture est honnête » restait à vérifier par nous.
Là où l'agent a failli : il a dimensionné deux tickets trop gros, et il a résolu une question ouverte en devinant malgré la contrainte. Les deux ont été attrapés à la relecture, ce qui est précisément son rôle.
Les erreurs qui produisent un mauvais résultat
- Objectif écrit comme une activité. L'agent fait l'activité et s'arrête.
- Aucune référence nommée. Il mélange trois sources et le résultat ne correspond à aucune.
- « Utilise ton jugement » sur les faits. Il invente un chiffre. Dites que « inconnu » est acceptable.
- Définition de terminé dans la tête du relecteur. L'agent ne peut pas vérifier ce qu'on ne lui a pas dit.
- Relecture par rôle. Personne ne la porte ; ça part.
- Un brief pour deux tâches. Scindez. Deux exécutions courtes valent mieux qu'une longue.
- Écrire le brief après l'exécution pour justifier le résultat. Le brief est le contrat ; il vient en premier.
FAQ
Que doit contenir le brief d'un agent IA ?
Cinq choses : un objectif en une phrase avec le résultat et le lecteur, les entrées utilisables et laquelle l'emporte, les contraintes de périmètre, de faits et d'actions, une définition de terminé qu'il peut vérifier seul, et un relecteur nommé avec un artefact nommé. Moins de 200 mots.
En quoi briefer un agent diffère-t-il d'écrire à un chatbot ?
Un chatbot répond une fois et vous lisez. Un agent agit de nombreuses fois avant que vous ne voyiez quoi que ce soit, donc le brief doit couvrir ce qu'il peut toucher et quand s'arrêter, pas seulement quoi dire. Les contraintes et la définition de terminé comptent plus que la formulation.
Quel niveau de détail pour la définition de terminé ?
Assez pour que l'agent coche chaque point sans vous demander, et assez court pour que votre relecteur la vérifie vraiment. Cinq à huit lignes de liste, en général.
L'agent doit-il pouvoir résoudre les questions ouvertes ?
Non. Demandez-lui de les lister. Un agent qui résout l'ambiguïté en devinant produit un résultat qui a l'air fini et qui est faux dans les détails qui comptent le plus.
Qu'est-ce qu'une exécution d'agent ?
Une exécution d'un agent sur un brief, avec un début, une fin et un artefact à relire. Dans Atrix, une exécution Develop renvoie exigences, architecture et tickets planifiés ; voir l'entrée du glossaire sur les exécutions d'agent et la définition d'un agent IA.
Un bon brief supprime-t-il le besoin de relecture ?
Non. Un bon brief rend la relecture plus rapide, parce que le relecteur vérifie la définition de terminé au lieu de tout lire à froid. La relecture est ce qui attrape les deux ou trois choses que l'agent a de toute façon ratées.
Prochaine étape
Prenez la prochaine tâche que vous alliez confier à un agent et écrivez les cinq parties avant de la lancer. Si la définition de terminé est difficile à écrire, la tâche n'est pas encore prête pour un agent. Pour voir ce qu'une exécution briefée renvoie en pratique, la page de l'agent IA montre les exigences, l'architecture et les tickets planifiés qu'une exécution Develop produit.