Un agent IA ouvre une application, remplit un formulaire et trouve le bouton de validation. La démonstration prouve une capacité à interagir avec l’interface. Elle ne prouve ni le droit de transmettre les données saisies ni l’autorité nécessaire pour prendre la décision correspondante.
Cette distinction devient essentielle dès qu’un assistant peut agir sur des outils réels. La compétence technique et l’autorisation métier sont deux choses différentes. Un agent peut préparer une demande avec beaucoup d’efficacité tout en devant s’arrêter avant un achat, un engagement ou une modification dépassant son périmètre.
Définir l’action, pas seulement l’objectif
« Gérer mes réservations » laisse trop de décisions implicites. L’agent peut-il rechercher des options, remplir des champs, utiliser une carte enregistrée, accepter des conditions ou annuler une réservation existante ?
Ces étapes ne produisent pas les mêmes conséquences.
Décomposez le parcours en actions observables. Précisez les comptes utilisables, les données consultables, les destinataires et les limites de montant ou de périmètre. Une instruction claire doit aussi dire ce qu’il faut faire si aucune option ne respecte les critères. Sans cette règle, l’agent peut être tenté de choisir une approximation.
L’autorisation peut être donnée à l’avance pour un ensemble borné d’actions. Elle ne nécessite pas forcément une interruption à chaque clic. En revanche, un objectif général ne devrait pas devenir une permission illimitée dès que l’interface présente un nouveau choix.
La saisie peut déjà constituer une transmission
Le bouton final n’est pas toujours la seule frontière importante. Certains formulaires enregistrent les informations pendant leur saisie. Une recherche dans un service externe peut également lui transmettre des termes sensibles avant toute confirmation visible.
Définissez donc les catégories de données que l’agent peut envoyer et vers quels services. Préparer un brouillon local et remplir un champ dans un site tiers ne sont pas automatiquement équivalents. Le parcours doit tenir compte des mécanismes réels de l’application utilisée.
Les documentations techniques de pilotage informatique recommandent de borner l’environnement, de limiter les accès et de vérifier le résultat. Ces mesures complètent les consignes données au modèle.
Une restriction appliquée par l’application résiste mieux à une mauvaise interprétation qu’une phrase isolée dans un prompt.
Le contenu d’une page n’accorde aucun nouveau pouvoir
Un agent peut rencontrer un message demandant d’ignorer ses instructions, de transmettre un fichier ou de cliquer sur une autre adresse. Ce texte fait partie de l’environnement qu’il consulte ; il ne constitue pas une autorisation donnée par l’utilisateur ou l’organisation.
Même une page interne peut contenir du contenu provenant d’un tiers : courriel, commentaire, pièce jointe ou document importé. La source d’une instruction compte autant que ses mots. Il faut distinguer les informations nécessaires à la tâche des demandes qui tentent de modifier les règles de son exécution.
Réduisez les permissions aux besoins du parcours. Un agent chargé de préparer une réponse n’a pas systématiquement besoin d’un droit d’envoi ou d’administration. Cette limitation ne prétend pas empêcher toute erreur ; elle réduit les conséquences possibles d’une mauvaise lecture ou d’une instruction indésirable.
Prévoir une validation qui porte sur un résultat concret
Pour une action engageante, montrez ce qui va être fait : objet, destinataire, montant, données transmises et conditions pertinentes. Une demande vague de confirmation ne permet pas à l’utilisateur de contrôler efficacement la décision. L’agent doit avoir préparé les éléments nécessaires avant de demander l’arbitrage.
La validation doit correspondre à l’action finalement exécutée. Si le montant change ou si le destinataire est remplacé après l’accord, les conditions approuvées ne sont plus les mêmes. Le système doit reconnaître ce changement au lieu de considérer toute confirmation passée comme réutilisable sans limite.
Prévoyez aussi le cas où l’utilisateur refuse ou modifie le choix. L’agent doit pouvoir abandonner proprement, corriger le brouillon ou rendre la main. Savoir s’arrêter fait partie du fonctionnement attendu, au même titre que savoir terminer une procédure.
Vérifier l’état final et les effets partiels
Un clic réussi ne prouve pas que l’action a abouti. Le site peut afficher une erreur, créer un doublon après une nouvelle tentative ou enregistrer une partie des modifications. Vérifiez l’état final dans le service concerné, avec un identifiant ou un autre élément observable lorsque c’est possible.
Bornez le nombre d’étapes, la durée et les reprises. Une boucle de tentatives peut multiplier les transmissions ou les dépenses. En cas d’incertitude après une interruption, l’agent doit rechercher l’état de l’opération avant de la relancer, plutôt que de supposer qu’elle a échoué.
Conservez une trace adaptée des actions et de leur autorisation, en évitant de journaliser inutilement des secrets. Cette trace permet de comprendre un incident et de distinguer décision autorisée, action tentée et résultat constaté. La confiance utile repose sur cette séparation : l’agent agit dans un cadre défini, et son compte rendu décrit ce qui a réellement été vérifié.
