Qu’est-ce qu’un agent IA en computer use ?

Un agent IA en computer use pilote un logiciel par son interface graphique : il lit l’écran, déplace le curseur, remplit les champs et clique, sans API côté application. Une intégration API appelle des fonctions documentées, qui renvoient une réponse structurée. Notre règle : l’API dès qu’elle couvre l’opération, le computer use pour les systèmes qu’on ne peut pas intégrer.

OpenAI a présenté GPT-6 Astra le 3 septembre 2026 en mettant en avant sa capacité à se servir d’un ordinateur comme le ferait une personne (annonce et fiche système d’OpenAI du 3 septembre). Deux jours plus tôt, le 1er septembre, Anthropic sortait Claude Fable 5.1, dont l’annonce affiche une progression sur OSWorld 2.0, le banc d’essai du pilotage d’interface, sans en faire son axe de communication. La capacité est donc acquise des deux côtés. Ce qui se joue dans les comités d’architecture de la rentrée porte sur le mode qu’on retient par défaut, et sur ce qu’on accepte de perdre en le retenant.

Une capacité en bêta publique depuis 2024

La capacité elle-même n’est pas neuve. Anthropic l’a ouverte en bêta publique le 22 octobre 2024, en la présentant alors comme expérimentale et sujette aux erreurs, et les éditeurs l’ont affinée depuis. Ce qui change en septembre 2026 tient à sa place dans le discours commercial : elle quitte le statut de fonction annexe pour devenir une promesse d’architecture.

Pourquoi cet arbitrage arrive dans les comités d’architecture cet automne ?

Parce que la promesse s’adresse d’abord aux arbitrages budgétaires. Un agent en computer use se branche sur des applications qui n’exposent rien : un client lourd des années 2000, un progiciel métier verrouillé par son éditeur, un extranet fournisseur sans interface programmable. On en trouve dans la plupart des grandes entreprises françaises, et ce sont eux qui font caler les projets d’automatisation au moment du chiffrage, bien plus souvent que les limites des modèles.

Depuis la sortie d’Astra, la même phrase nous revient des directions techniques : on n’aurait plus besoin d’intégrer. Prise telle quelle, la phrase est fausse. Elle contient pourtant une part de vrai qui mérite un arbitrage écrit plutôt qu’un débat de couloir, parce que les deux modes ne se gouvernent pas de la même façon.

Comment un agent pilote-t-il une interface, et comment appelle-t-il une API ?

La boucle capture, décision, action

En computer use, l’agent travaille en boucle. Le programme qui l’encadre, souvent appelé harnais, prend une capture d’écran et l’envoie au modèle avec la consigne. Le modèle répond par une action élémentaire : cliquer à telles coordonnées, saisir un texte, appuyer sur une touche, faire défiler la page. Le harnais l’exécute dans un navigateur ou une machine virtuelle, reprend une capture, et le cycle recommence jusqu’à ce que le modèle estime la tâche terminée.

Le point faible : l’agent déduit l’état du système de ce qu’il voit. Il sait qu’un champ est rempli parce que la capture suivante le montre rempli, et rien ne lui confirme que l’écriture a atteint la base, sauf si un écran de confirmation l’affiche. Un libellé déplacé par une mise à jour suffit à décaler toute la séquence.

L’appel d’outil et le protocole MCP

Une intégration API fonctionne autrement. L’agent dispose d’outils, c’est-à-dire de fonctions décrites par un nom, des paramètres et un format de réponse. Quand il décide d’en utiliser un, il produit un appel structuré, le système cible l’exécute et renvoie un résultat explicite : un identifiant de transaction et un statut, ou un code d’erreur. L’agent lit l’état du système dans cette réponse.

Le Model Context Protocol (MCP), standard ouvert créé par Anthropic et confié depuis le 9 décembre 2025 à l’Agentic AI Foundation, hébergée par la Linux Foundation, normalise cette mécanique. Un serveur MCP expose les fonctions d’une application, et tout agent Claude ou autre client compatible peut les découvrir et les appeler de la même manière. Le connecteur s’écrit une fois, se versionne et se teste comme n’importe quel autre composant du SI. Encore faut-il qu’une interface programmable existe et que quelqu’un écrive ce connecteur.

Beaucoup d’architectures combinent les deux. Dans une direction logistique, par exemple, un même agent peut lire les commandes dans l’ERP par API, puis saisir un avis d’expédition sur l’extranet d’un transporteur qui n’offre aucune interface programmable. Le choix du mode se fait donc action par action, au même grain que la gouvernance.

Computer use ou intégration API : comment trancher ?

Branchez l’agent sur une API chaque fois qu’elle existe et qu’elle couvre l’opération. Réservez le computer use aux systèmes que vous ne pouvez pas intégrer, ou pas dans le temps imparti. Le premier mode se teste et se rejoue à l’identique, alors que le second demande une surveillance continue pendant toute sa durée de vie.

La grille d’arbitrage, cas d’usage par cas d’usage

Avant tout chiffrage, posez ces questions pour chaque cas d’usage et consignez les réponses dans le dossier d’architecture.

  1. Une API couvre-t-elle l’opération de bout en bout, ou seulement la lecture ?
  2. Que coûte une erreur : une ligne à corriger le lendemain, ou une écriture irréversible en base de production ?
  3. Comment saurez-vous que l’agent s’est trompé, et au bout de combien de temps ?
  4. Qui valide avant l’écriture, et à quel endroit de la chaîne ?

La validation avant écriture, souvent sans titulaire

La quatrième question est celle qui reste sans réponse dans les ateliers de cadrage que nous animons. L’agent est cadré techniquement, son périmètre d’écriture est documenté, et personne ne sait dire qui relève l’alerte quand elle tombe un vendredi à dix-neuf heures.

La fréquence et le volume de la tâche

Quand la grille laisse un cas ouvert, la fréquence pèse d’abord. Une tâche quotidienne amortit l’écriture d’un connecteur, et chaque exécution devient plus sûre et moins gourmande en appels au modèle. Une saisie mensuelle dans un écran ancien justifie rarement ce chantier. Le computer use y trouve sa place la plus défendable, à condition que le volume reste assez bas pour qu’un humain relise chaque écriture.

La stabilité de l’interface cible

Un agent qui clique dépend de la mise en page. Une application en ligne qui modifie ses écrans à chaque version casse les séquences sans prévenir, alors qu’un client lourd figé depuis des années offre une cible plus prévisible. Les systèmes les plus anciens font souvent les meilleurs candidats au pilotage d’interface, justement parce que plus personne n’y touche.

La réversibilité de l’écriture

Lire un écran pour en extraire une information expose beaucoup moins qu’y valider un paiement. Un premier déploiement en computer use gagne à rester en lecture seule, qu’il s’agisse de consulter un dossier ou de relever un statut. L’écriture vient ensuite, opération par opération, quand le journal des actions montre que l’agent se repère sur les écrans réels de l’entreprise.

Pourquoi les benchmarks ne tranchent pas à votre place ?

Les scores publiés sur OSWorld varient fortement selon le protocole d’évaluation. Dans son annonce du 1er septembre, Anthropic publie ainsi pour Fable 5.1 deux scores OSWorld 2.0 très éloignés, l’un en notation partielle et l’autre en notation stricte, et précise en note qu’ils ne se comparent pas directement aux résultats OSWorld 2.0 publiés auparavant. L’écart cesse d’être un détail méthodologique le jour où il sert à justifier un choix d’architecture en comité.

Une mesure à produire sur vos propres tâches

Le taux de réussite d’un agent sur un banc d’essai public dit peu de chose de son comportement sur votre progiciel de gestion, avec vos habilitations et vos écrans personnalisés, un jour de clôture comptable. La seule mesure qui vous engage est celle que vous produisez sur vos propres tâches, avec vos propres données. Gartner (2025) anticipe l’annulation de plus de 40 % des projets d’IA agentique d’ici fin 2027. Nous voyons souvent une cause dès l’entrée : une décision d’architecture arrêtée sur des chiffres que personne n’a rejoués en interne.

Qu’est-ce que ça change pour une entreprise française ?

La traçabilité des actions face à l’AI Act

D’abord la traçabilité. Un agent qui clique laisse une trace pauvre : une suite de captures et de coordonnées, sans identifiant de transaction ni code retour. Un agent qui appelle une API laisse une trace exploitable en audit, avec l’appel et sa réponse horodatés. Depuis le 2 août 2026, les obligations de transparence de l’article 50 de l’AI Act s’appliquent, et leur manquement relève du régime de sanctions du règlement. Le règlement Digital Omnibus (UE) 2026/1744, entré en vigueur le 27 juillet 2026, laisse aux systèmes déjà sur le marché avant le 2 août un délai jusqu’au 2 décembre 2026 pour le marquage des contenus prévu à l’article 50, paragraphe 2, et repousse au 2 décembre 2027 les exigences substantielles applicables aux systèmes à haut risque de l’annexe III. Cela laisse du temps sur la documentation lourde, et aucun sur la capacité à répondre à un régulateur qui demande qui a fait quoi, quand et sur quel système.

En France, la désignation formelle des autorités compétentes n’est toujours pas achevée : le projet de loi d’adaptation au droit de l’Union (DDADUE), dont le volet numérique doit les désigner, a été adopté par le Sénat le 18 février 2026 et transmis à l’Assemblée nationale le 20 février, où il n’a pas encore été examiné.

L’identité sous laquelle l’agent agit

Ensuite l’identité. Un agent en computer use hérite d’une session, donc des habilitations de la personne qui l’a ouverte. Beaucoup d’organisations découvrent à cette occasion qu’elles n’ont pas de compte de service pour un agent, et pas de réponse claire sur la responsabilité d’une écriture faite sous le compte d’un collaborateur en congé. Selon Deloitte (State of AI in the Enterprise, édition 2026), 21 % seulement des entreprises ont une gouvernance mature de leurs agents. Le computer use élargit la surface à gouverner avant que ce chiffre ait bougé.

La parade est connue des équipes sécurité : un compte de service propre à chaque agent, limité aux droits qu’exigent ses tâches. Dans des logiciels anciens qui n’avaient prévu aucun utilisateur non humain, créer ce profil prend du temps, et mieux vaut lancer ce chantier avant le pilote.

Quelle gouvernance appliquer selon le mode d’action ?

Le protocole de gouvernance LOOP™ classe chaque action possible d’un agent dans l’une de ses 4 zones, avant la mise en production. Nous recommandons d’y intégrer le mode technique : une même opération peut changer de zone selon qu’elle passe par une API ou en computer use, parce que la qualité de la trace et le niveau de confiance diffèrent.

Zone verte : lectures et opérations réversibles

En zone verte, l’agent agit sans validation, avec un niveau de confiance supérieur à 90 %, et chaque action est tracée. Pour un agent en computer use, nous conseillons d’y réserver surtout des lectures. Une écriture par API, réversible et journalisée avec son identifiant de transaction, y entre plus facilement qu’une écriture en computer use, dont la trace se résume à des captures.

Zones orange et rouge : écritures et situations imprévues

La zone orange couvre les actions dont la confiance se situe entre 70 et 90 % : l’agent propose, un humain désigné valide avant l’exécution. Nous recommandons d’y placer par défaut toute écriture en computer use dans un système de production, le temps que le journal démontre sa fiabilité. Sous 70 % de confiance, la zone rouge impose l’escalade : l’agent s’arrête, documente ce qu’il a compris et ce qui lui manque, alerte le responsable désigné, et la décision humaine est requise sous 4 heures, sans aucune action automatique. Un écran différent de celui attendu ou un message d’erreur inconnu devraient faire basculer l’agent dans cette zone.

Zone noire : ce que l’écran peut faire entrer

Un agent qui lit l’écran lit aussi ce qu’un tiers y a placé. Une page web ou un courriel peut contenir des instructions dissimulées, destinées à détourner l’agent de sa tâche : on parle d’injection de prompt indirecte. LOOP™ range les tentatives d’injection en zone noire, avec blocage immédiat, alerte au RSSI et arrêt complet de l’exécution, au même titre qu’un accès à des données hors de la classification autorisée. Pour un agent qui navigue sur le web, ce risque se traite dès la conception, en limitant les domaines accessibles.

Ce classement se prépare avant le déploiement. Claude Ops, notre programme d’industrialisation, commence ainsi par un audit IT et data qui cartographie les API disponibles et les intégrations à développer, un relevé qui sert ensuite à décider, système par système, du mode d’action de chaque agent.

Quelles erreurs reviennent dans les premiers projets ?

Utiliser le computer use pour contourner la DSI

Un métier qui attend une intégration depuis des mois voit dans le pilotage d’interface un moyen de s’en passer. L’agent tourne alors sur le poste d’un collaborateur, sous son compte, en dehors de tout inventaire. Le résultat rappelle les macros de tableur que plus personne n’ose ouvrir, avec un modèle en plus : la DSI ignore combien d’agents tournent et ce qu’ils modifient. Le pilotage d’interface a sa place dans le catalogue de la DSI, avec les mêmes règles de recensement que les autres automatisations.

Mesurer la réussite sans mesurer l’erreur

Beaucoup de pilotes suivent un taux de tâches terminées. L’indicateur utile en exploitation est le délai entre une erreur de l’agent et sa détection, qui répond à la troisième question de la grille. Un agent qui réussit la plupart de ses saisies mais dont les erreurs restent invisibles pendant un mois coûte plus cher qu’un agent plus lent dont chaque écart remonte le jour même.

Par où commencer ?

Par un inventaire, avant tout pilote. Listez les tâches que vous vouliez automatiser et qui ont été reportées faute d’API disponible. Nous retrouvons cette liste dans la plupart des DSI, sous forme de tickets fermés en « hors périmètre ». Elle délimite le terrain réel du computer use, plus étroit que la promesse commerciale, et se chiffre tâche par tâche.

Une première tâche instrumentée

Prenez ensuite une seule tâche de cette liste, à coût d’erreur faible, et instrumentez-la avant de l’automatiser : un journal des actions et un point de validation humaine nommé. Selon S&P Global (2025), 46 % des POC d’IA sont abandonnés avant la production. D’après notre expérience, les projets qui passent ce cap ont en général décidé de l’observabilité avant d’écrire le premier prompt.

Notre diagnostic de maturité IA vous note en trois minutes sur les 6 axes du référentiel Koneetiv (édition 2026) : Stratégie & vision, Données & socle technique, Adoption & usage, Industrialisation, Compétences et Gouvernance. Cet article touche surtout l’Industrialisation, qui couvre l’intégration au SI, et la Gouvernance, dont relève la traçabilité des décisions. Le cadre d’ensemble figure sur notre page agents IA en entreprise.

Voir aussi notre analyse du passage du pilote à la production, notre guide sur ce qu’est un agent IA en entreprise et la rubrique agents IA en production.