Computer use : fonctionnement, offres et sécurité

Un agent de computer use accomplit des tâches en manipulant une interface graphique : il observe un écran, clique, saisit du texte et vérifie les changements. Il peut piloter un navigateur ou un bureau complet, mais sa fiabilité dépend du parcours, des contrôles et des droits accordés. Réservez-lui des tâches délimitées, avec un résultat vérifiable et une validation avant les engagements sensibles.

Ce que recouvre le computer use

L’utilisation d’ordinateur désigne une capacité d’action, pas un produit unique. Un modèle peut proposer les gestes tandis qu’un autre logiciel les exécute. Une application prête à l’emploi rassemble ces éléments ; une intégration par API vous laisse davantage de responsabilités.

Il faut distinguer le périmètre accessible du mode d’observation. Un agent limité au navigateur ne dispose pas nécessairement des fichiers du poste. Un agent de bureau peut changer de fenêtre et utiliser plusieurs applications, selon ses permissions. L’un comme l’autre peut observer des captures ou exploiter une description structurée des éléments visibles.

Approche	Ce qu’elle observe	Comment elle agit	Limite principale
Pilotage visuel du bureau	Captures de l’écran autorisé	Souris, clavier, défilement	Sensibilité aux fenêtres et à leur disposition
Navigation structurée	Éléments et structure d’une page	Actions sur les contrôles identifiés	Dépendance à la structure exposée
Intégration par API	Données prévues par le service	Opérations explicitement disponibles	Couverture limitée par l’API
Automatisation à règles fixes	États et conditions prédéfinis	Séquence programmée	Maintenance lorsque le parcours change

Ces approches peuvent se combiner. Une interface graphique peut servir à récupérer un document, puis une opération structurée à traiter son contenu.

Pour les parcours exclusivement web, l’article sur les agents navigateurs complète ce guide. Le choix décisif reste le même : donner à l’agent le chemin le plus contrôlable vers le résultat, sans élargir inutilement son accès.

Comment fonctionne la boucle d’actions

Le fonctionnement repose sur une boucle : recevoir l’objectif, observer l’environnement, choisir une action, l’exécuter, puis observer de nouveau. Le modèle ne déplace pas directement la souris. Il émet une demande qu’un programme traduit en geste dans l’environnement autorisé.

Une consigne comme préparer un export implique plusieurs décisions : reconnaître le bon compte, choisir la période, lancer le téléchargement et retrouver le fichier. Une erreur initiale peut produire un résultat apparemment cohérent. L’agent doit donc vérifier les éléments qui déterminent la suite, notamment l’identité du compte et les filtres sélectionnés.

La capture suivante peut révéler une boîte de dialogue, un chargement ou une action sans effet. Continuer depuis une observation périmée expose à cliquer au mauvais endroit. Les raccourcis clavier peuvent simplifier certains gestes, mais ne dispensent pas de contrôler le champ actif.

La documentation computer use d’Anthropic, consultée le 24 octobre 2026, décrit une capacité de capture et de contrôle souris-clavier dont l’application cliente exécute les appels. Elle souligne aussi que le modèle peut supposer une action réussie sans la vérifier.

Terminer une séquence ne prouve pas que l’objectif est atteint. Un clic sur l’export ne prouve ni la présence du fichier, ni sa période, ni son contenu. La condition de réussite doit donc être définie avant l’exécution, idéalement avec une vérification indépendante de l’interprétation visuelle.

Les offres : distinguer application, modèle et infrastructure

Au 24 octobre 2026, comparer les offres demande de préciser ce que vous achetez : une interface utilisable directement, une capacité de modèle, un agent programmable ou un environnement d’exécution. Ces briques ne remplacent pas les mêmes travaux.

Offre ou brique	Nature	Périmètre documenté	Responsabilité à examiner
Computer Use dans ChatGPT	Fonction dans l’application de bureau	Interfaces locales autorisées	Permissions du poste et disponibilité régionale
Computer use de Claude	Capacité intégrable par API	Environnement fourni par l’intégrateur	Exécution des actions et contrôles
Browser Use	Agent programmable et services hébergés	Navigation web	Choix du modèle, sessions et données
Cua	Pilotes et infrastructure	Environnements informatiques et isolation	Assemblage et exploitation
Playwright MCP	Serveur d’outils	Navigateur et structure accessible des pages	Agent appelant et droits de session

La documentation Computer Use de ChatGPT indique une disponibilité sur macOS et Windows, dans les régions prises en charge, avec ChatGPT Work et Codex. Elle distingue cet accès local des tâches réalisées dans un environnement distant.

Les anciens noms demandent de la vigilance. La page d’aide ChatGPT agent indique désormais que ce mode n’est plus disponible et oriente vers ChatGPT Work. Elle conserve des sections historiques : leurs anciennes limites ne constituent donc pas une description fiable de l’offre actuelle. Operator est également un ancien nom, dont les fonctions avaient été intégrées au mode agent.

Cette comparaison décrit les périmètres documentés ; elle ne constitue pas un classement de réussite.

Choisir une brique programmable

Le dépôt officiel Browser Use, consulté le 24 octobre 2026, distingue bibliothèque, interface en ligne de commande et services cloud. Un navigateur hébergé fournit l’environnement de navigation ; une offre d’agent hébergé prend aussi en charge l’exécution de l’agent. Cette différence détermine ce que votre équipe doit exploiter.

Le dépôt officiel Cua présente des pilotes, des environnements isolés et des outils destinés notamment à l’évaluation. Il faut le considérer comme une infrastructure à intégrer, plutôt que présumer qu’il fournit une application finale adaptée à votre métier.

Le dépôt officiel Playwright MCP décrit une interaction fondée sur des représentations structurées d’accessibilité. Cette approche permet de cibler des éléments web sans dépendre uniquement de leur position dans une capture. Elle ne décide toutefois pas à elle seule de la pertinence d’une action.

Pour comparer ces briques, examinez les points suivants :

qui choisit les actions et quel modèle reçoit les observations ;
qui héberge la session et conserve ses données ;
comment suspendre, reprendre et fermer une exécution ;
quelles opérations peuvent être bloquées techniquement ;
quelles preuves restent disponibles après un incident.

Les fiches de l’annuaire des agents IA permettent de retrouver les projets. Leur popularité et leur activité constituent des indices d’entretien, pas une mesure de leur fiabilité sur votre tâche.

Quand préférer une API ou une automatisation classique

Le computer use est pertinent lorsqu’une interface est le seul chemin praticable vers une opération. Il peut aussi aider à explorer un parcours variable ou à contrôler un résultat tel qu’un utilisateur le voit. Sa souplesse a cependant un coût : davantage d’observations, d’attente et d’incertitude.

Lorsqu’une API adaptée existe, examinez-la d’abord. Elle peut rendre explicites les champs, les identifiants, les erreurs et les droits. Cela facilite les contrôles, sans garantir l’absence d’erreurs métier. Une intégration structurée peut parfaitement modifier le mauvais dossier si l’objectif est ambigu.

Une automatisation à règles fixes convient aux parcours stables dont les conditions sont connues. Introduire un modèle pour choisir chaque clic n’apporte pas nécessairement de bénéfice. Inversement, accumuler des règles fragiles pour toutes les variantes peut devenir difficile à maintenir.

Prenons un exemple hypothétique : récupérer un document sur un portail sans API exploitable. L’agent peut naviguer jusqu’au téléchargement, puis un traitement déterministe contrôler le nom, le format et les champs attendus. La validation finale dépend alors de critères explicites.

Pour choisir, partez du besoin : faut-il interpréter un écran, décider d’un chemin variable ou simplement déplacer des données connues ? Réservez la liberté de décision aux étapes qui en ont besoin. Les étapes prévisibles gagnent à conserver des contrôles simples et reproductibles.

Évaluer la fiabilité sur une tâche complète

Un agent peut reconnaître correctement les boutons et échouer sur le résultat métier. Il peut aussi demander de l’aide au bon moment : cette interruption réduit l’autonomie, mais peut éviter une erreur. Mesurez séparément réussite, intervention humaine et incidents.

Préparez des situations représentatives : chargement lent, fichier déjà présent, session expirée, fenêtre inattendue, plusieurs dossiers homonymes ou résultat absent. Incluez aussi un parcours où l’agent doit renoncer parce que les informations disponibles ne suffisent pas.

Dimension	Observation à conserver	Décision qu’elle éclaire
Résultat	État final vérifié indépendamment	La tâche est-elle accomplie ?
Intervention	Motif et durée des reprises humaines	Quelle supervision prévoir ?
Temps	Durée complète, attente comprise	Le parcours apporte-t-il un gain ?
Dépense	Appels, environnement et reprises	Quel budget réel prévoir ?
Incident	Action indue, doublon ou exposition	Le périmètre est-il acceptable ?

Les benchmarks publics servent à situer des capacités dans un protocole donné. OSWorld 2.0, consulté le 24 octobre 2026, porte sur des tâches informatiques longues dans des environnements réels. Un score doit rester attaché au protocole, aux outils autorisés et aux conditions d’exécution.

Ne transposez pas un résultat public en probabilité de réussite sur votre logiciel. Une démonstration sélectionnée ne renseigne pas davantage sur les échecs ordinaires. Le guide pour évaluer un agent IA détaille la construction d’un jeu de tests adapté.

Les erreurs ordinaires et les reprises dangereuses

Les difficultés ne viennent pas uniquement du modèle. Une application peut déplacer un bouton, afficher une notification ou appliquer un filtre mémorisé. Un téléchargement peut rester en cours alors que l’écran paraît revenu à son état initial.

Les intitulés ambigus constituent un autre piège. Un bouton de confirmation peut enregistrer un brouillon, publier un document ou engager un achat selon le contexte. La lecture du libellé doit être complétée par celle de l’objet concerné, du destinataire et des conséquences.

La reprise après incident mérite une règle distincte. Si la connexion tombe après une soumission, recommencer immédiatement peut créer un doublon. L’agent doit d’abord rechercher une preuve de l’action précédente : document créé, état du dossier ou confirmation du service.

Prévoyez des points de reprise qui décrivent l’état atteint, plutôt qu’une simple liste de clics exécutés. Un état utile précise le dossier ouvert, les changements confirmés et les opérations encore incertaines. Il permet à une personne de reprendre sans deviner.

Enfin, limitez les tentatives et la durée d’une exécution. Lorsqu’un blocage persiste, le résultat attendu doit être un compte rendu exploitable : action tentée, observation obtenue et incertitude restante. Une relance aveugle consomme du budget et peut aggraver l’erreur.

Sécurité : les contenus affichés restent des données

Un agent lit des pages, des messages et des documents susceptibles de contenir des instructions hostiles. Une injection de prompt cherche à lui faire traiter ce contenu comme une consigne autorisée. Elle peut apparaître dans du texte ou dans une image observée.

L’accès au navigateur ajoute un enjeu : une session connectée représente déjà une autorisation. Même sans connaître le mot de passe, l’agent peut disposer des actions offertes au compte. Protéger uniquement les identifiants ne suffit donc pas.

Séparez autant que possible consultation, préparation et engagement. Un compte capable de lire des dossiers n’a pas nécessairement besoin de les supprimer. Un environnement de préparation peut produire un brouillon sans pouvoir l’envoyer. Ces restrictions doivent être appliquées par les permissions, pas seulement exprimées dans le prompt.

L’isolation limite certaines conséquences sur le poste, mais elle ne neutralise pas les droits d’un compte distant. Une session isolée qui peut envoyer des messages conserve cette capacité. De même, une liste de domaines autorisés réduit l’exposition sans garantir que leur contenu est fiable.

Anthropic recommande notamment un environnement dédié, des privilèges minimaux et une confirmation humaine pour les décisions ayant des conséquences significatives. Le guide pour sécuriser un agent IA permet de transformer ces principes en règles de déploiement.

Prévoyez aussi un arrêt accessible qui suspende réellement l’exécution et permette de fermer les accès concernés.

Confidentialité : suivre les écrans, les fichiers et les sessions

Une capture peut exposer davantage que le document visé : notifications, noms de clients, onglets, chemins de fichiers ou données d’un autre dossier. Préparer un environnement dépouillé réduit cette collecte accidentelle. Fermez les applications inutiles et utilisez un profil distinct lorsque c’est possible.

Cartographiez séparément les endroits où circulent les données : poste local, environnement distant, fournisseur du modèle, stockage des traces et outil de supervision. Une exécution dite locale peut encore envoyer ses observations à une API distante. Un navigateur cloud peut conserver un état de connexion.

Demandez quelles données sont conservées, pendant combien de temps, dans quelle zone et avec quels accès administratifs. Vérifiez également comment supprimer une session et révoquer les autorisations. Ces questions doivent couvrir les captures, les fichiers téléchargés et les journaux.

La journalisation doit rester proportionnée. Elle aide à comprendre une erreur, mais peut créer une nouvelle copie d’informations sensibles. Conservez les éléments utiles à l’audit avec des accès limités et une durée définie, plutôt qu’un enregistrement permanent par défaut.

Pour une tâche sensible, examinez le contenu visible avant le lancement. Une permission de capture d’écran ne distingue pas spontanément ce qui est utile à l’objectif de ce qui appartient à un autre travail. La préparation du poste fait donc partie du contrôle de confidentialité.

Coût : raisonner par résultat accepté

Le coût total associe les appels au modèle, l’environnement d’exécution, les services annexes, l’intégration et la supervision. Une bibliothèque disponible sans paiement ne rend pas nécessairement son exploitation gratuite. Un abonnement général ne prouve pas non plus que la fonction souhaitée est incluse.

Les captures, les observations répétées et l’historique peuvent alimenter la consommation du modèle. Les chargements et les reprises allongent l’occupation de l’environnement. Selon l’offre, ces éléments peuvent relever de facturations différentes : vérifiez le périmètre exact avant toute comparaison.

Le bon indicateur est le coût par résultat accepté. Rapportez les dépenses d’un lot aux tâches effectivement validées, en comptant aussi les tentatives abandonnées. Ajoutez le temps consacré à relire, corriger et reprendre les incidents.

Un parcours peu coûteux à lancer peut devenir peu intéressant si chaque résultat demande une inspection complète. À l’inverse, une supervision courte et ciblée peut être compatible avec une tâche répétitive, à condition que le résultat soit facile à vérifier.

Fixez des plafonds de dépense, de durée et de tentatives. Comparez enfin le parcours avec une exécution humaine ou une automatisation classique sur le même périmètre. Le budget doit inclure l’entretien lorsque l’interface change, pas seulement la première démonstration réussie.

Organiser un pilote contrôlable

Commencez par une tâche réversible sur des données fictives ou adaptées au test. Les prérequis sont un environnement distinct, un compte aux droits limités, un résultat attendu et une personne capable de reprendre. Il n’est pas nécessaire d’autoriser un envoi ou une publication pour vérifier la préparation d’un livrable.

Décrivez le résultat. Précisez le compte, la période, le format et les critères d’acceptation.
Délimitez l’accès. Autorisez seulement les applications, dossiers et destinations nécessaires.
Définissez les arrêts. Prévoyez les cas ambigus, les erreurs persistantes et les engagements sensibles.
Testez les variantes. Incluez un parcours normal et des situations qui doivent provoquer une interruption.
Contrôlez indépendamment. Vérifiez le livrable ou l’état du service, puis consignez les écarts.
Élargissez progressivement. Ajoutez un parcours lorsque les résultats précédents sont compris.

Problèmes fréquents

Si l’agent perd la fenêtre active, demandez une nouvelle observation avant toute saisie. S’il rencontre une authentification ou un CAPTCHA, prévoyez une reprise humaine autorisée. Si l’issue d’une soumission reste incertaine, contrôlez l’état distant avant de relancer.

Checklist avant utilisation régulière

Le résultat peut être vérifié sans croire le compte rendu de l’agent.
Les permissions correspondent à la tâche.
Les actions sensibles passent par une validation explicite.
Les incidents ont une procédure de reprise.
Les traces et sessions ont une durée de conservation.
Les plafonds et l’arrêt ont été vérifiés.

À retenir

Le computer use donne accès à une interface ; la qualité du résultat reste à démontrer sur votre parcours.
Distinguez le modèle, l’agent, le navigateur et l’environnement avant de comparer les offres.
Privilégiez les opérations structurées lorsqu’elles couvrent le besoin et facilitent les contrôles.
Encadrez les droits, vérifiez les effets réels et mesurez le coût de supervision avec celui de l’exécution.

Pages liées

Questions fréquentes

Un agent computer use contrôle-t-il forcément mon ordinateur personnel ?

Non. Il peut agir dans un navigateur hébergé, une machine virtuelle ou une session locale autorisée. Avant toute connexion, vérifiez quel environnement il commande et quels comptes y sont déjà ouverts.

Peut-on utiliser un agent computer use sans savoir programmer ?

Une interface prête à l'emploi peut éviter de développer la boucle d'actions. L'intégration d'une capacité par API demande en revanche de gérer l'exécution, les erreurs et les permissions. Dans les deux cas, il faut définir un résultat vérifiable.

Computer use fonctionne-t-il avec tous les logiciels ?

L'accès à une interface graphique ne garantit pas que l'agent sache accomplir une tâche. La compatibilité dépend notamment du système, des permissions, de la lisibilité des écrans et des mécanismes d'authentification. Un essai sur votre parcours reste nécessaire.

Un agent peut-il travailler pendant que j'utilise le même ordinateur ?

Sur une session partagée, vos mouvements de souris et changements de fenêtre peuvent perturber son travail. Préférez un environnement distinct lorsque l'outil le permet. Vérifiez aussi si une interruption humaine suspend réellement les actions.

Un projet open source permet-il de garder toutes les données en local ?

La disponibilité du code ne détermine pas le trajet des données. Un programme installé localement peut envoyer des captures à un modèle distant ou utiliser un navigateur hébergé. Il faut examiner séparément chaque composant et ses réglages.

Agents qui utilisent un ordinateur (computer use) : fonctionnement, offres, fiabilité, sécurité