Quelles actions de vos agents doivent vraiment être validées ?

Votre agent de développement demande une autorisation avant de modifier un fichier.

Le même type d'agent peut déjà avoir le droit de lire une boîte mail privée, d'utiliser un navigateur connecté ou d'appeler un outil externe.

La demande visible porte sur le verbe. Le risque réel peut être ailleurs.

C'est ainsi qu'une entreprise finit par faire valider des modifications sans danger, tout en examinant à peine des autorisations permanentes beaucoup plus larges. « Modifier » paraît lourd de conséquences. « Lire » paraît sûr. Un déploiement peut être annulé. Un droit d'accès peut être retiré. Aucun de ces verbes ne suffit à décider où une personne doit intervenir.

Le cadre de gouvernance de l'IA agentique publié par l'IMDA à Singapour rend le problème très concret dans l'une de ses études de cas. CodeBuddy, l'outil de Tencent, ne demande pas d'autorisation pour lire des fichiers. Il en prévoit pour les modifications, les commandes système, les requêtes réseau et les outils externes. La durée varie elle aussi : une session, un projet, une commande, ou une nouvelle validation lorsqu'une action devient suspecte.

C'est déjà plus utile que de répéter qu'il faut « garder un humain dans la boucle ». La vraie question est de savoir où cette boucle doit se refermer.

Mais il reste le plus difficile : comment classer une action avant qu'un incident ne vous donne la réponse ?

Le raccourci que nous avons testé

La règle la plus simple est la réversibilité.

Si l'effet complet d'une action ne peut pas être annulé, elle doit être validée. Envoyer un message, effectuer un paiement et publier une page entrent dans cette catégorie. Pour une suppression, on peut adopter une règle plus stricte : l'agent prépare, une personne exécute.

Si l'effet peut être annulé, l'agent agit et laisse une trace.

Cette règle est séduisante parce qu'elle est facile à appliquer. Elle a aussi une base solide. L'IMDA classe les actions irréversibles parmi les étapes importantes qui doivent faire intervenir une personne. Le cadre cite notamment la suppression définitive de données, l'envoi de communications et les paiements.

Nous avons comparé ce raccourci à un second modèle, celui du Citizen SDLC de Tenex. Tenex évalue le rayon d'impact selon quatre dimensions :

1. la portée et les capacités : à quels systèmes l'action accède-t-elle, et peut-elle lire, écrire ou exécuter ?
2. la réversibilité et l'autonomie : l'effet peut-il être annulé, et quelle part du chemin l'agent choisit-il seul ?
3. l'exposition : qui voit le résultat, et jusqu'où circule-t-il ?
4. la sensibilité des données : quelle information l'action touche-t-elle ?

Nous avons ensuite recensé 28 catégories d'actions dans un système opérationnel réel qui effectue des recherches, prépare des contenus, publie, observe les réponses et tient à jour des données commerciales. Chaque catégorie a été évaluée deux fois. Dans le modèle à quatre dimensions, toute valeur ÉLEVÉE déclenchait une limite d'autorisation. Les seuils et l'inventaire complet sont conservés avec le résultat.

Les deux règles n'ont pas retenu le même ensemble.

La réversibilité seule a sélectionné 11 catégories sur 28.

Le modèle à quatre dimensions en a sélectionné 19 sur 28.

Huit catégories réversibles ont franchi un autre seuil. La réversibilité a donc laissé de côté 42 % des actions retenues par le modèle complet.

Les actions réversibles qui changent le résultat

Trois exemples suffisent à voir le mécanisme.

Lire une boîte mail privée. L'action ne modifie rien. Au sens strict, elle est totalement réversible. Mais la sensibilité des données est élevée. La bonne limite n'est pas une demande avant chaque message. C'est une autorisation permanente mais délimitée à des comptes, des champs et des finalités précises, avec une trace de chaque accès.

Modifier des droits. Un droit peut être retiré. Cela ne rend pas le changement bénin. Tant qu'il existe, il élargit ce que l'agent, ou une autre identité, peut atteindre. Une autorisation puissante mais révocable mérite toujours une validation exacte, voire une exécution humaine.

Déployer du code versionné. Un retour arrière est possible. Une règle fondée uniquement sur la réversibilité peut donc laisser passer l'action. Pourtant, la portée en production et l'exposition publique restent élevées. La bonne limite peut être une version précise, validée en amont et déployée par une chaîne contrôlée, plutôt qu'une personne sollicitée pour chaque commande de compilation.

Cinq autres catégories produisent le même désaccord : lire des identifiants ou utiliser une session déjà connectée, lancer des commandes système ou piloter un ordinateur sans périmètre étroit, écrire des données relationnelles personnelles dans un outil commercial, modifier les règles qui gouvernent les agents futurs, et changer une tâche récurrente.

Toutes peuvent être annulées. Toutes peuvent causer un dommage réel avant de l'être.

C'est ce que le raccourci ne voit pas. La réversibilité mesure la possibilité de récupérer. Une règle d'autorisation doit aussi mesurer le pouvoir accessible pendant l'intervalle qui précède cette récupération.

Une autorisation n'est pas un bouton unique

Le débat habituel propose deux mauvaises options : demander une validation à chaque fois, ou supprimer toute validation.

La comparaison fait apparaître cinq états plus utiles :

1. Automatique et journalisé. À utiliser lorsque les quatre dimensions restent dans les limites convenues.
2. Autorisation permanente et délimitée. Une personne valide une fois un outil, une source de données, un compte ou une catégorie de commandes stable. Le système surveille ensuite la limite, pas chaque exécution.
3. Validation exacte en amont. Le texte, la version ou l'élément précis est validé avant l'exécution, qui peut ensuite être automatique et fidèle.
4. Validation à chaque action. Pour les messages externes, les commandes inhabituelles et les engagements dont le contexte change à chaque fois.
5. Exécution humaine uniquement. L'agent prépare, mais ne peut pas agir. La suppression peut rester ici.

Cette structure évite la file d'attente de validations décrite par Tenex, sans prétendre que toute action annulable est sûre. La personne intervient sur la limite. Une règle déterministe traite ensuite le chemin courant.

Les quatre questions à utiliser lundi

Recensez des actions, pas des métiers ni des noms d'agents. « Agent de service client » est trop large. « Lire la fiche d'un client », « modifier l'adresse de livraison », « déclencher un remboursement » et « envoyer la confirmation » sont quatre lignes différentes.

Pour chaque ligne, demandez-vous :

1. À quoi cette action peut-elle accéder, et que peut-elle modifier ?
2. Son effet complet peut-il être annulé, y compris les obligations créées et ce qu'une autre personne a déjà vu ?
3. Qui peut recevoir ou observer le résultat ?
4. L'action touche-t-elle des échanges privés, des données personnelles, des opérations confidentielles, des secrets ou des données réglementées ?

Si une réponse franchit votre seuil élevé, placez une limite d'autorisation avant cette catégorie d'actions. Si aucune ne le franchit, autorisez l'exécution dans un périmètre nommé et conservez une trace. Si l'action est nouvelle ou difficile à classer, refusez-la par défaut jusqu'à ce qu'elle le soit.

Le seuil est une décision d'exploitation, pas une constante universelle. Un prototype fondé sur des données synthétiques, sans identifiants de production, ne doit pas hériter des mêmes réglages qu'un système capable d'atteindre la paie, les clients ou l'infrastructure.

Le principe est plus modeste, et plus solide :

La réversibilité est un veto, pas un classement complet.

Si une action ne peut pas être entièrement annulée, elle exige un point de contrôle. Si elle peut l'être, il reste encore trois questions.