Agents web économiques avec Haiku 5.5 : la file de validation est le nouveau coût

Le 7 octobre, Anthropic a lancé Claude Haiku 5.5 en le positionnant d'emblée sur les tâches de navigation web. L'article de lancement le présente comme un choix idéal pour « les tâches sensibles au temps de réponse comme le support client en direct et l'utilisation d'un navigateur », la page produit met en avant le remplissage de formulaires, la saisie de données et le transfert d'informations entre applications, et cette même version a introduit en bêta les fonctionnalités de « computer use » et de navigation web dans les SDK Python et TypeScript d'Anthropic. Sur OSWorld 2.1, le benchmark d'utilisation de l'ordinateur cité par Anthropic, Haiku 5.5 atteint 72,4 % pour environ 0,61 $ par tentative avec l'effort maximal (« max effort »), et 53,3 % pour environ 0,13 $ avec l'effort moyen défini par défaut.

Ce chiffre mis en avant correspond à un score avec attribution partielle des points. En consultant la system card, on constate que ces mêmes essais affichent un taux de réussite stricte de 37,1 %. Ainsi, une équipe qui intègre Haiku 5.5 dans un flux de navigation web obtient une exécution qui ne coûte que quelques centimes, mais un résultat qui, la plupart du temps, n'est que partiellement achevé. L'exécution est devenue très bon marché, mais sa vérification ne l'est pas ; et pour une équipe déployant plusieurs agents, cela reporte le coût réel de l'automatisation du navigateur sur la personne chargée d'examiner les résultats.

En résumé

Sur le sous-ensemble hors ligne d'OSWorld 2.1 évalué par Anthropic, Haiku 5.5 obtient en moyenne 72,4 % en crédit partiel, mais ne valide intégralement que 37,1 % des tentatives ; Sonnet 5.5 et Opus 5.5 affichent le même écart de 34 à 35 points, à des tarifs bien plus élevés. Considérez chaque exécution dans le navigateur comme partiellement achevée tant qu'elle n'a pas été vérifiée : intégrez un critère d'acceptation strict dans la Tâche, demandez à l'Agent de s'arrêter avant toute action de soumission (« submit ») et d'indiquer ce qui est fait, non fait, ainsi que les preuves associées, puis laissez un humain autoriser l'étape finale via un commentaire mentionnant l'Agent avec un @. Investissez dans l'effort pour économiser du temps de révision : l'exécution est la composante la moins chère. Les agents explorent, exécutent, testent et rendent compte. Les humains fixent le cap, accordent les autorisations et valident le résultat.

Un crédit partiel ne veut pas dire terminé

Anthropic a testé OSWorld 2.1 sur 82 de ses 108 tâches en 1080p, avec jusqu'à 500 étapes par tentative, avec l'effort maximal (« max effort »), en calculant la moyenne sur cinq essais. L'entreprise a publié deux chiffres par modèle, et c'est le second qui concerne directement le réviseur.

D'abord, cet écart n'est pas un problème propre à Haiku. Chaque modèle de la famille affiche un décalage d'environ 35 points entre « la majorité des étapes ont été exécutées » et « la tâche est terminée », et même Opus 5.5 ne réussit pleinement qu'environ une fois sur deux. Une grande partie des tentatives de « computer use », telles qu'évaluées ici, s'achèvent à l'état partiellement terminé. Ensuite, Haiku 5.5 rend ce travail inachevé très peu coûteux à produire. Par réussite stricte, son coût représente environ un septième de celui de Sonnet 5.5, et par tentative, environ un neuvième.

Le travail partiellement achevé représente le scénario le plus dangereux pour l'automatisation de la navigation. Une exécution qui échoue purement et simplement ne laisse aucune trace. En revanche, une exécution qui transfère 31 fiches sur 40 dans le CRM, ou qui remplit le formulaire d'un fournisseur jusqu'au champ des taxes, laisse dans une application tierce un état qui paraît finalisé de loin. La personne chargée de le réviser doit alors identifier les neuf fiches manquantes, sans que rien à l'écran ne les signale.

Où se déplace le coût quand l'exécution ne coûte que quelques centimes

Un flux d'automatisation web économique modifie la ligne du budget qu'il convient de surveiller. À 0,13 $ par tentative, une centaine d'exécutions de remplissage de formulaires relève de l'épaisseur du trait sur la facture du modèle. En revanche, cent exécutions nécessitant chacune qu'un humain vérifie ce qui a été saisi peuvent mobiliser l'attention d'une personne pendant une journée entière. Le tarif de Haiku 5.5 est 90 % inférieur à celui de Haiku 4.5 pour les prompts allant jusqu'à 100 000 tokens ; celui du relecteur ne l'est pas.

Il existe également une particularité tarifaire. Haiku 5.5 est facturé 0,10 $ par million de tokens en entrée et 0,50 $ par million en sortie pour les prompts jusqu'à 100 000 tokens, puis 0,50 $ et 2,50 $ pour les prompts dépassant 100 000 tokens. Une longue session de navigation peut faire croître le prompt au-delà de ce palier, appliquant dès lors le tarif supérieur à chaque requête suivante. C'est une raison supplémentaire de limiter la portée des Tâches de navigation web : un formulaire, un lot de fiches, une Tâche.

Nos articles La revue humaine est le goulot d'étranglement et Jours de travail d'agents par jour ouvré humain ont déjà développé cet argument. Ce que change Haiku 5.5, c'est ce ratio : à 0,13 $ par exécution, son coût se remarque à peine, et les modèles bon marché peuvent coûter plus cher dès lors que l'on comptabilise la file d'attente de revue. Le seul levier disponible consiste donc à rendre chaque vérification plus rapide.

Revue des agents « computer use » : ce que la Tâche doit contenir

Une Tâche confiée à un agent de navigation web n'est facilement vérifiable que si la vérifier prend moins de temps que de refaire le travail. Cela repose sur trois éléments que l'Agent ne peut pas inventer après coup : un critère d'acceptation strict rédigé avant l'exécution, un rapport qui sépare ce qui est fait de ce qui ne l'est pas, et des preuves qu'un humain peut consulter sans rejouer l'ensemble de la session.

Dans Sharkly, la Tâche constitue déjà l'enregistrement partagé de référence. Elle contient la description, les commentaires, les pièces jointes et l'historique d'activité ; le compte-rendu de l'Agent destiné à l'équipe est enregistré sur la Tâche sous la forme d'un commentaire associé à l'exécution ; et le journal d'exécution consigne les appels d'outils ainsi que les événements du Runtime. L'architecture de révision repose donc sur deux piliers : la description de la Tâche définit ce que signifie « terminé », et les instructions de l'Agent précisent ce que le rapport doit contenir. Voici un point de départ pour les instructions d'un Agent de saisie sur navigateur :

Restate the acceptance check from the Task description before you start.
Work up to, but not including, any submit, send, publish, pay, or delete action.
Then stop and report, in this order:
  Done: every record or field you completed, by its identifier.
  Not done: everything you skipped or could not complete, and why.
  Check: the acceptance check, and whether your own count meets it.
  Evidence: the paths of the screenshots you saved in the task directory.
Leave the Task waiting for human review. Do not take the final action
until a person @ mentions you in a comment on this Task to release it.

Formulez le critère d'acceptation sous forme d'élément quantifiable : « 40 lignes dans le CRM, chacune avec une adresse e-mail valide », et non « importer le tableur ». La liste « Non fait » est précisément la partie que le crédit partiel dissimule ; nommer ce qui a été omis transforme une exécution à 72 % en une exécution à 72 % dont le reste est connu. Notre guide sur la revue du travail des agents à l'aide de preuves au niveau de la tâche détaille plus en profondeur les formats de rapport.

D'après la documentation sur les Agents de Sharkly, l'Agent utilise le modèle par défaut du Runtime ; pour en changer, spécifiez-en un dans les arguments personnalisés (« Custom arguments ») de l'Agent ou du Runtime (claude-haiku-5-5 pour Claude Code). Il n'existe pas de menu déroulant pour le modèle. La configuration est expliquée dans comment exécuter des agents Claude Haiku 5.5 dans Sharkly.

S'arrêter avant la soumission

Un résultat partiel est tout à fait acceptable pour un brouillon, mais inacceptable pour un formulaire définitivement validé. Isolez donc l'étape irréversible de l'exécution au lieu d'espérer que le modèle ne commette aucune erreur.

Ce schéma exploite des fonctionnalités déjà existantes dans Sharkly. L'Agent avance jusqu'à l'action finale, puis laisse la Tâche en attente de validation humaine, ce qui la fait apparaître dans la boîte de réception du réviseur. Ce dernier consulte le rapport et les captures d'écran, corrige ou rejette, puis mentionne l'Agent avec un @ dans un commentaire sur la Tâche pour autoriser l'action finale. Un simple commentaire ne relance pas l'Agent ; seule la mention ouvre ou poursuit sa conversation sur la Tâche, et sa réponse est consignée sous forme d'un nouveau commentaire rattaché à l'exécution. La soumission s'effectue au sein de la même Tâche, sous le même enregistrement, après validation formelle par un humain. Notre guide des points de validation aborde les autres situations où placer un tel arrêt.

Ce point de contrôle limite également l'autre risque lié à la navigation. Un agent web consulte des pages qu'il n'a pas écrites lui-même. La system card d'Anthropic indique que Haiku 5.5 résiste mieux aux injections de prompts que toute version antérieure de Haiku, égalant en grande partie ses modèles les plus avancés face à des attaquants adaptatifs dans des environnements de « computer use ». Il s'agit là d'un résultat sur benchmark et non d'une garantie absolue pour le portail de votre fournisseur, et une instruction injectée incapable d'atteindre le bouton de soumission sans un commentaire humain constitue un incident d'une gravité bien moindre. La délimitation côté hôte (un Computer dédié, des identifiants restreints par Agent grâce à ses variables d'environnement secrètes, une seule session de navigation à la fois) reste la même que celle présentée dans notre guide des garde-fous pour le computer use, et notre article sur l'injection de prompts et les garde-fous pour agents traite du reste.

Voici la règle de décision à appliquer pour ce type de flux. Utilisez un Agent de navigation Haiku 5.5 lorsque le résultat peut être validé à l'aide d'un décompte ou d'une liste en moins d'une minute, et que l'action finale est soit réversible, soit subordonnée à une mention dans un commentaire. Confiez plutôt le travail à un humain, ou à un modèle plus grand assorti du même point de contrôle, lorsque la vérification équivaut à refaire tout le travail ; car dans ce cas, un taux de réussite stricte de 37 % ne vous apporte rien d'autre qu'une seconde passe.

Payer pour l'effort, économiser sur la révision

Haiku 5.5 est le premier modèle Haiku d'Anthropic à intégrer un paramètre d'effort, configuré par défaut sur moyen (« medium »). Sur OSWorld, ajuster l'effort améliore considérablement le score de crédit partiel pour un surcoût dérisoire :

Passer de medium à max ajoute environ 0,49 $ par tentative et 19 points de crédit partiel. Si ces points écourtent ne serait-ce qu'un peu le temps de révision, max s'avère le réglage le plus économique pour toute Tâche de navigation vérifiée par un humain. La system card illustre le taux de réussite stricte par niveau d'effort sous forme de graphique mais n'en fournit le chiffre précis que pour le niveau max ; mesurez donc le taux de réussite stricte sur vos propres Tâches avant d'opter pour un niveau inférieur. L'effort se définit dans Claude Code sur le Computer : l'Agent ne propose ni sélecteur de modèle ni contrôle de profondeur de réflexion. Réservez l'exécution à moindre coût aux cas où personne ne lit le résultat, comme illustré dans Luna pour les quatre-vingts pour cent rébarbatifs ; un flux de navigation web n'en fait pas partie.

Toute tâche de navigation qui écrit dans les systèmes de tiers doit faire l'objet de sa propre Tâche plutôt que d'être intégrée dans une exécution plus vaste, car une personne doit obligatoirement la valider ; l'article Haiku 5.5 : sous-agent ou Agent autonome détaille cette règle générale.

Un agent de navigation plus économique entraîne davantage d'exécutions, et plus d'exécutions se traduit par plus de résultats partiellement terminés en attente de vérification humaine. Si vous faites déjà tourner plusieurs agents, Sharkly vous offre un espace centralisé pour gérer l'ensemble de leurs tâches et de leurs résultats.