Agent IA qui contrôle un ordinateur : comment ça marche vraiment

Un agent IA qui contrôle un ordinateur ne se contente pas de répondre dans une fenêtre de chat. Il regarde un écran, comprend l’état d’une interface, choisit une action, clique, tape, défile, puis observe le résultat avant de continuer. Cette boucle lui permet d’utiliser des sites et des logiciels conçus pour les humains, même quand aucune API n’existe.

La démonstration est fascinante. La réalité opérationnelle est plus exigeante. Un agent peut remplir un formulaire ou collecter des informations, puis échouer sur une fenêtre inattendue, un changement d’interface ou une action ambiguë. Le bon usage n’est donc pas de lui donner les clés de toute ta vie numérique. C’est de lui confier un workflow borné, observable et récupérable.

Ce guide explique comment fonctionne le computer use, ce qu’un agent peut réellement faire, où il reste fragile et comment construire un système utile sans transformer chaque clic en pari.

Un agent IA qui contrôle un ordinateur, c’est quoi ?

Un agent de computer use combine quatre capacités :

1. voir l’interface grâce à des captures d’écran ;

2. comprendre les éléments visibles et l’objectif demandé ;

3. choisir une action de souris ou de clavier ;

4. recommencer jusqu’à la fin de la tâche ou jusqu’à un blocage.

OpenAI décrit cette boucle comme une succession de perception, raisonnement et action dans sa présentation du Computer-Using Agent. Le modèle reçoit une capture, décide du prochain geste, agit dans une machine virtuelle, puis reçoit une nouvelle capture.

Cette méthode est différente d’une intégration API classique. Une API expose des commandes propres comme « créer un événement » ou « chercher un client ». Le computer use manipule l’interface humaine : bouton, menu, champ, tableau, boîte de dialogue.

L’avantage est énorme. L’agent peut travailler sur un outil ancien, fermé ou dépourvu d’intégration. La contrepartie est claire : une interface visuelle est moins stable et moins explicite qu’une API.

La boucle perception, raisonnement, action

1. Perception

L’agent reçoit une image de l’écran. Il doit reconnaître ce qui ressemble à un bouton, un champ, une notification ou un résultat. Il ne lit pas seulement du texte. Il interprète une disposition visuelle.

Cette étape paraît simple quand l’interface est propre. Elle se complique avec les fenêtres superposées, les menus animés, les éléments hors écran, les textes tronqués, les thèmes sombres ou les boutons sans libellé.

2. Raisonnement

Le modèle relie l’état visible à l’objectif. Si tu lui demandes de retrouver cinq factures, il doit décider où commencer, quels filtres utiliser, comment vérifier la période et où enregistrer les résultats.

Un bon agent ne génère pas un plan figé de vingt étapes. Il progresse avec l’état réel de l’écran. Si une bannière bloque un bouton, il la ferme. Si la recherche ne retourne rien, il modifie la requête. Si la session expire, il s’arrête.

3. Action

L’agent clique, défile, tape du texte ou utilise une touche. Chaque action modifie potentiellement l’environnement. Il faut donc observer à nouveau avant de poursuivre.

Cette boucle continue jusqu’à trois sorties possibles :

• la tâche est terminée et vérifiée ;

• l’agent rencontre un problème récupérable ;

• l’agent a besoin d’une décision ou d’une validation humaine.

Le troisième cas n’est pas un échec. C’est une fonction de sécurité.

Computer use ou API : quelle différence ?

Une API est préférable quand elle existe, qu’elle est stable et qu’elle expose exactement l’action nécessaire. Elle renvoie des données structurées, gère mieux les erreurs et évite de dépendre de la position d’un bouton.

Le computer use devient pertinent dans quatre situations :

• aucune API n’existe ;

• l’API ne couvre qu’une partie du workflow ;

• l’interface rassemble plusieurs informations difficiles à obtenir autrement ;

• la tâche traverse plusieurs outils conçus pour être utilisés à la main.

Le meilleur système est souvent hybride. L’agent utilise une API pour récupérer des données, puis une interface visuelle pour une étape non exposée. Il peut aussi préparer une action via API et demander à l’humain de confirmer dans l’interface.

Opposer totalement les deux approches est une erreur. L’objectif n’est pas de faire cliquer une IA pour le plaisir. L’objectif est de terminer un travail avec le chemin le plus fiable.

Ce que les agents savent déjà faire

Les usages les plus solides ont trois caractéristiques : ils sont répétitifs, peu ambigus et faciles à vérifier.

Rechercher et collecter

Un agent peut ouvrir plusieurs pages, appliquer des filtres, relever des résultats et les ranger dans un tableau. Cela fonctionne bien quand les critères sont précis et que chaque ligne peut être vérifiée.

Exemple : trouver les pages tarifaires de dix outils, relever le prix public et conserver l’URL source.

Remplir des formulaires

Il peut saisir des informations dans une interface, choisir des options et préparer l’envoi. Pour une action importante, la soumission finale doit rester soumise à validation.

Exemple : préparer un dossier administratif avec des données déjà vérifiées, puis laisser l’utilisateur relire avant l’envoi.

Déplacer des données entre outils

Un agent peut lire une information dans un tableau, ouvrir un CRM et préparer une mise à jour. Ce cas est utile quand l’intégration native manque, mais il exige des contrôles contre les doublons et les écritures sur le mauvais compte.

Naviguer dans un logiciel métier

Les entreprises utilisent encore beaucoup d’outils internes ou anciens sans API moderne. Le computer use peut leur donner une couche d’automatisation sans reconstruire immédiatement tout le logiciel.

Il faut toutefois commencer en lecture seule. Observer et extraire est moins risqué que modifier.

Préparer un livrable

L’agent peut rassembler des informations, ouvrir un document et construire un premier brouillon. Pour les présentations, les tableaux complexes ou les éditeurs inhabituels, la fiabilité reste très variable.

Ce que montrent les évaluations

Les benchmarks sont utiles pour mesurer une direction, pas pour promettre un taux de réussite dans ton entreprise.

Dans sa publication de janvier 2025, OpenAI indiquait que son CUA atteignait 38,1 % sur OSWorld, un benchmark de contrôle complet d’ordinateur, contre 72,4 % pour les humains dans la référence citée. Le même système obtenait 58,1 % sur WebArena et 87 % sur WebVoyager, deux évaluations centrées sur le navigateur.

Ces chiffres montrent deux choses.

Premièrement, le computer use avait déjà dépassé les anciens systèmes sur plusieurs tests. Deuxièmement, il restait loin d’une fiabilité humaine sur les environnements complexes.

OpenAI précisait aussi que les tâches simples et répétitives réussissaient mieux que les interfaces inconnues ou l’édition de texte complexe. C’est exactement la frontière utile pour choisir un premier workflow.

Ne demande pas : « Est-ce que les agents savent contrôler un ordinateur ? »

Demande : « Sur cette tâche précise, avec cette interface, ce niveau de risque et ce contrôle, quel taux de réussite observons-nous ? »

Les sept fragilités à connaître

1. Une interface change

Un bouton est déplacé, un menu est renommé ou une bannière apparaît. L’agent doit reconnaître que son chemin habituel n’existe plus.

2. Le contexte visible est incomplet

Une ligne est hors écran. Un état n’apparaît qu’après un survol. Un message d’erreur disparaît trop vite. L’agent peut tirer une conclusion avec une image partielle.

3. Deux éléments se ressemblent

Les interfaces utilisent souvent plusieurs boutons « Enregistrer », plusieurs comptes ou plusieurs conversations proches. Une action correcte au mauvais endroit reste une erreur.

4. Une instruction est ambiguë

« Mets à jour le dossier » ne dit pas quel champ, quelle source fait autorité ni comment traiter un conflit.

5. La session expire

Connexion, double authentification et CAPTCHA peuvent interrompre le travail. L’agent doit savoir rendre la main sans tenter de contourner la sécurité.

6. Une page contient une instruction hostile

Un texte affiché à l’écran peut tenter d’influencer l’agent. Ce risque de prompt injection impose de séparer les instructions de confiance du contenu rencontré.

7. La tâche a une conséquence irréversible

Envoyer un email, acheter, supprimer, publier ou modifier un droit d’accès n’est pas un simple clic. Le système doit reconnaître l’importance de l’action.

Les validations humaines indispensables

Dans sa présentation d’Operator, OpenAI décrit plusieurs mécanismes : reprise en main pour les données sensibles, confirmation avant une action importante et surveillance renforcée sur certains sites.

Cette logique peut être appliquée à n’importe quel agent.

Garde une validation humaine avant :

• un paiement ;

• un envoi public ;

• un email externe ;

• une suppression ;

• une modification de permissions ;

• une décision liée à l’emploi, la santé, le droit ou la finance ;

• une saisie d’identifiants ou de données privées.

Pour les workflows moins risqués, la validation peut porter sur un lot. L’agent prépare vingt mises à jour, puis l’humain contrôle un rapport avant l’écriture.

Le but n’est pas de valider chaque mouvement de souris. Ce serait juste une automatisation pénible. Le but est de placer les contrôles sur les conséquences.

Comment choisir un premier workflow

Le meilleur premier cas n’est pas le plus spectaculaire. C’est celui qui passe cinq tests.

Fréquent

La tâche revient assez souvent pour justifier l’effort de construction.

Borné

Le début, la fin et les actions possibles sont clairs.

Vérifiable

Tu peux déterminer rapidement si le résultat est correct.

Récupérable

Une erreur peut être annulée ou corrigée sans dommage majeur.

Mesurable

Tu peux comparer temps gagné, taux de réussite ou volume traité.

Un bon exemple : collecter chaque semaine des informations publiques dans dix interfaces et préparer un tableau sourcé.

Un mauvais exemple : « Gère tout mon ordinateur pendant que je ne regarde pas. »

Construire le workflow en six étapes

Étape 1 : écrire le résultat attendu

Décris le fichier, le tableau, le statut ou la preuve qui doit exister à la fin. Évite les missions vagues.

Étape 2 : cartographier le chemin humain

Fais la tâche une fois toi-même. Note les écrans, les choix, les erreurs fréquentes et les cas particuliers.

Étape 3 : réduire le périmètre

Commence avec un site, un type de dossier et une action. N’ajoute pas cinq outils avant d’avoir une boucle stable.

Étape 4 : définir les arrêts

Écris les conditions où l’agent doit demander de l’aide : identité incertaine, donnée manquante, page inconnue, action sensible ou résultat contradictoire.

Étape 5 : enregistrer les preuves

Conserve les URLs, statuts, captures ou identifiants utiles. Une phrase « terminé » ne prouve rien.

Étape 6 : mesurer plusieurs cycles

Teste sur dix ou vingt cas réels. Classe les échecs : perception, instruction, interface, permission ou logique métier. Corrige le système, pas seulement le dernier cas.

Cette boucle rejoint la méthode de feedback pour agents IA : observer, nommer l’erreur, modifier une règle puis retester.

L’architecture de permissions

Un agent qui voit tout et peut tout faire est facile à imaginer et difficile à sécuriser.

Le principe le plus solide est le moindre privilège. L’agent reçoit uniquement les droits nécessaires à son workflow.

Tu peux séparer :

• un profil de lecture ;

• un profil de préparation ;

• un profil d’écriture limitée ;

• les actions sensibles réservées à l’humain.

Utilise aussi un environnement isolé quand c’est possible. Un navigateur dédié, une machine virtuelle ou un compte de test limite l’impact d’une mauvaise action.

La séparation des comptes aide autant la sécurité que le diagnostic. Quand l’agent utilise un espace propre, ses traces sont plus faciles à retrouver et ses permissions plus faciles à comprendre.

Computer use et agent autonome

Contrôler un ordinateur ne rend pas automatiquement un agent autonome.

L’autonomie dépend de cinq éléments :

• la durée pendant laquelle il peut agir ;

• les décisions qu’il peut prendre ;

• les sources qu’il peut consulter ;

• les actions qu’il peut déclencher ;

• les validations qu’il doit obtenir.

Un agent peut cliquer seul tout en restant fortement supervisé. À l’inverse, un agent branché uniquement sur des API peut exécuter beaucoup d’actions sans intervention.

Le computer use est une capacité. L’autonomie est une politique.

Cette distinction évite le fantasme du « Jarvis » qui pilote tout. Un système utile n’a pas besoin d’une autonomie totale. Il a besoin d’un périmètre où il réussit souvent, signale clairement les exceptions et laisse une preuve exploitable.

FAQ

Un agent IA peut-il utiliser n’importe quel logiciel ?

En théorie, une interface visible peut être manipulée. En pratique, la fiabilité dépend du logiciel, de la stabilité de l’interface, de la complexité de la tâche et des protections présentes.

Est-ce plus fiable qu’une automatisation classique ?

Pas quand une API ou une intégration stable couvre le besoin. Le computer use est surtout utile pour les trous entre les outils ou les logiciels sans connexion propre.

Faut-il savoir coder ?

Pas pour utiliser un produit fini. Pour construire un système sur mesure, il faut au minimum savoir définir les permissions, les validations, les preuves et les scénarios d’échec.

Peut-il saisir mes mots de passe ?

Techniquement, certains systèmes peuvent interagir avec des champs de connexion. La bonne pratique est de reprendre la main pour les informations sensibles ou d’utiliser un gestionnaire d’accès conçu pour l’automatisation.

Peut-il publier ou acheter seul ?

Il peut préparer l’action. La validation finale doit rester humaine tant que le système n’a pas un cadre de risque extrêmement précis.

À retenir

Un agent IA qui contrôle un ordinateur ouvre une nouvelle couche d’automatisation : il peut travailler dans les interfaces que ton entreprise utilise déjà.

Mais le pouvoir ne vient pas du clic automatique. Il vient de la boucle complète :

1. une mission bornée ;

2. une perception de l’état ;

3. une action ;

4. une preuve ;

5. une validation au bon endroit ;

6. une correction après les échecs.

Commence par une tâche fréquente, peu risquée et vérifiable. Mesure les cycles réels. Garde les conséquences sensibles sous contrôle humain.

C’est moins spectaculaire que « l’IA gère mon ordinateur ». C’est beaucoup plus proche d’un système qui travaille vraiment.