Les agents d'IA sont déjà dans vos systèmes et votre stratégie d'identité ne le sait pas encore
D'ici la fin 2026, 40 % des applications d'entreprise intégreront des agents d'IA dotés de tâches spécifiques. Il y a douze mois, ce chiffre ne dépassait pas 5 %. Ce bond n'est pas seulement statistique : il est structurel. Des millions d'identités non humaines opèrent en ce moment même dans des réseaux d'entreprise avec accès aux données, aux systèmes et aux décisions, et la majorité des équipes de sécurité continue d'aborder le problème avec les mauvais outils.
La gestion des identités et des accès — ce que l'industrie appelle IAM, pour Identity and Access Management — a été construite pour un monde où les acteurs du système étaient des personnes. Quelqu'un entre, on lui attribue un rôle, ses accès sont révisés périodiquement et il finit par être désinscrit. Le cycle a une logique humaine parce qu'il a été conçu pour des humains. Les agents d'IA n'arrivent pas par les ressources humaines, ils n'ont pas de manager pour approuver leurs permissions et ils n'ont pas non plus de date de désactivation programmée. Mais ils ont bel et bien des accès. Et ces accès, dans la grande majorité des organisations, ne sont pas gouvernés avec la même rigueur que ceux d'un nouvel employé.
Ce n'est pas un problème technique mineur. C'est une fissure structurelle dans la façon dont les entreprises comprennent qui — ou quoi — opère au sein de leurs systèmes.
L'inventaire que personne ne possède
Avant de parler de contrôles, il existe une question plus fondamentale à laquelle peu d'organisations sont capables de répondre avec précision : combien d'agents d'IA tournent en ce moment dans leurs environnements, qui les a déployés et que peuvent-ils faire.
La réponse embarrassante est que la majorité ne le sait pas. Selon des données publiées par Gravitee, seulement un agent d'IA sur sept opérant dans des environnements de production a fait l'objet d'une révision formelle par l'équipe de sécurité avant d'être déployé. Les autres ont été lancés par des équipes métier ou de développement animées d'une urgence opérationnelle, sans passer par les mêmes filtres qui s'appliquent à tout nouveau système. Le résultat est un écosystème d'identités non humaines qui accumulent des permissions sans audit, opèrent sous des identifiants partagés et restent actives bien après que le flux de travail qui leur a donné naissance a changé ou disparu.
Le problème n'est pas nouveau dans sa logique. Les identités non humaines — comptes de service, clés d'API, scripts d'automatisation — étaient déjà plus nombreuses que les utilisateurs humains dans la plupart des grandes entreprises avant même que les agents d'IA n'entrent dans le paysage. Ce qui a changé, c'est la vitesse et l'autonomie. Un cluster Kubernetes peut provisionner des milliers de comptes de service en quelques minutes. Un agent d'IA peut interagir simultanément avec plusieurs systèmes, prendre des décisions en temps réel et modifier son comportement en fonction du contexte. Ce n'est pas un compte de service passif attendant une instruction. C'est un acteur doté d'une capacité de jugement propre, opérant à l'intérieur de vos systèmes.
Sans un inventaire clair des agents existants, de leurs accès et des responsables qui en répondent, toute conversation sur les contrôles arrive après le problème. On ne peut pas gouverner ce que l'on n'a pas catalogué.
À quoi ressemble une brèche quand l'acteur est une machine
Le cas Salesloft et Drift, survenu l'année dernière, illustre avec précision le type de risque qui émerge lorsque les contrôles d'identité ne couvrent pas les intégrations d'IA. Des attaquants ont compromis des tokens OAuth liés au chatbot de Drift — une intégration d'IA utilisée par Salesloft — et ont accédé aux environnements Salesforce de plus de 700 organisations. La brèche est passée inaperçue pendant plusieurs jours.
Le détail qui importe n'est pas technique, mais opérationnel : l'équipe de sécurité pouvait voir que le chatbot disposait d'un accès. Ce qu'elle ne pouvait pas voir, c'est ce qu'il faisait avec cet accès en temps réel. De l'extérieur, les requêtes malveillantes étaient indiscernables du comportement légitime du bot. Il s'agissait d'une identité non humaine de confiance faisant exactement ce qu'elle semblait devoir faire.
Ce schéma — accès visible, comportement invisible — est au cœur du problème. Les cadres IAM traditionnels ont été construits pour répondre à la question de savoir qui a accès à quoi. Face aux agents d'IA, la question qui compte est ce que cet accès fait à chaque instant, dans quel contexte et à quelle fin. Ce sont des questions différentes et elles nécessitent des outils différents.
Le modèle de contrôle statique basé sur les rôles — on attribue un rôle, le rôle définit les permissions, les permissions sont révisées chaque trimestre — n'a pas été conçu pour des acteurs qui opèrent à la vitesse des machines et modifient leur comportement selon le contexte. Il faut une évaluation continue du risque, et non un audit périodique. Il faut que les accès expirent automatiquement lorsque la tâche est terminée, et non qu'ils persistent indéfiniment parce que personne ne les a révoqués.
Les principes existent depuis longtemps. Le moindre privilège, l'accès juste-à-temps, les tokens éphémères qui expirent d'eux-mêmes, l'intégration avec les plateformes de gestion des accès à privilèges. Aucun de ces mécanismes n'est nouveau. Ce qui est nouveau, c'est l'urgence de les étendre à une catégorie d'identités pour lesquelles ils n'avaient pas été pensés à l'origine, et de le faire avant que l'incident suivant n'apparaisse dans le rapport trimestriel.
Ce que les organisations reportent et pourquoi ce report a un coût
Il y a une raison pour laquelle les équipes de sécurité n'ont pas étendu leurs cadres IAM aux agents d'IA aussi vite que ces agents se déploient : le déploiement est impulsé par les équipes métier, et les équipes de sécurité interviennent après.
L'asymétrie est structurelle. Une équipe produit ou opérationnelle qui trouve dans un agent d'IA un moyen d'automatiser un flux de travail n'a aucun intérêt à s'arrêter pour demander une révision de sécurité qui peut prendre plusieurs semaines. Son intérêt, c'est le résultat opérationnel immédiat. Le coût de ne pas le faire — une brèche, un accès non autorisé, un agent compromis — est payé par une autre équipe, plus tard, sous un autre budget.
Cette distribution des incitations produit exactement l'inventaire chaotique décrit plus haut : des dizaines ou des centaines d'agents tournant en production, beaucoup sans propriétaire formel, avec des permissions qui n'ont jamais été révisées et des identifiants dont personne ne sait quand ils expirent.
La solution n'est pas de ralentir le déploiement des agents. Les gains de productivité sont réels et les organisations qui prendront du retard paieront ce coût d'une autre manière. La solution est d'intégrer la gouvernance des identités au processus de déploiement, non pas comme une étape ultérieure, mais comme une condition préalable. Qu'aucun agent n'entre en production sans que quelqu'un ait répondu à trois questions fondamentales : à quoi a-t-il accès, qui est responsable de cet accès et dans quelles conditions cet accès expire-t-il.
Gartner a identifié l'absence de gouvernance sur les identités des agents d'IA comme l'une des tendances de cybersécurité les plus critiques pour 2026. Non pas parce qu'il s'agit d'un problème nouveau dans sa logique, mais parce que la vitesse d'adoption dépasse la vitesse des contrôles. L'écart entre les deux est là où vivent les incidents.
Le régulateur manquant dans la course vers l'IA opérationnelle
Le discours dominant sur l'IA en entreprise est centré sur la capacité : ce qu'un agent peut faire, combien de temps il économise, combien de processus il automatise. C'est un discours légitime. Les chiffres de productivité sont réels.
Ce que ce discours laisse de côté, c'est la question de savoir qui répond quand quelque chose tourne mal. Et lorsque l'acteur qui défaille n'est pas un employé mais un agent ayant accès à plusieurs systèmes, la question devient beaucoup plus difficile à répondre.
La réduction des coûts liés aux brèches que promettent les cadres d'IA intégrés à l'IAM — jusqu'à 80 % selon certaines études sectorielles — ne se réalise pas d'elle-même. Elle se réalise lorsque quelqu'un a décidé que les agents d'IA sont des décisions d'identité avant d'être des décisions d'ingénierie. Lorsque l'équipe de sécurité dispose d'une visibilité en temps réel sur le comportement de chaque agent, et pas seulement sur ses permissions statiques. Lorsque les accès expirent automatiquement et que les flux d'attestation sont continus, et non annuels.
Les organisations qui déploient des agents d'IA sans ce niveau de gouvernance ne font pas preuve de témérité par ignorance. Elles font preuve de témérité parce que la pression pour avancer vite est réelle et que les contrôles appropriés exigent un investissement, une coordination et une friction délibérée dans les processus de déploiement.
Cette friction, bien conçue, ne freine pas l'adoption. Elle la rend durable. La différence entre un programme d'IA qui monte en charge de façon ordonnée et un programme qui produit un incident majeur dans dix-huit mois ne réside ni dans la qualité des modèles ni dans l'ambition des cas d'usage. Elle réside dans le fait que quelqu'un ait eu — ou non — la conversation sur les identités avant que le premier agent n'arrive en production.
