La question arrive toujours au même moment. L'agent fonctionne, il rend service, et il faut maintenant le brancher sur un système réel : la messagerie, l'outil de gestion, l'espace de documents. Alors quelqu'un demande, très raisonnablement : « on lui met quel compte ? »
Trois réponses circulent. La première est de lui prêter un compte utilisateur existant — souvent celui de la personne qui l'a construit. La deuxième est de créer un compte de service, comme on le fait depuis vingt ans pour un traitement de nuit. La troisième est apparue cette année et vient de passer en disponibilité générale sur au moins une plateforme d'annuaire d'entreprise : donner à l'agent une identité qui n'est ni l'une ni l'autre.
La documentation qui la définit ne prend pas de gants sur le motif : face au déploiement de systèmes autonomes, « les modèles d'identité conçus pour les utilisateurs humains et pour les applications se révèlent insuffisants ».
Trois façons de donner un accès, trois régimes de responsabilité
| Compte d'un humain, prêté | Compte de service | Identité d'agent | |
|---|---|---|---|
| Ce que voient les journaux | Une personne | Un service | Un agent, comme tel |
| Durée de vie attendue | Celle de la personne | Des années | De la minute au trimestre |
| Création | Aucune | Manuelle, arbitrée | En masse, par automatisation |
| Propriétaire | Implicite et faux | Souvent perdu | Enregistré à la création |
| Retrait | Impossible sans casser l'humain | Oublié | Prévu par le modèle |
| Agir « au nom de » | Indistinguable | Non prévu | Explicite et révocable |
La première colonne devrait être fermée d'office, et pourtant c'est la plus répandue. Elle a un défaut qu'aucune politique n'efface : elle rend l'agent invisible. Le jour où il faut expliquer une opération, il n'existe aucune trace permettant de dire qu'un logiciel l'a produite. C'est exactement le trou décrit dans Gouverner un agent autonome : qui répond de ses actes ?, et l'identité prêtée le creuse au lieu de le combler.
Pourquoi le compte de service ne suffit plus
Le compte de service n'est pas un mauvais outil : il est dimensionné pour un autre régime. La documentation le formule mieux que n'importe quelle paraphrase — ces identités « portent l'attente d'une stabilité de long terme, d'une propriété connue et d'un cycle de vie géré ».
Or un agent ne ressemble pas à ça. Il est « souvent créé dynamiquement, par de l'automatisation, par des actions d'utilisateur dans des outils à faible code, ou par orchestration d'API ». Et surtout : « un agent peut exister quelques minutes le temps d'une tâche précise, ou être créé et détruit des milliers de fois par jour dans le cadre d'un flux automatisé ». La conclusion tient en sept mots : le modèle est conçu « pour l'échelle et l'éphémérité plutôt que pour la permanence ».
C'est un renversement complet de l'hygiène habituelle. Pendant vingt ans, la bonne pratique était de limiter le nombre de comptes techniques, parce que chacun était un objet coûteux à gouverner. Ici, la bonne pratique devient l'inverse : un agent, une identité, quitte à en créer beaucoup, parce que c'est la seule façon de savoir lequel a fait quoi et de couper l'un sans couper les autres.
Les motifs listés par la documentation valent d'être lus tels quels, parce qu'ils cadrent ce que vous devez exiger d'une telle plateforme : distinguer les opérations faites par des agents de celles faites par des identités humaines ou applicatives ; permettre aux agents d'obtenir un accès à la bonne taille ; les empêcher d'atteindre les rôles et systèmes les plus critiques ; et faire tenir la gestion d'identité à l'échelle de populations d'agents créés et détruits vite.
Autonome ou délégué : la distinction qui décide de tout
Une fois l'identité créée, l'agent peut agir selon deux régimes, et confondre les deux est la faute la plus coûteuse du domaine.
En accès autonome, l'agent utilise des droits attribués directement à son identité : rôles d'annuaire, rôles applicatifs, permissions sur une interface de données. Il agit pour lui-même. Ce qu'il peut faire ne dépend d'aucun humain présent, ce qui est précisément l'intérêt — et le danger — d'un agent qui tourne la nuit.
En accès délégué, il agit au nom d'une personne, avec les droits de cette personne, et la documentation précise le point qui compte : « l'utilisateur garde le contrôle des droits qui sont délégués à l'identité de l'agent ». La délégation est un prêt borné et révocable, pas un transfert.
La règle qui en découle est simple à énoncer et exigeante à tenir : tout ce qui engage quelqu'un doit passer en délégué ; tout ce qui relève de la mécanique interne peut passer en autonome. Un agent qui compile un rapport de stock agit pour lui-même. Un agent qui envoie ce rapport à un client agit au nom de quelqu'un — et ce quelqu'un doit être nommé dans le jeton, pas dans une note de service.
Un troisième régime, moins commenté, mérite attention : l'agent peut aussi recevoir des requêtes d'autres clients, utilisateurs ou agents, et les authentifier pour décider s'il obéit. C'est la brique qui manque à la plupart des montages multi-agents artisanaux décrits dans Faire travailler plusieurs agents IA ensemble : sans elle, un agent fait ce qu'on lui demande parce qu'on le lui a demandé.
Le parrain : la seule ligne qui empêche l'orphelin
Le détail le plus utile de tout le modèle est aussi le plus discret. Quand un agent est créé depuis un atelier à faible code, « l'utilisateur qui a créé l'agent est enregistré comme son parrain ». Une ligne, posée à la création, qui répond à la question que personne ne sait trancher six mois plus tard : à qui est cet accès ?
Sans parrain, une identité d'agent devient exactement ce que sont devenues les clés d'API de la décennie précédente : un droit actif que personne ne réclame, que personne n'ose couper, et qui survit à trois réorganisations. Avec parrain, la revue trimestrielle a un destinataire — et la question « est-ce encore utile ? » a quelqu'un pour y répondre.
Exigez-la donc partout, y compris pour les agents que vous construisez à la main hors de tout atelier. Le champ n'a pas besoin d'être natif : une convention de nommage et un tableau tenu à jour valent mieux qu'une case vide dans un produit sophistiqué.
Le prix, qui n'est jamais dans le schéma d'architecture
Une identité d'agent ne se réduit pas à une case cochée. Sur la plateforme examinée, la brique d'identité est disponible pour tous les clients de l'annuaire, mais étendre à ces agents les fonctions de sécurité de l'annuaire suppose une offre supplémentaire, incluse dans un palier haut de la suite bureautique ou vendue en complément d'autres paliers, avec une licence par utilisateur.
Ce n'est pas un reproche : c'est un paramètre de décision. Un projet d'agents dimensionné sur « une identité par agent » sans avoir lu les conditions de licence découvre le coût au pire moment, quand le pilote a réussi et qu'il faut généraliser. La question à poser au fournisseur est précise : quelles fonctions de sécurité s'appliquent aux identités d'agent sans licence additionnelle, et lesquelles la réclament ? C'est le même réflexe que dans Combien coûte vraiment un agent IA — la facture n'est jamais là où on la regarde.
Le protocole, à exécuter sur votre annuaire
- Inventoriez l'existant. Listez tout ce qui, aujourd'hui, permet à un agent d'agir chez vous : clés d'API dans des fichiers de configuration, comptes de service partagés, jetons collés dans des automatisations. Le chiffre vous surprendra ; c'est le point de départ, pas un motif de honte.
- Classez chaque accès en autonome ou délégué selon la règle donnée plus haut : engage-t-il quelqu'un ? Tout ce qui engage et qui tourne aujourd'hui en autonome est votre dette prioritaire.
- Choisissez un agent réel, pas un exemple, et refaites-lui une identité propre : parrain, droits écrits, liste de refus, échéance. Mesurez le temps que ça prend. Multipliez par le nombre d'agents que vous prévoyez.
- Testez la coupure, chronomètre en main, jetons déjà émis compris.
- Testez la trace : demandez à quelqu'un d'extérieur de retrouver, dans vos journaux, trois opérations faites par cet agent — sans lui dire lesquelles. S'il n'y arrive pas, votre traçabilité est décorative.
- Chiffrez la licence avant de généraliser, en distinguant ce qui est inclus de ce qui ne l'est pas.
Le cinquième point est celui qu'on saute, et c'est celui qui compte le jour d'un incident. Un agent qui tourne longtemps dérive, et la dérive ne se voit que dans les traces — c'est le sujet de Superviser un agent IA qui travaille en continu et, côté limites intrinsèques, de Combien de temps un agent tient-il tout seul.
Une identité propre borne ce que l'agent a le droit de faire. Elle ne dit rien de ce qu'il exécute réellement : les outils qu'il appelle viennent, eux, de code tiers que personne dans votre organisation n'a lu. C'est l'objet de l'article suivant. Le branchement lui-même est traité dans Connecter un agent IA à vos outils et vos données sans lui ouvrir toutes les portes, et la question de confiance dans Faut-il faire confiance à un agent IA ?
Une question, un projet IA ?
Vous branchez des agents sur vos systèmes internes et la question du compte à leur donner reste ouverte ? Échangeons sur votre contexte.
Prendre contact →