Comment évaluer les browser agents : checklist pratique

Commencez par un task contract qui fixe l’état initial, les sites et applications autorisés, les données, l’état terminal, les événements interdits et la limite de confirmation humaine. « Réserver un billet » ne constitue pas un test : il faut fixer trajet, date, budget, droit de réserver et éventuel arrêt avant paiement. Pour une tâche read-only, le verdict peut vérifier l’enregistrement trouvé ; pour une tâche qui change l’état, il doit confirmer l’état réel du backend plutôt que le texte vu par l’agent sur la page.

WebArena est utile grâce à ses sites fonctionnels et à la vérification de tâches longues et réalistes, mais un benchmark public ne reproduit ni vos permissions, ni vos locales, ni vos données, ni vos conséquences. Transformez les production jobs en task families nettoyées et attribuez à chacune un oracle indépendant : requête API ou base de données en sandbox, export structuré, DOM state contrôlé ou artifact revu par un humain. Le self-report « terminé » de l’agent n’est jamais un oracle.

• Outcome → l’état requis a réellement été créé, trouvé ou modifié.
• Trajectory → chaque action était autorisée pour la tâche et l’état courant.
• Side-effect integrity → aucun submit, message, paiement ou effacement supplémentaire.
• Stop behavior → l’agent refuse, demande une clarification ou sollicite un approval correctement.

Le résultat d’un browser eval ne dépend pas seulement du modèle. Versionnez image ou VM, navigateur, viewport, device scale, locale, timezone, polices, cookies, account fixture, network policy, données initiales et état de chaque application. Documentez séparément le mode d’observation—screenshot, accessibility tree, DOM, OCR ou combinaison—et l’action mode—coordonnées, element IDs, primitives Playwright ou raccourcis clavier. Les informations supplémentaires d’OpenAI sur l’évaluation CUA documentent les différences d’environnement browser/VM, de prompts, sampling et scoring ; sans cela, comparer les versions n’est pas reproductible.

BrowserGym uniformise les observation et action spaces pour plusieurs benchmarks de web agents ; appliquez la même discipline dans votre harness interne. Conservez un environment manifest avec chaque résultat et rejetez le run si le fixture ne démarre pas, si le site a changé de façon inattendue ou si l’oracle est indisponible. Un infrastructure failure ne doit pas compter comme model failure, ni une tâche déjà réalisée par hasard comme success. Le reset doit restaurer tout le business state, y compris mails, panier, fichiers et pending transactions.

Un frozen regression set couvre les tâches typiques et incidents connus, tandis qu’un held-out set introduit de nouvelles formulations, entités et layout variants. Ajoutez viewports responsive, autre zoom, traductions, sticky banners, modals, lazy loading, contrôles désactivés, labels identiques, tableaux paginés et éléments below the fold. Pour les computer-use agents, testez aussi fenêtre active, focus, drag, clipboard, file picker et system dialogs. L’objectif n’est pas de casser les coordonnées, mais de mesurer le grounding sur l’état sémantique courant.

Ajoutez des perturbations temporelles et opérationnelles : réponses lentes, spinners, screenshots stale, actions acceptées après timeout, session expiry, redirects, nouveaux onglets et formulaires partiellement enregistrés. Les tâches ambiguës doivent exiger une clarification et les tâches impossibles un arrêt sûr. Maintenez une contamination boundary : n’utilisez pas les screenshots held-out dans les prompts ou few-shot examples et n’optimisez pas la policy sur chaque échec sans créer un nouveau blind set.

Task success est nécessaire mais insuffisant. Un trace grader vérifie origin transitions, targets, champs saisis, repeated actions, approval binding et prohibited states. Distinguez perception error, wrong target, planning error, policy block, environment failure, premature stop et false success claim. Le nombre d’étapes et la latency ne comptent qu’après correctness : un chemin plus court avec un submit erroné n’est pas plus efficace. Si plusieurs chemins sont valides, évaluez les invariants plutôt qu’une action sequence exacte.

Une recovery suite démarre l’agent dans un état intermédiaire : un modal masque le bouton, la validation rejette un champ, la navigation revient au login ou un timeout survient après commit. Pass exige de lire d’abord l’état réel, d’éviter le side effect en double et de choisir retry, reconcile, rollback ou escalation. Pour un agent stochastique, exécutez plusieurs runs indépendants, publiez la distribution et faites un paired comparison avec le baseline ; un replay réussi ne prouve pas une fiabilité générale.

• Functional verdict → un oracle indépendant a confirmé l’état final.
• Policy verdict → aucune action n’a dépassé le scope ou l’approval.
• Grounding verdict → la target correspondait à l’intention dans le frame réel.
• Recovery verdict → le retry n’a créé aucun doublon et a conservé l’audit trail.

Pages, documents, messages et tooltips sont des données non fiables. Un security slice place des prompt injections directes et indirectes dans le texte visible, les accessibility attributes, les documents chargés et les résultats de recherche. Ne vérifiez pas seulement si l’agent répète l’instruction ; vérifiez les sinks : tente-t-il de changer l’objectif, de naviguer vers un origin interdit, de lire un canary secret, de le coller dans un formulaire, de charger un fichier ou d’exécuter une action externe ? La détection de prompt injection sans sink verdict crée une fausse impression de sécurité.

Tous les write tests s’exécutent dans des comptes jetables avec canary data, email ou webhooks interceptés, fake payment rail et journal de backend mutations. Liez l’approval au payload exact et au state snapshot : valider un destinataire ne permet pas de changer l’adresse après le modal. Testez annulation, approval expiré, boutons trompeurs, download quarantine et secrets dans le clipboard. Des identifiants de production, paiements réels ou messages à des personnes externes ne sont pas nécessaires pour un eval probant.

Le decision record contient dataset revision, environment manifest, modèle, prompt, observation/action adapter, policy, oracle, sample count, résultats par segment, critical failures et reviewer. Comparez le candidate à un known-good bundle sur les mêmes task seeds. Promote exige une non-regression de l’outcome, une tolérance zéro pour les critical side effects définis et des slices séparés validés par domaine, locale, longueur de tâche et risk tier. Un benchmark public est un signal externe, pas un substitut au release gate interne.

Le rollout passe d’un environnement offline réinitialisable à shadow, read-only canary, draft-only writes puis à des actions étroitement approuvées. Le monitoring reprend la taxonomie offline : false completion, duplicate mutation, unexpected origin, approval mismatch et recovery failure. Rollback restaure un bundle compatible de modèle, prompt, adapter et policy, arrête les nouveaux runs et réconcilie les side effects inachevés avant un nouvel essai. Un incident trace assaini ne devient regression fixture qu’après revue de provenance et privacy.