Bêta publique de l’API Agents d’OpenAI : critères d’exploitation et de sécurité à vérifier avant d’ajouter un agent pilotant le navigateur

Quand les tâches répétitives se bloquent sur une « interface web »

Parmi les tâches quotidiennes des équipes d’exploitation, beaucoup ne se terminent pas proprement via une API. Il faut vérifier un état dans une console interne, modifier un paramètre dans l’écran d’un SaaS externe, puis consigner le résultat dans un ticket. L’automatisation par script s’arrête souvent sur la connexion, l’emplacement d’un bouton, une approbation d’autorisation ou un écran d’exception. L’API Agents, annoncée par OpenAI le 10 septembre 2026, vise précisément ce point. Selon l’annonce, les développeurs peuvent utiliser une API en bêta publique où ils spécifient la tâche, le modèle, les outils et l’environnement, tandis qu’OpenAI prend en charge un harnais fondé sur Codex et l’exploitation des sessions[1].

À la date de référence, le 1er octobre 2026 en heure coréenne, lire cette annonce comme « un nouveau modèle de plus » ferait manquer l’essentiel. Le changement se situe davantage dans la couche d’exécution que dans le modèle. OpenAI explique que le harnais gère les exécutions longues, la gestion du contexte, l’usage des outils et la coordination de sous-agents[1]. À cela s’ajoute, dans le journal des changements du 29 septembre, l’intégration de computer use à l’API Agents : il y est indiqué que l’agent travaille dans un navigateur hébergé par OpenAI, tandis que l’approbation de l’accès aux sites web et la connexion sont traitées par l’application[2].

Contexte : des chaînes de prompts aux sessions d’exécution

Les implémentations d’agents existantes assemblent généralement elles-mêmes des chaînes de prompts, des appels de fonctions, des files d’attente, une logique de nouvelle tentative et un stockage d’état. Cela fonctionne à petite échelle, mais plus la tâche s’allonge, plus les questions deviennent difficiles : « jusqu’où est-on allé ? », « quel outil a été appelé ? », « comment reprendre après un échec ? ». OpenAI explique qu’avec l’API Agents, elle fournit aux développeurs un environnement d’exécution managé de la même famille de harnais que Codex[1].

Le libellé de l’annonce officielle est assez affirmatif, mais les affirmations de l’entreprise doivent être lues comme telles. Les citations de clients incluent des exemples d’amélioration des coûts, de la latence et du taux d’échec, mais il s’agit des résultats de workflows clients particuliers[1]. À l’inverse, l’article WebArena fournit un contexte d’évaluation indépendant montrant que les agents web restent en difficulté sur des tâches web longues proches du réel. Dans des environnements incluant commerce électronique, forums, développement collaboratif et sites de gestion de contenu, cet article rapporte que le meilleur agent fondé sur GPT-4 a atteint un taux de réussite de bout en bout de 14,41 %, contre 78,24 % pour les humains[4]. Il ne faut pas généraliser ces chiffres aux performances des produits OpenAI les plus récents, mais ils sont importants pour établir que l’automatisation d’interfaces web n’est pas aussi simple que dans une démonstration.

Changement clé : computer use inclut aussi l’UX d’approbation

L’ajout de computer use dans le journal des changements du 29 septembre est important en pratique. Le journal indique que l’agent peut accomplir des tâches dans un navigateur hébergé par OpenAI, et que l’approbation de l’accès aux sites web ainsi que la connexion sont traitées par l’application du développeur[2]. Autrement dit, activer une fonction de manipulation du navigateur ne fait pas disparaître la question de la délégation d’autorisations par l’utilisateur. Il faut concevoir dans le produit l’approbation, le refus, la connexion, l’interruption et les journaux d’audit.

La disponibilité par région doit aussi être lue prudemment. L’annonce officielle dit que l’API Agents est disponible en bêta publique pour « tous les développeurs », mais il ne faut pas interpréter cette seule phrase comme garantissant la disponibilité pays par pays, les restrictions par organisation, la région de traitement des données ou la stabilité d’une fonctionnalité bêta[1]. À la date de référence, l’annonce officielle et le journal des changements vérifiés pour cet article confirment le statut de bêta publique et l’ajout de la fonctionnalité, mais ils ne remplacent pas les politiques régionales détaillées ni les conditions contractuelles[1][2]. Pour une entreprise opérant en Corée, par exemple, il faut vérifier séparément la console de compte, la revue juridique et les exigences d’exportation des données.

Ordre de vérification avant adoption : commencer par la bêta et les autorisations

La première vérification consiste à répartir les tâches en trois catégories : consultation en lecture seule, rédaction d’un brouillon suivie d’une approbation humaine, et modification effective d’un état. La consultation de documents web publics ou l’exploration d’écrans de QA peut commencer avec un risque relativement faible. En revanche, le changement d’un plan de paiement, l’octroi de droits utilisateur ou le basculement d’un déploiement ont un coût d’échec élevé ; il est donc difficile d’en faire dès le départ des cibles d’exécution entièrement automatique.

La deuxième vérification concerne les critères de réussite. Le fait qu’un navigateur ait accédé à une page et le fait que le travail soit terminé sont deux choses différentes. C’est aussi pour cette raison que WebArena évalue l’achèvement fonctionnel[4]. Lors de la création d’un jeu d’évaluation interne, il faut juger non pas la « réussite de navigation à l’écran », mais le fait que « l’état prévu a changé », que « des preuves subsistent » et que « l’action est réversible ».

La troisième vérification est le modèle de menace de sécurité. Le document d’OWASP sur les menaces liées à l’IA agentique explique que, avec la combinaison des LLM et de l’IA générative, les systèmes de type agent ont gagné en échelle et en capacité, et que les risques associés ont également augmenté[3]. Le profil d’IA générative du NIST explique lui aussi que les risques de l’IA générative peuvent varier aux niveaux du modèle, du système, du cas d’usage et de l’écosystème, et que les organisations doivent ajuster les méthodes de mesure et de gestion à leurs caractéristiques propres[5].

Comparaison des options : orchestration maison ou harnais managé ?

Ce qui importe dans ce tableau n’est pas de savoir « quelle option est la plus intelligente ». Il s’agit de placer différents degrés d’automatisation selon le coût d’échec et la vérifiabilité du travail. L’API Agents peut remplacer un harnais construit en interne, mais elle ne remplace pas la responsabilité de l’organisation.

Limites : bêta, benchmarks et responsabilité de sécurité

Le statut de bêta publique signifie que les fonctionnalités peuvent changer rapidement. L’annonce d’OpenAI indique aussi que des améliorations itératives seront apportées pendant la bêta à partir des retours reçus[1]. Il est donc préférable de commencer par un pilote interne dont l’impact reste limité en cas d’échec, plutôt que de le connecter immédiatement à un processus critique.

Les évaluations indépendantes aident également à éviter l’excès de confiance. Les résultats de WebArena reposent sur des modèles antérieurs, mais ils montrent que, dans des tâches web complexes, les agents affichaient un écart important par rapport au niveau humain[4]. Les documents de l’OWASP et du NIST portent aussi un message commun : plus les agents disposent d’outils et d’autorisations, plus une conception de sécurité et de gouvernance devient nécessaire[3][5]. Il est plus sûr d’utiliser les cas clients publiés par l’entreprise comme des indices de potentiel, et les sources indépendantes comme des matériaux pour concevoir les modes d’échec et les points de contrôle.

À faire cette semaine

Commencez par sélectionner 20 tâches candidates et classez-les en lecture seule, rédaction de brouillon et modification d’état. Pour chacune, notez les conditions de réussite, les actions interdites, les preuves nécessaires et les points où un humain doit approuver. Ensuite, associez aux fonctionnalités en bêta publique uniquement des tâches de lecture seule ou de rédaction de brouillon, afin de construire un petit jeu d’évaluation.

Puis concevez d’abord les écrans d’approbation et les journaux. Comme computer use déplace le navigateur à la place de l’utilisateur, les questions « à quel site accède-t-on ? », « qui traite la connexion ? » et « où s’arrête-t-on avant un changement d’état ? » deviennent des exigences produit[2]. Enfin, si vous vérifiez vos critères internes à l’aune du modèle de menaces agentiques de l’OWASP et de la perspective de gestion des risques d’IA générative du NIST, vous aurez davantage de chances de passer d’une démonstration à une automatisation exploitable[3][5].