La réception connecte un nouvel agent de prise de rendez-vous au calendrier. Le chemin le plus rapide consiste à utiliser le compte Microsoft ou Google d’une collaboratrice. On valide OAuth, le test fonctionne et le pilote démarre.
Trois mois plus tard, la collaboratrice quitte l’entreprise. Son compte est bloqué. L’automatisation s’arrête — ou un ancien token continue de fonctionner sans que personne sache précisément quels processus l’utilisent encore. Dans les logs, chaque modification ressemble en plus à une action effectuée personnellement par cette ancienne collaboratrice.
Le problème n’est pas d’abord le modèle IA. C’est l’identité.
Un agent qui accède de manière autonome au CRM, au calendrier, aux fichiers ou aux API devrait disposer, lorsque la plateforme le permet, d’une identité technique séparée : compte de service, managed identity ou autre identité de workload. Le vocabulaire varie. Le principe est stable : l’automatisation n’est ni « Anna » ni « le patron », mais un acteur technique nommé avec son propre cycle de vie.
Le compte de service d’un agent IA rend les droits réellement gérables
Des permissions partagées sous une identité humaine deviennent vite difficiles à administrer. Trois automations peuvent fonctionner avec le même compte et, six mois plus tard, personne ne sait exactement quel processus a effectué quelle action.
L’architecture Zero Trust de NIST place l’identité au centre des décisions d’accès. Le document SP 800-207A étend cette logique aux applications et services cloud. Microsoft décrit de son côté les managed identities comme des identités de workload distinctes des comptes utilisateurs habituels.
Pour une PME, l’intérêt est immédiat : si l’agent de réservation a sa propre identité, on peut désactiver cet agent, réduire ses droits ou filtrer ses traces, sans bloquer simultanément le poste d’une personne.
Fait confirmé : les architectures modernes d’identité permettent de gérer des identités non humaines et des accès granulaires.
Recommandation : toute automation de production qui agit de manière indépendante devrait avoir une identité technique clairement nommée et un responsable humain.
Ce qui se casse quand l’agent travaille « comme Marie »
Premier risque : l’excès de droits. Le compte d’un dirigeant peut accéder aux mails, factures, documents RH et espaces partagés. L’agent chargé des rendez-vous n’a peut-être besoin que de deux agendas et de quelques champs CRM. Réutiliser le compte humain donne souvent trop dès le départ.
Deuxième problème : l’attribution. Le journal indique « maria@example… a modifié le rendez-vous ». Était-ce vraiment Maria ? L’agent ? Un script ? Une autre intégration utilisant le même token ? Lors d’un litige, cette différence compte.
Troisième problème : le départ des collaborateurs. Les rôles changent, les mots de passe sont réinitialisés, les comptes sont désactivés. Un processus critique ne devrait pas dépendre en silence de ce cycle de vie.
Enfin, le confinement devient compliqué. En cas d’activité suspecte, on veut isoler l’automatisation. Avec un compte partagé, couper l’accès peut empêcher aussi un humain de travailler.
Dans un garage, par exemple, un agent peut lire une demande web et placer un créneau provisoire dans le planning. Il a besoin de droits limités sur le calendrier et le CRM, pas de toute la boîte mail du chef d’atelier.
Une identité machine ne se résume pas à créer un nouvel utilisateur
Créer [email protected] puis lui donner tous les droits ne règle presque rien. L’intérêt vient du périmètre et du cycle de vie.
Une mise en place simple peut suivre ces étapes :
- Un objectif par identité.
agent-reservation-prodest plus clair qu’un compte génériqueai-master. - Le minimum de scopes. Distinguez lecture et écriture, et limitez la ressource lorsque l’outil le permet.
- Un propriétaire métier et un propriétaire technique. L’un décide du workflow, l’autre peut modifier l’identité et ses credentials.
- Un cycle de vie des secrets. Préférez les identités gérées lorsqu’elles existent ; sinon définissez stockage, rotation et expiration.
- Un test de révocation. Désactivez volontairement l’identité et vérifiez que l’agent ne peut plus agir.
- Une attribution lisible. Les logs doivent montrer le nom de l’agent à l’origine de l’action.
Séparez également test et production. Un agent « de test » connecté aux droits clients de production n’est plus vraiment un environnement de test.
Les cas où l’outil SaaS ne coopère pas
Toutes les applications utilisées par une PME n’offrent pas un système élégant d’identité machine. Certains outils n’acceptent que des utilisateurs classiques. Dans ce cas, un compte technique dédié, sans usage humain quotidien et avec les droits minimums, reste généralement préférable au compte d’une vraie personne.
La délégation est une autre possibilité. L’agent conserve son identité technique, mais le log indique pour quel collaborateur ou quelle règle métier il agit. Cela évite l’usurpation invisible.
Préparez aussi le chemin inverse : que se passe-t-il si l’identité machine ne fonctionne plus ? Une personne doit pouvoir reprendre les tâches essentielles. Le « break glass » n’est pas un mot de passe partagé avec tout le bureau ; c’est une procédure de continuité connue.
Le handover est particulièrement important lorsqu’un agent rencontre une tâche légitime hors de son périmètre. Il ne devrait pas s’auto-attribuer un droit supplémentaire. Il transmet la tâche à son owner.
Un pilote minimal qui teste aussi l’arrêt
Choisissez un processus avec des conséquences limitées. Créez l’identité dédiée et ne donnez que les accès nécessaires. Évitez le classique « admin pour commencer, on réduira ensuite ».
Testez volontairement une action autorisée, une action interdite et la révocation complète du compte. Lisez ensuite les journaux : pouvez-vous identifier rapidement quel agent a modifié quel objet ?
Mesurez le taux d’actions attribuées sans ambiguïté, les accès refusés hors périmètre, le temps nécessaire pour révoquer l’identité, le nombre d’exceptions de droits demandées et la part des credentials avec expiration ou rotation définie.
Le test le plus révélateur n’est pas « l’agent peut-il créer un événement ? ». C’est « pouvons-nous arrêter uniquement cet agent en quelques minutes sans bloquer une collaboratrice ou casser trois autres workflows ? ».
Une identité machine séparée ne garantit pas la sécurité. Elle fournit en revanche un objet clair pour contrôler les permissions, les logs, la révocation et la responsabilité. C’est ce qui permet à une automation de sortir du stade de démo sans devenir un compte fantôme de plus dans l’entreprise.
L'article sur les permissions et journaux d'audit répond à la question des actions autorisées. L'inventaire des agents indique où ils fonctionnent. L'identité technique rend chaque entrée réellement révocable.
Sources
FAQ
Chaque petite fonction IA doit-elle avoir un compte séparé ?
Pas forcément pour une fonction purement textuelle. Dès qu’une automation agit seule sur des systèmes métiers, la séparation devient très utile.
Un compte de service et une managed identity sont-ils identiques ?
Non. L’implémentation varie, mais les deux évitent de dépendre d’un utilisateur humain ordinaire.
L’agent peut-il agir au nom d’un salarié ?
Oui, si l’identité technique de l’agent reste visible et si la délégation métier est enregistrée.
Et si le SaaS ne supporte pas les comptes de service ?
Créez si possible un utilisateur technique dédié avec des droits minimums et évitez d’utiliser un compte personnel.
Quand revoir les droits ?
À chaque changement de processus, de propriétaire ou d’outil, après un incident et régulièrement dans le cadre d’une revue d’accès.