Human-in-the-loop, automatisé : l'autorisation asynchrone pour les actions d'agent à fort enjeu
Cet article fait partie de la série Les défis d’authentification et d’autorisation de l’IA agentique.
Certaines actions d’agent peuvent raisonnablement être prises de façon autonome. D’autres — rembourser un client, déployer en production, déplacer de l’argent — méritent réellement qu’un humain dise oui à cette action précise, pas seulement à l’existence de l’agent en général. Le problème est structurel : le moment où un agent décide qu’il a besoin de cette approbation est rarement celui où un humain se trouve justement devant un écran. C’est la faille de consentement, et la façon dont on la comble en dit long sur le fait que le « human-in-the-loop » soit un contrôle réel ou une décoration de conformité.
Pourquoi la solution évidente ne fonctionne pas
La solution évidente est un écran de consentement unique : lors de la configuration initiale de l’agent, demander à l’utilisateur de l’approuver largement — « autoriser cet agent à gérer votre calendrier, envoyer des e-mails et traiter des remboursements en votre nom » — puis le laisser tourner sans surveillance par la suite. Cela satisfait techniquement « l’utilisateur a consenti », mais de la même façon qu’un CGU : large, générique, accordé une fois, et fonctionnellement dénué de sens comme contrôle continu. Cela ne distingue pas l’agent qui replanifie une réunion de l’agent qui émet un remboursement de 2 000 €. Une fois accordé, il ne peut pas être retiré pour une action précise sans révoquer l’ensemble.
L’échec inverse est tout aussi courant : exiger une approbation synchrone, en session, pour chaque action sensible, ce qui ne fonctionne que si l’utilisateur se trouve justement en train d’utiliser activement l’application au moment précis où l’agent a besoin de la réponse. Une grande partie de la valeur des agents vient précisément du fait de ne pas exiger cela — traitement en arrière-plan, workflows en plusieurs étapes, actions qui se terminent des minutes ou des heures après que l’utilisateur a regardé quoi que ce soit pour la dernière fois. Un modèle de consentement qui ne fonctionne que de façon synchrone repousse discrètement les équipes vers la case à cocher large et unique, car c’est la seule façon de garder l’agent utile.
Le pattern : l’autorisation asynchrone et découplée
La réponse basée sur les standards ici est un flux d’authentification découplé — défini par l’OpenID Foundation sous le nom de Client-Initiated Backchannel Authentication — qui permet à un client (le backend de l’agent, dans ce cas) de demander l’autorisation de l’utilisateur sans que celui-ci soit présent dans la même session, ni même sur le même appareil, que la requête. Le backend de l’agent envoie la demande d’autorisation au serveur d’autorisation ; le serveur pousse une notification vers l’appareil séparé et de confiance de l’utilisateur — un téléphone avec une application d’authentification, typiquement — où l’utilisateur examine et approuve ou refuse ; le backend de l’agent interroge (ou est notifié) du résultat et poursuit une fois l’approbation obtenue.
Trois modes de livraison sont définis, chacun adapté à une architecture d’agent différente : poll, où le client vérifie périodiquement si une décision a été prise — simple, et un choix par défaut raisonnable pour la plupart des backends d’agent ; ping, où le serveur d’autorisation notifie le client qu’une décision est prête, réduisant le trafic de vérification inutile ; et push, où le résultat complet est livré directement au client, minimisant la latence dans les cas où la rapidité compte le plus. Aucun de ces modes n’exige que l’utilisateur soit sur le même écran, ni même le même appareil, que l’agent qui a déclenché la requête — ce qui est précisément l’intérêt du mécanisme.
Rendre l’approbation véritablement signifiante : les Rich Authorization Requests
Un flux d’approbation découplé ne résout que la moitié du problème. Si la notification reçue par l’utilisateur se contente de dire « autoriser l’accès ? », on retombe dans le problème du consentement vide de sens, simplement étalé dans le temps plutôt qu’accordé une fois pour toutes en amont. L’autre moitié, ce sont les Rich Authorization Requests (RAR, RFC 9396), une extension d’OAuth qui permet à une demande d’autorisation de porter des authorization_details structurés et précis plutôt qu’une simple chaîne de scope.
La différence en pratique, c’est la différence entre une notification qui dit « autoriser l’agent à accéder à la facturation ? » et une autre qui dit « approuver un remboursement de 2 000 € à la cliente Jane Doe pour la commande #12345 ? ». La seconde constitue un consentement réel, signifiant et non répudiable — l’utilisateur approuve une action précise et décrite, pas une catégorie d’accès qui se trouve l’inclure. Quand ces deux éléments sont combinés — authentification découplée portant une charge d’autorisation riche et structurée — on obtient un flux d’approbation qui fonctionne de façon asynchrone et produit un enregistrement d’audit précis de ce qui a été approuvé, en des termes suffisamment spécifiques pour tenir la route si quelqu’un demande plus tard si l’agent a dépassé la permission qui lui avait été accordée.
Recommandations de conception
Réservez ce pattern aux actions véritablement à fort enjeu, pas à tout. La valeur d’une invite d’approbation est inversement proportionnelle à sa fréquence de déclenchement. Si chaque action d’agent — y compris les actions routinières et à faible risque — déclenche une notification push, le pattern dégénère exactement dans la fatigue d’approbation qu’il était censé éviter, simplement à l’échelle de l’action plutôt qu’une fois pour toutes. Décidez délibérément quelles catégories d’action franchissent le seuil de l’approbation explicite (actions irréversibles, transactions financières au-dessus d’un seuil, tout ce qui touche à l’infrastructure de production) et laissez l’agent opérer de façon autonome dans le scope déjà accordé pour tout le reste.
Rendez chaque demande d’approbation suffisamment précise pour constituer une véritable décision. Si la charge d’autorisation structurée pouvait être satisfaite par plus d’une action que l’agent pourrait plausiblement entreprendre, elle n’est pas assez précise. « Approuver une transaction » n’équivaut pas à « approuver un remboursement de 2 000 € pour la commande #12345 » — seule la seconde formulation donne à l’humain quelque chose de concret à évaluer, et seule elle produit un enregistrement montrant sans ambiguïté ce qui a été approuvé si le comportement réel de l’agent est remis en question plus tard.
Concevez explicitement le cas d’absence de réponse. L’approbation asynchrone signifie que l’humain pourrait ne jamais répondre — occupé, endormi, téléphone déchargé. Décidez en amont de ce que fait l’agent après un timeout : la tâche échoue-t-elle proprement, est-elle mise en file pour une nouvelle tentative, escaladée vers un autre approbateur, ou expire-t-elle purement et simplement ? Laisser ce point indéfini tend à produire des systèmes qui restent bloqués indéfiniment ou qui poursuivent silencieusement sans approbation, ce qui annule tout l’intérêt du mécanisme.
Journalisez la charge approuvée aux côtés de ce qui a réellement été exécuté. La valeur d’une demande d’approbation riche et structurée ne tient pas seulement à la meilleure expérience utilisateur sur le moment — c’est qu’on dispose désormais d’un enregistrement lisible par machine de ce qui a été exactement approuvé, comparable après coup à ce que l’agent a exactement fait. Si ces deux éléments peuvent diverger (l’agent obtient l’approbation pour un montant de remboursement et, à cause d’un bug ou d’un changement ultérieur de contexte, en exécute un autre) et que personne ne les compare, le journal d’audit est décoratif plutôt que fonctionnel.
Soyez honnête sur le coût en UX et en infrastructure. Ce pattern exige un canal hors bande fiable et joignable vers l’utilisateur — typiquement un appareil enregistré avec une application d’authentification compatible push, ou un numéro de téléphone, ou une adresse e-mail vérifiée que l’utilisateur surveille réellement. Mettre cela en place représente une vraie infrastructure, pas une case à cocher, et c’est en partie pourquoi ce pattern doit rester réservé au petit ensemble d’actions véritablement sensibles plutôt qu’à tout ce que fait un agent.
Bien mis en œuvre, c’est le mécanisme qui permet au « human-in-the-loop » de signifier davantage qu’une formule marketing : non pas un humain qui surveille chaque action, mais un humain qui donne son accord de façon spécifique et vérifiable sur la poignée d’actions où cela compte, en des termes suffisamment précis pour constituer une véritable preuve de ce à quoi il a consenti.
Prochain article de la série : Au-delà de l’écran de consentement : la confiance agent-à-agent et agent-à-application, qui traite de ce qu’il advient du consentement et de la délégation dès lors que des agents commencent à accéder à des applications et à d’autres agents au-delà de ceux que vous contrôlez directement.