Piloter un écran ne vaut pas droit de tout cliquer

Un modèle capable de piloter un écran lit des captures de l’interface graphique, déplace le pointeur, clique et saisit du texte comme le ferait un utilisateur, ce qui lui donne accès à des applications sans interface programmable. C’est le verrou qu’il fait sauter, et il est réel dans la plupart des grandes organisations.

Anthropic vient d’ouvrir en version bêta cette capacité d’utilisation de l’ordinateur avec la nouvelle version de Claude 3.5 Sonnet. Le principe est simple : le modèle reçoit une capture d’écran, décide de l’action suivante, l’exécute, reçoit une nouvelle capture, et ainsi de suite jusqu’à la fin de la tâche.

Une part importante du travail administratif se déroule dans des logiciels anciens sans API : un progiciel métier, un portail fournisseur, un outil interne développé il y a quinze ans. Automatiser ces gestes exigeait jusqu’ici un développement spécifique et fragile.

Un modèle qui manipule l’interface directement contourne l’obstacle. C’est une capacité utile, et cette capacité peut exposer un périmètre très large : il peut faire tout ce que l’utilisateur dont il emprunte la session peut faire.

Un périmètre défini par une liste d’appels autorisés ne fonctionne plus quand le système agit par l’écran, puisqu’il n’y a plus d’appels à lister et que tout ce qui est visible devient cliquable. C’est la difficulté propre à cette capacité.

Avec une interface programmable, on autorise quatre appels et on en interdit le reste. C’est le cadre posé dans le périmètre avant l’autonomie, et il est net.

Avec un écran, tout est cliquable. Le bouton « valider » et le bouton « annuler » se ressemblent, et rien dans le mécanisme n’empêche le second d’être atteint.

Le périmètre doit donc être posé en amont, dans les droits du compte utilisé. Un système qui pilote une session dont le compte n’a pas le droit de valider un paiement ne peut pas valider un paiement, quelle que soit son erreur d’interprétation. C’est une barrière technique essentielle, à compléter par l’isolation, les contrôles des outils et les confirmations.

Avant qu’un agent utilise une interface graphique, je définis un compte dédié, des droits minimaux, une trace proportionnée, des confirmations et des limites d’exécution techniques.

• Un compte dédié aux droits minimaux, jamais la session d’un utilisateur humain. C’est la barrière principale.
• Un enregistrement de la session : ce qui a été vu, ce qui a été cliqué. Des captures ciblées peuvent aider l’analyse, avec une collecte limitée et protégée pour éviter de conserver des données sensibles inutiles.
• Une validation humaine sur tout ce qui est irréversible, présentée avant le clic et pas après.
• Une limite de durée et d’actions par exécution, pour qu’une boucle d’erreur s’arrête d’elle-même.

Un modèle qui lit l’écran peut être influencé par ce qui y est affiché, y compris par un texte placé là pour lui, car il ne distingue pas l’interface de son contenu. Cette vulnérabilité est structurelle et sérieuse.

Si une page web, un courriel ouvert ou un document affiché contient une instruction rédigée à destination du modèle, ce modèle la lit au même titre que le reste de l’écran. Le système peut confondre une instruction affichée dans le contenu avec une consigne autorisée ; la séparation doit être testée.

Le risque est plus élevé que dans un système documentaire, parce que la capacité d’action est plus large. Un système qui ne peut que répondre produit une réponse fausse ; un système qui pilote un écran peut agir.

Restreindre les droits du compte limite les conséquences, mais ne suffit pas à éliminer une injection dans le périmètre permis. Aucune consigne, aussi bien rédigée soit-elle, ne remplace une interdiction technique, même un prompt système conçu pour tenir dans la durée. C’est le principe posé dans quand un modèle commence à agir.

Le test d’une instruction hostile affichée à l’écran vérifie que l’agent n’exécute pas une action interdite et que les contrôles techniques limitent les conséquences possibles.

Placer volontairement une fausse instruction dans un document que le système va afficher, et vérifier qu’il ne l’exécute pas. Si le test échoue, analysez la séparation entre instructions et données, les permissions et les filtres d’action, puis rejouez le scénario. Un test réussi ne prouve pas l’absence de toutes les injections.

Un premier usage de pilotage d’écran se prépare en six étapes, du choix d’une tâche sans effet irréversible jusqu’au test d’injection, avant toute mise en service. L’ordre limite les dégâts possibles pendant l’apprentissage.

1. Choisir une tâche qui lit ou recopie, sans action qui engage l’organisation.
2. Créer un compte technique aux droits strictement nécessaires, identifiable dans les journaux.
3. Isoler l’environnement d’exécution : une machine virtuelle dédiée, sans accès aux services inutiles à la tâche.
4. Activer l’enregistrement de la session et le conserver avec la trace des actions.
5. Fixer les plafonds de durée et de nombre d’actions par exécution.
6. Réaliser le test d’injection décrit plus haut, puis le rejouer à chaque changement de l’écran ou du modèle.

La confidentialité des informations envoyées au modèle inclut les captures et les données visibles : l’autorisation d’agir ne vaut pas autorisation de tout transmettre.

Le pilotage d’écran crée de la valeur sur les gestes répétitifs, bornés et vérifiables a posteriori, comme la saisie, l’extraction ou le contrôle sans modification. Les autres usages relèvent de la démonstration.

Trois familles fonctionnent bien. La saisie répétitive dans un progiciel sans interface programmable, où le système recopie des données déjà validées ailleurs. L’extraction depuis un portail qui n’exporte rien, où le système ne fait que lire. Et le contrôle systématique, où le système parcourt des écrans pour signaler des anomalies sans rien modifier.

Ces trois usages partagent une caractéristique : soit ils ne modifient rien, soit ils recopient une donnée dont l’original fait foi ailleurs. L’erreur y est détectable et rattrapable.

À l’inverse, confier à un tel système une action qui engage l’organisation sans point de contrôle revient à parier sur l’interprétation correcte d’une interface graphique par une machine. Ce pari se perd régulièrement. La frontière rejoint celle de ce qu’on ne délègue jamais à un modèle.

Une action réalisée par un système pilotant l’écran est indiscernable d’une action humaine dans la plupart des journaux applicatifs, et c’est un problème juridique avant d’être technique. Il faut le traiter avant le déploiement.

Le progiciel enregistre qu’un compte a cliqué. Il n’enregistre pas si le clic venait d’une personne ou d’un automate. En cas de contestation, une commande passée à tort ou une validation indue devient plus difficile à reconstituer si le compte et les traces ne distinguent pas l’automatisation.

La parade tient en deux gestes : un compte technique distinct, identifiable dans les journaux, et un enregistrement horodaté de la session côté automate. Voir supervision humaine : la concevoir, pas la promettre. Cette journalisation rejoint d’ailleurs les livrables décrits dans ce que l’ingénieur doit livrer au titre de l’AI Act.

Les erreurs les plus graves avec un agent qui pilote un écran consistent à lui prêter une session humaine, à compter sur la consigne pour le borner et à lui confier une action irréversible sans validation. Toutes trois transforment une erreur d’interprétation en incident.

• Prêter sa propre session pour gagner du temps pendant les essais, puis la garder en production.
• Écrire « ne clique jamais sur valider » dans la consigne au lieu de retirer le droit de valider.
• Lancer sans plafond, ce qui laisse une boucle d’erreur répéter le même geste indéfiniment.
• Oublier la maintenance : une refonte de l’écran du progiciel suffit à dérégler l’automate, sans message d’erreur.

Avant d’ouvrir cette capacité sur un processus réel, un audit IA permet de cartographier les droits des comptes et les actions irréversibles concernées.

Lectures complémentaires : supervision humaine : la concevoir, pas la promettre. Ces liens complètent la navigation du site.

Le premier usage du pilotage d’écran doit préciser les droits, les actions autorisées, les risques d’injection, les traces et les possibilités de correction avant de démarrer.