Piloter un écran ne vaut pas droit de tout cliquer

Un modèle capable de lire un écran et de cliquer accède à des applications qui n'exposent aucune interface programmable. C'est le verrou qu'il fait sauter, et il est réel dans la plupart des grandes organisations.

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 c'est aussi la plus large jamais accordée à un système automatique : 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. 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 la seule barrière qui tienne.

Un système qui lit l'écran peut être influencé par ce qui y est affiché, y compris par un texte placé là pour lui. 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. La distinction entre l'interface et son contenu n'existe pas pour lui.

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.

La parade reste la même et elle est la seule : restreindre les droits du compte. Aucune consigne, aussi bien rédigée soit-elle, ne remplace une interdiction technique, le principe posé dans quand un modèle commence à agir.

Les usages qui tiennent sont ceux où le geste est répétitif, borné et vérifiable a posteriori. Les autres 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.

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, une validation indue, l'organisation ne peut pas démontrer ce qui s'est réellement produit.

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.