Bonnes pratiques · Portes de review

Bonnes pratiques des portes de review humaine pour Agents IA

Une interface de review n'est pas à elle seule une frontière de contrôle. L'Agent doit connaître le candidat décidé, l'autorité accordée par approved et la manière dont chaque autre résultat bloque ou réoriente l'exécution.

Mis à jour 3 août 2026Guide pratique

Rendre l'autorité demandée explicite

  1. nommer l'action bloquée
  2. montrer périmètre, preuves, risque, retour arrière et questions ouvertes
  3. identifier le relecteur visé
  4. fixer une attente réaliste et une voie d'escalade

Garder la publication actuelle stable

Publier un candidat au lieu de remplacer silencieusement la révision formelle courante. Les lecteurs conservent un document stable pendant l'examen de la modification.

ow publish ./plan.mdw --update <document_id> --review --no-open --timeout 900

Échouer fermé pour tout autre résultat

  1. changes requested : réviser et soumettre à nouveau
  2. rejected : arrêter le chemin proposé
  3. timeout : signaler l'absence de décision et rester bloqué
  4. erreur de transport ou serveur : préserver l'état courant et rester bloqué

Conserver la preuve d'approbation

Noter la version immuable approuvée à côté de la preuve d'exécution. Un candidat ultérieur n'hérite pas d'autorité simplement parce qu'il partage l'URL canonique.

FAQ

Questions fréquentes

Un Agent peut-il interpréter le silence comme une approbation ?

Non. Décision absente, timeout et erreur sont des non-approbations.

Une petite modification impose-t-elle une nouvelle review ?

Oui, si elle modifie sensiblement périmètre, risque, action, preuves ou autorité approuvée.

Utiliser le vrai workflow

Publiez ce que votre Agent crée.

Donnez à chaque rapport, document ou plan une page pensée pour ses lecteurs, d’où reviennent commentaires, décisions et révisions formelles.