Un agent qui sait envoyer un mail doit aussi savoir quand il n’a pas le droit

Le problème à résoudre avant l’outil

Un agent de suivi relance automatiquement un fournisseur puis utilise le même canal pour un dossier contentieux. Pris isolément, le cas semble facile. Mis dans un processus réel, il pose une autre question : le droit technique d’agir doit être plus précis que « accès à la messagerie ». Destinataire, contexte, type de contenu et validation peuvent changer le risque.

Un agent change la nature du risque parce qu’il peut agir, enchaîner des outils et répéter une action sans attendre une nouvelle consigne. Les bonnes pratiques habituelles restent utiles, à condition de traiter l’agent comme une identité active et non comme une simple fonction. Le système devient plus sûr quand ses actions sont bornées et explicables avant même qu’un incident apparaisse. Le nœud du problème tient dans cette phrase : Le droit technique d’agir doit être plus précis que « accès à la messagerie ». Destinataire, contexte, type de contenu et validation peuvent changer le risque. On peut alors gagner quelques minutes à l’écran et les reperdre dans l’étape suivante.

Commencer par le réel

Ce sujet ne sort pas d’une intuition isolée. Le NIST a ouvert en février 2026 un travail sur l’application des standards d’identité et d’autorité aux agents logiciels. Le sujet devient concret dès qu’un agent agit avec des droits propres dans plusieurs systèmes. La CNIL souligne que les agents capables d’accéder à plusieurs sources, de conserver une mémoire et d’agir au nom de l’utilisateur augmentent les flux de données, la complexité des responsabilités et les risques de perte de maîtrise sur les données personnelles. La bonne lecture consiste donc à garder les faits d’un côté et la décision de l’autre.

Je commencerais par un indicateur très concret : définir des classes d’actions et des seuils de validation humaine. Observe ce que l’équipe arrête de faire grâce à l’IA. Si rien ne disparaît, le nouvel outil s’est peut-être simplement ajouté au reste. Compare le résultat accepté, pas seulement la première sortie. Les reprises racontent souvent l’histoire que la démo ne montre pas.

Quatre contrôles simples

Attribuer une identité et des droits distincts à chaque agent qui agit réellement. Le but n’est pas d’ajouter une couche de procédure. C’est de rendre visible la décision qui existait déjà, souvent de manière implicite.

Limiter les actions à ce qui est nécessaire et imposer une validation pour les effets sensibles. La question redevient très terre à terre : que fait l’équipe quand le cas n’est pas propre ?

Journaliser suffisamment pour reconstruire une action sans transformer les logs en copie intégrale des données. Cette précaution sert à une chose très concrète : ne pas faire payer le gain de temps à l’étape suivante.

Tester les scénarios d’abus, l’arrêt d’urgence et la révocation des accès avant la mise en production. L’intérêt est surtout de créer un critère observable. Si personne ne peut dire si ce point est respecté, la règle restera décorative.

Le cas qui doit te faire arrêter

Le point faible d’un raisonnement rapide apparaît ici. Le niveau de contrôle doit suivre la conséquence possible, pas l’enthousiasme pour l’outil. Un agent de suivi relance automatiquement un fournisseur puis utilise le même canal pour un dossier contentieux. Le contexte métier reste donc plus important que la beauté de la démonstration.

Aucun contrôle unique ne garantit la sécurité d’un agent. Les mesures doivent être adaptées au périmètre, aux données, aux outils accessibles et aux conséquences possibles. Les scénarios d’abus et d’incident font partie du fonctionnement normal à préparer.

Une règle de sortie

La dernière question est celle qu’on pose rarement dans les démonstrations : définir des classes d’actions et des seuils de validation humaine. C’est moins spectaculaire qu’une démo, mais beaucoup plus utile pour faire tenir l’usage dans le temps.