Un agent n’est pas une simple extension de l’utilisateur
Le modèle le plus simple consiste à laisser l’agent emprunter les droits de la personne qui l’a déclenché. C’est aussi celui qui rend la traçabilité impossible dès que l’agent gagne en autonomie.
Dans un système d’information ordinaire, l’identité est une notion stable. Un collaborateur possède un compte, ce compte porte des droits, ces droits s’accordent, se modifient et se révoquent, et chaque action se rattache à quelqu’un. Un agent met ce modèle en défaut sur deux points : l’étendue des droits qu’il mobilise, et la lisibilité de ce qu’il a fait.
Le raisonnement de l’héritage paraît pourtant logique : si un collaborateur peut consulter un document, son assistant devrait pouvoir le consulter pour lui. Il devient problématique pour deux raisons distinctes. La première tient au périmètre : un collaborateur accumule au fil des projets et des changements de poste des permissions dont la mission de l’agent n’a aucun besoin, et les lui transmettre en bloc élargit inutilement sa surface d’action. La seconde tient à la lecture des traces : si une modification apparaît dans le CRM sous l’identité du collaborateur, plus rien ne distingue ce qu’il a fait lui-même de ce que son agent a fait pour lui.
L’identité de l’agent relève donc de l’architecture, pas du détail d’implémentation.
Les agents deviennent une catégorie d’identité à part entière
Microsoft Entra Agent ID est passé en disponibilité générale. Microsoft le présente comme une couche de gestion des identités et des accès conçue spécifiquement pour les agents IA, destinée à les authentifier, les autoriser, les gouverner et les protéger à l’échelle de l’entreprise. Cette disponibilité générale porte sur le socle : une partie des expériences d’administration, dont l’assistant de création d’identités dans le centre d’administration Entra, reste annoncée en préversion.
Le glissement est notable. Les agents cessent d’être vus comme des fonctionnalités à l’intérieur d’applications pour devenir des entités auxquelles on peut rattacher une identité propre, et donc des permissions, des règles de sécurité et une responsabilité.
Nous prenons cet exemple parce qu’il est documenté publiquement et donc vérifiable, non parce qu’il constituerait la seule réponse possible. Le problème posé par l’identité des agents dépasse un éditeur, et le raisonnement qui suit vaut quel que soit l’outillage retenu.
Un identifiant ne suffit pas, il faut savoir à quoi il correspond
Attribuer un identifiant unique à chaque agent est la partie facile. Ce qui compte est ce que l’organisation sait de cet identifiant : qui en est responsable, pour quelle finalité l’agent a été créé, quelles ressources il peut consulter, quelles actions il peut effectuer, combien de temps il doit rester actif, et dans quelles circonstances ses accès doivent être retirés.
Le modèle de Microsoft répond à cette question par des relations administratives attachées à chaque identité d’agent, réparties entre trois rôles distincts. Le propriétaire est l’administrateur technique : il installe l’identité, la configure et gère ses secrets d’authentification. Le sponsor porte la responsabilité métier : il répond de la finalité de l’agent et des décisions de cycle de vie, revues d’accès et maintien en service compris, sans disposer pour autant des droits d’administration techniques. Le manager, enfin, rattache l’agent à la hiérarchie de l’organisation et peut demander des accès pour lui, sans pouvoir le modifier ni le supprimer.
Le détail le plus instructif se trouve dans les contraintes de création. Un sponsor est obligatoire dès la création d’une identité d’agent, alors que le propriétaire et le manager restent facultatifs. Un agent peut donc exister sans administrateur technique désigné, mais pas sans responsable métier identifié. Nous y voyons le bon arbitrage : la défaillance à redouter n’est pas l’absence de compétence technique, qui finit toujours par se voir, mais l’absence de quelqu’un capable de dire pourquoi cet agent existe encore. C’est exactement la chaîne de responsabilité que décrit notre décryptage sur la gouvernance des agents.
Ce que l’identité rend possible : le moindre privilège, puis l’audit
Prenons un agent chargé de préparer les rendez-vous commerciaux du lendemain. Sa mission suppose de lire quelques événements du calendrier, certaines informations du CRM et les documents liés aux comptes concernés. Elle ne suppose ni de modifier toutes les opportunités, ni d’exporter la base clients, ni d’écrire à l’extérieur de l’entreprise. Avec une identité propre, ce périmètre se décrit et s’applique réellement ; sans elle, il reste une intention. C’est la condition pratique du principe du moindre privilège appliqué aux agents.
Le second bénéfice apparaît après coup, au moment où l’on cherche à comprendre. Si tous les agents partagent des comptes techniques génériques, une trace indique seulement qu’une application a agi. Si chacun possède son identité, la reconstitution devient possible : agent X, pour l’utilisateur Y, action Z, sur la ressource W, à l’heure T. Cette chaîne devient déterminante à mesure que les agents se multiplient dans le SI, faute de quoi l’entreprise fabrique une nouvelle génération de comptes techniques dont plus personne ne sait qui les utilise.
La vraie difficulté arrive après : que deviennent les accès d’un agent oublié ?
Un collaborateur change de poste. Un projet s’arrête. Une application est remplacée. Un agent expérimental n’intéresse plus personne. Que deviennent ses accès ?
Les entreprises connaissent déjà ce problème avec les comptes de service oubliés. Les agents peuvent l’amplifier, précisément parce que leur création devient facile et décentralisée : ce qui s’obtient en quelques minutes se multiplie sans qu’aucune revue ne suive. L’identité agentique doit donc embarquer un cycle complet, de la création à la révocation, en passant par l’attribution d’un responsable et une revue périodique des permissions.
Le point de rupture le plus prévisible est le départ de ce responsable. Microsoft documente à ce titre des flux de cycle de vie qui réattribuent le parrainage lorsqu’un sponsor change de fonction ou quitte l’organisation, avec pour objectif explicite d’éviter les agents orphelins. L’outillage confirme ici le diagnostic : authentifier un agent aujourd’hui est le problème facile, savoir qui en répondra dans six mois est le problème réel.
Après les personnes et les applications, une troisième population à gérer
Les annuaires d’entreprise ont longtemps distingué deux populations : les personnes, et les identités techniques rattachées à des applications. Les agents ne se rangent proprement ni dans l’une ni dans l’autre. Ils empruntent aux secondes leur caractère non humain, mais ils agissent tantôt pour un utilisateur, tantôt pour une équipe, tantôt pour un processus, et pour des durées qui vont de l’appel ponctuel au service permanent. Ils peuvent surtout déléguer à d’autres agents, ce qui déplace la question : il ne suffit plus de savoir quels droits détient un agent, il faut savoir jusqu’où ces droits se propagent. C’est le sujet de notre décryptage sur les architectures multi-agents.
À retenir
La question technique en recouvre une plus élémentaire :
Si un agent peut agir dans votre entreprise, êtes-vous capable de dire précisément qui il est, pourquoi il dispose de ses droits, et ce qu’il en a fait ?
À mesure que l’autonomie progresse, cette capacité cesse d’être un confort d’exploitation pour devenir une condition d’industrialisation.
