Les dossiers de revue des agents d’IA sont la nouvelle réponse finale
L’article de lancement de Codex par OpenAI indique que Codex fournit des preuves vérifiables au moyen de citations de journaux de terminal et de sorties de tests, afin que les utilisateurs puissent retracer les étapes suivies pendant l’exécution d’une tâche.1 Cette phrase désigne le basculement produit. La réponse finale ne suffit plus.
Pour le travail d’agent, le dossier de revue devient la nouvelle réponse finale. Un agent sérieux devrait terminer par un ensemble structuré d’affirmations, de traces, d’approbations, de diffs, de tests, de vérifications de sources, de preuves de déploiement et de points non résolus. Une prose fluide peut résumer le travail. C’est le dossier qui crée la confiance.
TL;DR
Le travail des agents couvre désormais la planification, les appels d’outils, les modifications de fichiers, les approbations, les tests, les routes en production, les traductions et la validation humaine. La documentation cloud de Codex chez OpenAI décrit des tâches en arrière-plan dans des environnements cloud isolés, tandis que le SDK Agents expose le traçage des générations de modèle, des appels d’outils, des transferts, des garde-fous et des événements personnalisés.23 La documentation human-in-the-loop d’OpenAI met l’exécution en pause pour les décisions d’approbation, et les hooks Claude Code d’Anthropic exposent des événements de cycle de vie comme PreToolUse, PostToolUse, PermissionRequest et Stop.45
Tous ces éléments convergent vers le même artefact : un dossier de revue. Il transforme l’affirmation finale d’un agent en quelque chose qu’un humain peut inspecter, refuser, approuver ou transmettre à un autre relecteur.
Points clés
Pour les concepteurs d’agents : - Traitez la réponse finale comme une page de garde. Le dossier de revue doit porter les preuves. - Rattachez chaque affirmation importante à un fichier, une sortie de commande, un événement de trace, une source, une vérification de route, une décision d’approbation ou un point non résolu.
Pour les designers produit : - Concevez le dossier comme un objet facile à parcourir, pas comme un export de transcription. Groupez les preuves par décision utilisateur. - Intégrez l’état de la validation humaine dans le dossier. « Vérifié par machine » et « approuvé par un humain » sont deux statuts différents.
Pour les équipes qui adoptent des agents : - Exigez des dossiers de revue pour les publications publiques, les changements en production, les traductions, les changements sensibles pour la sécurité et le travail ayant un impact financier. - N’acceptez pas « terminé » si le dossier ne précise pas ce qui reste non vérifié.
Qu’est-ce qu’un dossier de revue pour agent d’IA ?
Un dossier de revue est un ensemble structuré de preuves pour le travail d’un agent.
Il répond à 7 questions :
| Question | Champ du dossier |
|---|---|
| Qu’a demandé l’utilisateur ? | Objectif et périmètre |
| Qu’a modifié l’agent ? | Fichiers, diffs, artefacts, état externe |
| Qu’a exécuté l’agent ? | Commandes, appels d’outils, arguments, états de sortie |
| Qu’a approuvé un humain ? | Décisions d’approbation et notes de risque |
| Qu’est-ce qui prouve le résultat ? | Tests, vérifications de sources, routes rendues, télémétrie, captures d’écran |
| Qu’est-ce qui demande encore du jugement ? | Tâches de revue, matrice de validation, affirmations non résolues |
| Que doit-il se passer ensuite ? | Fusionner, publier, refuser, réessayer ou escalader |
Le dossier peut prendre la forme de Markdown, de JSON, d’une ligne de base de données, d’un modèle de pull request ou d’un objet UI dédié. Le format compte moins que la structure. L’objet doit séparer les preuves de la narration.
Une réponse finale dit : « J’ai traduit l’article et je l’ai déployé. » Un dossier de revue indique quelles langues ont changé, quelle barrière de qualité a été franchie, quelles lignes D1 existent, quel commit a été déployé, quelle purge CDN a été exécutée, quelles routes en production renvoient l’article modifié et quelles revues par locuteur natif restent en attente. La deuxième version donne à l’humain une surface de décision.
Pourquoi les réponses finales ne fonctionnent-elles plus ?
Les réponses finales ne fonctionnent plus parce que les agents agissent désormais dans la durée.
Une réponse de chatbot peut être jugée dans l’espace même de la réponse. Un agent de code ou de publication produit un parcours : lire des fichiers, sélectionner des sources, appeler des outils, modifier du contenu, exécuter des tests, écrire des traductions, déployer, purger un cache et vérifier la production. Le paragraphe final ne fait que décrire ce parcours. Il ne prouve pas qu’il a eu lieu.
La documentation Codex d’OpenAI décrit des tâches cloud capables de lire, modifier et exécuter du code dans des environnements cloud isolés, y compris de nombreuses tâches en arrière-plan en parallèle.2 Le travail parallèle en arrière-plan creuse l’écart entre ce qui s’est passé et ce qu’une réponse finale peut contenir. Plus l’agent en fait, moins le résumé de transcription mérite d’être l’objet de preuve.
L’article d’OpenAI sur l’exécution sûre de Codex formule le même point opérationnel sous l’angle de la sécurité. Il décrit des contrôles pour l’isolation, les approbations, les politiques réseau, l’identité, la configuration gérée et la télémétrie native aux agents ; il mentionne aussi l’export de logs pour des événements comme les prompts, les décisions d’approbation, les résultats d’exécution d’outils, l’usage de MCP et les événements d’autorisation ou de refus réseau.6 Ce sont des ingrédients de dossier. Ils doivent vivre dans la surface de revue.
La réponse finale doit toujours exister. Elle doit se lire comme une synthèse exécutive. Le dossier de revue doit porter la piste d’audit.
Que doit contenir le dossier ?
Le dossier doit regrouper les preuves par décision, pas par ordre interne des événements.
| Section | Preuve minimale |
|---|---|
| Objectif | Demande utilisateur, critères d’acceptation, exclusions de périmètre |
| Résumé du travail | Fichiers modifiés, artefacts générés, état externe touché |
| Trace | Appels d’outils significatifs, sorties de commandes, échecs, nouvelles tentatives |
| Approbation | Actions risquées, décisions d’approbation, refus, reports |
| Vérification | Tests, vérifications de sources, routes rendues, contrôles de schéma, captures d’écran |
| Publication | Commit, état de déploiement, purge de cache, marqueurs modifiés visibles en production |
| Revue | État de validation humaine, état de revue par locuteur natif, points non résolus |
Cette structure garde le dossier lisible. Une trace brute peut contenir des centaines d’événements. Un dossier de revue ne devrait pas tous les déverser dans la vue principale. Il doit permettre d’ouvrir ou de lier la trace complète quand c’est nécessaire, tout en gardant la vue par défaut centrée sur les décisions.
Le niveau de preuve varie selon le domaine :
| Type de travail | Le dossier doit prouver |
|---|---|
| Changement de code | Diff, tests, appelants affectés, chemin de retour arrière |
| Article public | Sources, alignement affirmations-sources, métadonnées, schéma, route en production |
| Traduction | Cache de langue, barrière de qualité, ligne D1, route en production, état de revue par locuteur natif |
| Sécurité | Menace, atténuation, test, risque résiduel, registre d’approbation |
| Déploiement production | Commit, état de déploiement, fraîcheur du cache, marqueur modifié visible en production |
La règle reste constante : si un humain doit signer le travail, le dossier doit contenir les preuves qui rendent cette signature responsable.
Comment les traces et les approbations alimentent-elles le dossier ?
Les traces et les approbations fournissent l’ossature du dossier.
La documentation de traçage du SDK Agents d’OpenAI définit les traces et les spans autour d’une exécution d’agent, notamment les générations LLM, les appels d’outils, les transferts, les garde-fous et les événements personnalisés.3 Ces données indiquent au dossier ce qui s’est passé. La documentation human-in-the-loop d’OpenAI montre comment l’exécution peut se mettre en pause pour des approbations d’outils, renvoyer les approbations en attente sous forme d’interruptions, sérialiser l’état d’exécution et reprendre après décision.4 Ces données indiquent au dossier qui a autorisé l’action risquée.
Les hooks Claude Code d’Anthropic exposent une forme de cycle de vie comparable : des hooks peuvent s’exécuter avant les outils, après les outils, lors des demandes d’autorisation et quand Claude s’arrête.5 Ces événements comptent parce qu’ils permettent à un système d’agents de convertir le comportement en faits vérifiables en revue. Le dossier ne doit pas dépendre de la mémoire du modèle sur l’exécution. L’environnement d’exécution doit enregistrer les événements pertinents au moment où ils se produisent.
La distinction est importante :
| Achèvement faible | Achèvement par dossier |
|---|---|
| « Les tests passent. » | Commande, code de sortie, résumé de sortie, tests en échec le cas échéant |
| « Sources vérifiées. » | URL des sources, statut, alignement des affirmations, URL bloquées |
| « Déploiement réussi. » | Identifiant de déploiement, santé de l’environnement d’exécution, purge de cache, smoke test de route en production |
| « Traductions terminées. » | Liste des langues, résultat de la barrière de qualité, lignes D1, état de revue par locuteur natif |
| « J’ai approuvé la commande. » | Objet d’approbation, raison, niveau de risque, acteur, horodatage |
Le dossier supprime l’ambiguïté. L’agent peut toujours écrire un résumé concis, mais les preuves vivent hors de la prose.
Comment l’état de la revue humaine doit-il fonctionner ?
L’état de la revue humaine doit apparaître comme son propre champ, pas comme un adjectif.
Les barrières automatisées peuvent prouver la structure, la santé des routes, la présence du schéma, l’accessibilité des sources et de nombreux contrôles de parité. Elles ne peuvent pas prouver qu’un locuteur natif à l’aise dans la langue a relu un article localisé. Un dossier doit énoncer clairement les deux faits :
| Statut | Signification |
|---|---|
| Machine pass | Les barrières automatisées sont passées |
| Human pending | Une revue humaine requise n’a pas encore eu lieu |
| Human approved | Relecteur, date, langue ou périmètre, et décision enregistrés |
| Rejected | Le relecteur a trouvé un problème bloquant |
| Not required | Le flux de travail n’exige pas de validation humaine pour ce périmètre |
La même règle s’applique au-delà de la traduction. Une barrière de sécurité peut passer alors qu’une revue juridique reste en attente. Une suite de tests peut passer tandis que la revue produit refuse le comportement. Un déploiement peut réussir alors que le CDN sert encore du contenu obsolète. L’état de revue doit décrire la décision restante, pas décorer la confiance de l’agent.
Le AI Risk Management Framework du NIST présente la fiabilité comme un élément que les équipes intègrent à la conception, au développement, à l’utilisation et à l’évaluation des systèmes d’IA.7 Les dossiers de revue rendent ce cadre opérationnel. Ils transforment l’évaluation en artefact visible plutôt qu’en affirmation de réponse finale.
À quoi ressemble un dossier minimal ?
Commencez petit :
# Review Packet: <work item>
## Decision
Status: ready for review | blocked | approved | rejected
Owner: <human or team>
## Goal
- User request:
- Acceptance criteria:
- Scope exclusions:
## Changes
- Files:
- Artifacts:
- External state:
## Evidence
| Claim | Proof | Result |
|---|---|---|
| Tests ran | `<command>` output | pass/fail |
| Public route works | `<url>` smoke | pass/fail |
| Sources support claims | source list | pass/fail |
## Approvals
| Action | Risk | Decision | Notes |
|---|---|---|---|
## Remaining Gaps
- <unverified work>
Le dossier doit d’abord rester sobre. Les tableaux, liens et champs de statut courts fonctionnent mieux qu’un bel artefact qui cache la preuve. Une fois la structure solide, le design peut rendre le dossier plus facile à parcourir : sévérité, regroupements, filtres, traces repliées et actions suivantes explicites.
La décision produit importante : le dossier devient l’artefact que d’autres systèmes peuvent lire. Une pull request peut créer un lien vers lui. Une note de publication peut le résumer. Un relecteur natif peut le signer. Un futur agent peut reprendre à partir de lui.
En quoi cela change-t-il les interfaces d’agents ?
Les dossiers de revue relient les surfaces de supervision à la barrière de preuves.
La surface de supervision montre ce qui demande de l’attention pendant que l’agent travaille. La barrière de preuves arrête les achèvements faibles à la fin. Le dossier de revue conserve le résultat. Ensemble, ils créent une boucle :
- L’opérateur délègue un objectif.
- L’agent agit sous contrôle des approbations et des traces.
- Le système enregistre les preuves à mesure que les événements se produisent.
- L’agent résume le travail.
- Le dossier rattache chaque affirmation à une preuve.
- L’humain approuve, refuse ou renvoie le travail.
Cette boucle change aussi le standard d’écriture des agents. Une réponse finale ne doit pas prétendre être la preuve. Elle doit dire où se trouve la preuve, ce qui est passé et ce qui reste ouvert. Quand la tâche touche du contenu public, des données client, de l’argent, la sécurité, la production ou la traduction, le dossier doit survivre au chat.
Résumé rapide
Les dossiers de revue devraient remplacer les réponses finales comme artefact d’achèvement fiable pour le travail d’agent sérieux. OpenAI Codex pointe déjà vers des journaux de terminal vérifiables, des sorties de tests, des approbations, de la télémétrie et des traces de tâches cloud.12346 Le cycle de vie des hooks d’Anthropic montre la même forme d’environnement d’exécution depuis une autre pile d’agents.5 Le NIST fournit le cadre de confiance : l’évaluation relève de la conception, du développement, de l’utilisation et de l’évaluation des systèmes d’IA, pas seulement du comportement du modèle.7
Le geste pratique est simple : gardez la réponse finale courte, et rendez le dossier réel.
FAQ
Qu’est-ce qu’un dossier de revue pour le travail d’un agent d’IA ?
Un dossier de revue est un ensemble structuré de preuves qui consigne ce que l’agent devait faire, ce qui a changé, quelles commandes et quels outils ont été exécutés, quelles approbations ont eu lieu, quels contrôles sont passés et ce qui reste non vérifié. Il donne à un relecteur humain un objet de décision plutôt qu’une simple affirmation d’achèvement en prose.
Pourquoi une réponse finale ne suffit-elle pas ?
Une réponse finale résume le travail, mais ne prouve pas qu’il a eu lieu. Les tâches d’agent incluent désormais des appels d’outils, des modifications de fichiers, des tests, des déploiements, des traductions, des approbations et l’état du cache. Ces faits ont besoin de preuves attachées. Une réponse finale peut pointer vers le dossier ; le dossier doit porter la preuve.
Que doit d’abord inclure un dossier de revue ?
Commencez par l’objectif, les fichiers modifiés, les preuves de commandes et de tests, les vérifications de sources, les décisions d’approbation, la preuve de déploiement ou de route, et les points non résolus. Ajoutez les traces complètes, captures d’écran, validations par locuteur natif et notes de risque quand le travail touche des surfaces publiques, de production, de sécurité, financières ou ayant un impact client.
Chaque tâche d’agent a-t-elle besoin d’un dossier de revue ?
Non. Les tâches exploratoires à faible risque peuvent se terminer par un résumé normal. Les dossiers de revue comptent quand un humain doit signer, fusionner, publier, déployer, dépenser, approuver ou s’appuyer plus tard sur le résultat. Le dossier doit s’ajuster au niveau de risque.
Quel lien entre dossiers de revue et traces ?
Les traces enregistrent ce qui s’est passé pendant l’exécution d’un agent. Les dossiers de revue sélectionnent les événements de trace qui comptent pour une décision et les rattachent aux affirmations. La trace est l’enregistrement brut. Le dossier est l’objet de revue.
Références
-
OpenAI, « Présentation de Codex » OpenAI, 16 mai 2025. Source pour Codex comme agent d’ingénierie logicielle basé dans le cloud et pour l’affirmation selon laquelle Codex fournit une preuve vérifiable des actions au moyen de citations de journaux de terminal et de sorties de tests. ↩↩
-
OpenAI, « Codex cloud » OpenAI Developers. Source pour les tâches cloud Codex qui lisent, modifient et exécutent du code dans des conteneurs cloud isolés, y compris l’exécution de tâches en arrière-plan et en parallèle. ↩↩↩
-
OpenAI, « Traçage » OpenAI Agents SDK. Source pour le traçage intégré des exécutions d’agents, spans, générations LLM, appels d’outils, transferts, garde-fous et événements personnalisés. ↩↩↩
-
OpenAI, « Human-in-the-loop » OpenAI Agents SDK. Source pour les interruptions d’approbation, les approbations en attente, le
RunStatesérialisé et la reprise de l’exécution après les décisions d’approbation. ↩↩↩ -
Anthropic, « Référence des hooks » Claude Code Docs. Source pour les événements de cycle de vie Claude Code comme
PreToolUse,PostToolUse,PermissionRequestetStop. ↩↩↩ -
OpenAI, « Exécuter Codex en toute sécurité chez OpenAI » OpenAI, 8 mai 2026. Source pour les contrôles Codex décrits par OpenAI autour de l’isolation, des approbations, des politiques réseau, de l’identité, de la configuration gérée, de l’export de logs OpenTelemetry, des logs de conformité et de la télémétrie native aux agents. ↩↩
-
National Institute of Standards and Technology, « AI Risk Management Framework » NIST. Source pour l’intégration des considérations de fiabilité dans la conception, le développement, l’utilisation et l’évaluation des produits, services et systèmes d’IA. ↩↩