La demande de validation de votre agent IA est une frontière d’autorisation

C’est pourquoi une demande de validation doit être traitée comme une partie du modèle d’autorisations, et non comme une friction polie ajoutée une fois l’agent construit.

Les deux mauvais extrêmes

Le premier écueil consiste à faire confirmer chaque changement d’état. Ouvrir la page de facturation ? Confirmer. Choisir l’onglet annuel ? Confirmer. Saisir un nom d’entreprise ? Confirmer. Le produit a l’air prudent, mais ces demandes à répétition habituent les utilisateurs à valider par réflexe. Le système a produit un théâtre du consentement : beaucoup de clics, peu d’attention.

L’écueil inverse consiste à demander une seule fois, au départ. « Je vais faire le ménage dans l’espace de travail. Je continue ? » Cela paraît efficace, jusqu’à ce que la tâche s’étende à l’archivage d’enregistrements, au retrait de membres et à l’envoi d’un e-mail récapitulatif. L’utilisateur a validé un objectif, pas chacune de ses conséquences. Une instruction large, formulée en langage naturel, est devenue un rôle d’administrateur temporaire.

Ces deux échecs viennent du même choix : faire de la conversation la couche d’autorisation. La conversation sait établir une intention. Elle définit mal la capacité précise qui est accordée.

La taxonomie des modes de défaillance agentiques publiée par Microsoft en 2026 formule explicitement la version sécurité de cet argument. Elle recommande une revue humaine déterministe, une approbation distincte pour chaque sous-action lourde de conséquences, des descriptions tirées des appels d’outils sous-jacents, et des niveaux d’approbation fondés sur la réversibilité et le rayon d’impact. C’est l’application, et non le modèle, qui doit faire respecter la frontière.

Si modifier une phrase dans l’explication de l’agent peut décider de l’apparition ou non d’une validation, alors cette validation est pilotée par de la prose. Une vraie frontière d’autorisation est pilotée par l’action que l’application s’apprête à exécuter.

Classer la conséquence, pas le bouton

Les équipes commencent souvent par une liste de mots dangereux : supprimer, envoyer, payer, annuler. C’est utile, mais le libellé d’un bouton n’est pas une politique. « Annuler » peut fermer une boîte de dialogue ou résilier un abonnement. « Retirer » peut effacer un filtre ou révoquer l’accès d’une personne. « Continuer » peut être le dernier bouton d’un achat.

Pour classer une action, il faut l’action elle-même, sa cible et l’état qui l’entoure. Une politique pragmatique peut partir de cinq questions :

1. Cette action produit-elle un effet externe, comme un message, une invitation, une publication ou une modification mise en ligne ?

2. Déplace-t-elle de l’argent ou crée-t-elle un engagement financier ?

3. Change-t-elle qui peut accéder aux données, ou les autorisations dont chacun dispose ?

4. Supprime-t-elle des données, ferme-t-elle un compte ou modifie-t-elle un abonnement ?

5. En cas d’erreur, le même utilisateur peut-il revenir en arrière rapidement et complètement ?

On obtient ainsi une frontière bien plus utile que « toute écriture doit être confirmée ».

Action proposée · Comportement par défaut · Pourquoi

Lire une page, rechercher, filtrer ou ouvrir un onglet · Continuer · Aucun effet externe durable

Remplir un champ de brouillon non sensible · Continuer en gardant l’action visible · Réversible avant l’envoi

Modifier une préférence locale facile à annuler · Continuer, en général · Rayon d’impact réduit et retour en arrière facile

Envoyer, publier, inviter, partager ou modifier un accès · Faire valider l’action exacte · Touche une autre personne ou franchit une frontière

Acheter, passer à une offre supérieure, résilier, clôturer ou supprimer · Faire valider juste avant l’exécution · Financier ou difficile à annuler

Saisir des identifiants ou prendre une décision réglementée · Exiger le contrôle direct de l’utilisateur, ou refuser · Une validation ne rend pas toute action délégable pour autant

C’est proche du modèle de risque des outils décrit dans le guide d’OpenAI pour concevoir des agents, qui recommande d’évaluer chaque outil selon l’accès en écriture, la réversibilité, les autorisations du compte et l’impact financier. L’essentiel est de traduire ces propriétés en code et en politique, et non en une consigne de plus que le modèle pourrait interpréter avec créativité.

Demander au moment de la conséquence

La validation doit apparaître le plus tard possible, mais avant l’effet externe.

Prenons la demande « Résiliez mon abonnement Growth ». L’agent peut ouvrir les paramètres, aller dans la facturation et consulter l’offre en cours sans interrompre l’utilisateur. Aucune de ces étapes ne l’engage. La validation utile apparaît quand l’agent a trouvé le vrai bouton Résilier l’abonnement et sait quel abonnement il concerne.

À ce moment-là, la demande de validation dispose de faits concrets. Elle peut nommer l’action et la cible au lieu de paraphraser la demande initiale. Elle évite aussi de faire valider une opération que l’agent ne parviendra peut-être même pas à trouver.

La distinction est nette :

– La clarification intervient quand l’action voulue ou sa cible est ambiguë. « Retirez Alex » appelle une question si deux membres s’appellent Alex.

– La validation intervient quand l’action voulue est claire et que l’application est prête à exécuter une étape lourde de conséquences. Elle doit se limiter à un choix fermé : Accepter ou Refuser.

Mélanger les deux produit des conversations exaspérantes. L’agent demande « Êtes-vous sûr ? » alors qu’il ne sait toujours pas de quel enregistrement parlait l’utilisateur. Ou bien il recueille d’abord l’accord, tombe plus tard sur un autre bouton de confirmation, et traite la réponse précédente comme une autorisation pour cette nouvelle action.

La séquence la plus sûre est la suivante : intention, résolution de la cible, validation, exécution. Une confirmation demandée ensuite par le site est une nouvelle action exécutable, qui mérite sa propre décision.

La demande doit décrire l’action exécutable

Un agent peut dire « Je range simplement l’espace de travail » alors que son prochain appel d’outil retire un membre. Que ce décalage soit malveillant, injecté ou simplement une erreur ne change rien. L’interface de validation ne peut pas se fier au récit de l’agent pour décrire l’autorité qu’il réclame.

Construisez plutôt le texte de validation à partir de l’objet d’exécution. Affichez l’élément d’interface, la cible, la valeur sélectionnée, la destination et le périmètre concerné, tels que l’application les a résolus. « Cliquer sur Supprimer le compte pour Acme » est utile. « Poursuivre le nettoyage » ne l’est pas.

La taxonomie de Microsoft appelle la version faible le « blanchiment de description » : l’agent présente un résumé anodin qui masque une action sous-jacente plus lourde de conséquences. La parade proposée est simple : générer la description de validation à partir de l’appel d’outil réel ou de l’élément de la page, et non à partir d’un texte libre produit par le modèle.

C’est important même quand personne n’attaque le système. Les modèles compressent. Ils omettent des nuances. Ils désignent le mauvais objet d’un simple « ça ». La couche d’exécution dispose déjà des arguments exacts : la validation doit s’en servir.

– Elle apparaît parce qu’une politique déterministe a classé l’action exécutable, pas parce que le modèle a bien voulu demander.

– Elle nomme l’action, la cible, la destination et le périmètre dans des termes que l’utilisateur peut vérifier.

– Elle offre une vraie possibilité de refus et ne noie pas l’étape lourde de conséquences dans un lot.

– Elle autorise une seule tentative, pas toute la suite de la conversation.