Quand « Prendre le contrôle » ne donne pas la main

Imaginez un agent en train de travailler dans un navigateur. Il arrive sur une page de connexion qui demande votre intervention. Vous ouvrez son bureau, cliquez sur « Prendre le contrôle » et commencez à saisir vos identifiants. Que pensez-vous avoir obtenu en cliquant ?

Vous vous attendez probablement à disposer de l’interface sans que l’agent continue à cliquer ou à lire par un autre chemin. Si votre connexion se coupe, vous n’avez pas nécessairement décidé de lui rendre la main. Et si l’écran est présenté comme étant en direct, vous vous attendez à voir son état actuel.

Ce scénario illustre les questions que j’ai examinées dans Bot Screen, une fonctionnalité d’Hermes Agent permettant de prendre puis de restituer le contrôle du bureau de l’agent. Le 12 septembre, Teknium m’a invité à la revoir. J’ai publié une revue de l’interaction humain–agent, avec cinq problèmes et deux remarques de conception. Il a reproduit les cinq signalements et documenté leurs corrections. La fonctionnalité a été fusionnée le 23 septembre.

L’intérêt de ce cas tient à ce qu’une action simple pour l’utilisateur exige de plusieurs parties du système. « Prendre le contrôle » engage les outils, les captures, la connexion et les indications affichées.

Trois questions derrière un bouton

J’ai abordé cette revue en ergonome : quelle situation l’interface donne-t-elle à comprendre, quelles actions restent possibles et sur quoi la personne peut-elle s’appuyer pour poursuivre son travail ?

Trois questions ont guidé l’analyse. Qui peut réellement agir après la reprise en main ? Que peut encore observer l’agent ? Et quel état du système la personne croit-elle voir ?

Pour les examiner, j’ai utilisé des sondes de régression assistées par IA, portant sur des composants réels avec des doublures aux frontières précisées dans la revue. Ce travail n’était pas une étude utilisateurs ni une campagne d’essais du bureau Xfce en conditions réelles. Les corrections et les vérifications en environnement réel rapportées dans les réponses sont celles du mainteneur.

Cette distinction permet de suivre les responsabilités : j’ai formulé et documenté les problèmes ; le mainteneur les a reproduits, corrigés et vérifiés de son côté.

1. Le navigateur offrait encore un autre chemin

La reprise en main pouvait bloquer un chemin d’action sans bloquer les outils du navigateur partagé. L’agent pouvait donc encore lire ou agir dans ce navigateur alors que la personne en détenait le contrôle.

Pour l’utilisateur, il s’agit du même espace de travail. Il n’a aucune raison de connaître les différences entre l’outil qui pilote le bureau et celui qui commande directement le navigateur. Une protection limitée au premier chemin ne suffit pas à donner au bouton le sens attendu.

La correction documentée a appliqué la vérification du contrôle aux commandes locales concernées du navigateur partagé, avec invalidation des résultats lorsque le contrôle change. Le mainteneur a rapporté que les commandes de clic et de lecture étaient refusées pendant le contrôle humain, puis de nouveau possibles après restitution.

La question d’ergonomie a ainsi conduit à examiner un accès situé derrière l’interface visible.

2. Une capture pouvait traverser toute l’intervention

Un second problème concernait le temps. Une capture pouvait commencer lorsque l’agent avait la main, traverser une prise de contrôle humaine puis une restitution, et revenir alors que l’agent avait de nouveau la main.

Vérifier uniquement qui détient le contrôle à la fin manque ce qui s’est produit entre les deux états. Le détenteur initial et le détenteur final peuvent être identiques alors qu’une intervention humaine a eu lieu.

La correction s’appuie sur le changement d’époque du contrôle : le résultat est écarté si la capture traverse une transition. Cela donne au système une manière de tenir compte du passage humain, même lorsque celui-ci est déjà terminé au retour de l’opération.

C’est une propriété importante des interactions avec des systèmes asynchrones. L’état affiché au présent ne raconte pas nécessairement les transitions qu’une opération a traversées.

3. Une coupure pouvait être interprétée comme une restitution

La connexion du spectateur pouvait tomber pendant l’intervention humaine. Le comportement signalé rendait alors le contrôle à l’agent, qui pouvait reprendre au milieu d’une connexion inachevée.

Une perte de réseau ne renseigne pas sur l’intention de la personne. Elle peut encore être en train de travailler, essayer de rétablir l’affichage ou simplement chercher à comprendre ce qui vient de se passer.

La réponse du mainteneur distingue les fermetures normales de la coupure inattendue. Dans le cas involontaire vérifié, l’exclusion humaine reste en place. La disparition de la connexion ne suffit plus à faire reprendre l’agent.

La continuité de cette exclusion préserve une décision que la personne avait effectivement prise, sans lui en attribuer une nouvelle à partir d’un événement technique.

Schéma explicatif des chemins couverts après correction, pas une capture du produit. Les actions déjà en cours ne sont pas drainées ; ce mécanisme ne constitue pas une isolation au niveau du système d’exploitation.

4. Une ancienne image pouvait encore sembler actuelle

Lorsque les rafraîchissements échouaient, l’interface pouvait continuer à présenter la dernière image comme étant en direct. L’image existait bien ; c’était son statut temporel qui était trompeur.

Une personne peut s’appuyer sur cette indication pour décider d’attendre, de reprendre la main ou de considérer que l’agent poursuit son travail. La fraîcheur de l’information participe donc à la décision, même si l’image n’a rien d’anormal visuellement.

La correction atténue l’image après plusieurs échecs et signale qu’il s’agit du dernier état vu, l’écran étant devenu injoignable. L’information conservée reste utile, avec une indication de ce qu’elle permet encore de conclure.

Ce point rappelle que la lisibilité d’un état dépend aussi de sa date et des conditions dans lesquelles il a été obtenu.

5. Un événement pouvait concerner le mauvais hôte

Deux hôtes pouvaient utiliser le même chemin de profil. Un événement provenant de l’un pouvait alors modifier l’état de contrôle affiché pour l’autre, parce que la correspondance reposait sur ce seul chemin.

Le signalement portait sur un état affiché erroné. Il ne démontrait pas un transfert de saisie, de cookies ou de vidéo entre les hôtes.

La correction associe l’identifiant de connexion et le profil pour déterminer à quel écran appliquer l’événement. La personne doit pouvoir rattacher une indication de contrôle au bon environnement, même lorsque les installations se ressemblent.

Pour une équipe, cela donne un scénario de revue concret : ouvrir deux environnements qui partagent les mêmes noms ou chemins et examiner à quel endroit leurs événements se reflètent.

Ce que la revue permet d’affirmer

Dans sa réponse publique, Teknium confirme avoir reproduit les cinq problèmes et détaille leur traitement. Les deux remarques de conception sont distinctes. L’une concernait le motif de l’intervention ; le mécanisme associé a ensuite été retiré. Il serait donc inexact de compter sept fonctionnalités livrées.

La portée du contrôle reste également précise. Le mainteneur a conservé l’absence d’attente de fin des actions déjà en cours lors d’une reprise en main. La coordination des chemins d’outils couverts ne crée pas une séparation de sécurité entre processus partageant le même compte système.

Ces limites appartiennent à la compréhension de la fonctionnalité. Elles évitent de transformer des corrections vérifiables en promesse générale de confidentialité.

Une contribution de conception qui atteint le fonctionnement du système

La revue partait de ce qu’une personne peut comprendre et faire. Elle a conduit à examiner les accès aux outils, le temps des captures, les déconnexions et l’identité des environnements.

Pour une équipe qui développe un agent, une question féconde consiste à prendre une action importante de l’interface et à suivre ses conséquences dans le système. Que doit signifier cette action pour la personne ? Quels chemins doivent respecter ce sens ? Que devient-il pendant une coupure, une attente ou une reprise ?

Ce cas montre le type de contribution que je souhaite poursuivre : une revue ciblée, des problèmes examinables et des recommandations discutées avec les personnes qui construisent le produit.

Si vous développez un parcours de délégation, de supervision ou de reprise en main, vous pouvez me proposer une fonctionnalité à revoir. Le point de départ peut être aussi simple qu’un bouton dont nous voulons vérifier ensemble toutes les implications.