L’intelligence artificielle s’impose désormais comme un levier structurant pour les entreprises : 70%¹ l’ont déjà placée au cœur de leur stratégie. Jusqu’ici, la majorité des déploiements reposaient sur des assistants conversationnels capables de restituer de l’information, parfois enrichie par des données internes, mais dont les interactions avec le système d’information restaient limitées.

Une rupture est désormais en cours : l’essor de l’IA agentique. Contrairement aux simples chatbots, les agents IA ne se contentent plus de répondre ; ils raisonnent, décident d’appeler des outils et déclenchent des actions. Ils peuvent envoyer un courriel, planifier un déplacement, mettre à jour un dossier, initier une transaction ou, demain, exécuter des opérations plus sensibles encore. Leur promesse en matière d’automatisation est considérable. Leur impact potentiel sur la surface d’attaque du système d’information l’est tout autant.

Car dès lors qu’un système d’IA agit, une question devient centrale : au nom de qui agit-il, avec quels droits, dans quel périmètre, et sous quel contrôle ?

Cette question est d’autant plus critique que les usages progressent rapidement : 51 %² des organisations ont déjà déployé un agent IA à destination de leurs collaborateurs, tandis que 59 %³ des salariés reconnaissent utiliser des agents IA non officiellement autorisés. Au-delà des usages individuels, chaque direction métier peut être tentée de déployer ses propres agents pour répondre à des besoins locaux. Ce phénomène alimente un Shadow IT agentique, dans lequel les agents se multiplient de manière fragmentée, avec des architectures hétérogènes, des contrôles variables et une gouvernance souvent lacunaire.

Dans ce contexte, l’Identity and Access Management (IAM) doit redevenir le centre de gravité de la stratégie de sécurité. Toute donnée qu’un agent peut consulter, toute ressource qu’il peut modifier, toute action qu’il peut exécuter doivent relever d’un dispositif de contrôle d’accès, de traçabilité et de gouvernance centralisé.

Cet article propose d’analyser la sécurisation des agents IA à travers le prisme de l’IAM, non comme une brique parmi d’autres, mais comme l’un des garde-fous structurants pour encadrer leurs usages et protéger durablement le système d’information.

Des assistants conversationnels aux agents IA : comment ils interagissent avec le SI

Par quels mécanismes un agent IA peut-il agir sur une application ?

La capacité d’un agent IA à interagir avec les applications du système d’information repose sur l’émergence de nouveaux protocoles, parmi lesquels le Model Context Protocol (MCP) occupe aujourd’hui une place croissante. Ce type de protocole permet à un agent IA de dialoguer avec des applications tierces via une couche intermédiaire, souvent matérialisée par une brique IT appelé serveur MCP.

Ce serveur MCP agit comme un composant d’exposition et d’orchestration. Il reçoit des requêtes émises par un modèle d’IA, les traduit en appels exploitables, puis les relaie vers les API de l’application cible.  Pour cela, le serveur MCP met à disposition du modèle des outils (“tools”) décrivant les actions qu’il est autorisé à invoquer. Une fois le serveur déclaré dans l’interface conversationnelle ou dans l’environnement de l’agent, le modèle peut décider, en fonction de la demande utilisateur et de son raisonnement, d’appeler un ou plusieurs de ces outils.

D’un point de vue sécurité, cela introduit une question d’identité : comment l’utilisateur final est-il authentifié, et comment cette identité est-elle propagée — ou non — jusqu’aux services cibles ? Dans les architectures modernes, l’authentification utilisateur repose généralement sur OpenID Connect (OIDC), tandis que l’autorisation d’accès aux API repose sur OAuth 2.x via des jetons d’accès. L’enjeu, pour un agent, est de garantir que les appels aux outils et aux API soient réalisés dans un modèle contrôlé de délégation : l’agent agit-il avec ses propres droits, avec les droits de l’utilisateur, ou selon un mécanisme hybride ?

Illustrons ce fonctionnement à travers un cas d’usage : la planification d’une réunion par un agent IA. L’utilisateur formule sa demande dans l’interface conversationnelle : « Planifie une réunion avec l’équipe demain à 10h ». L’agent IA analyse la requête et décide d’utiliser l’outil « Calendrier » mis à disposition par le serveur MCP. Il envoie alors une requête structurée à ce serveur, contenant uniquement les informations nécessaires à la création de l’événement (participants, date, heure, sujet). Le serveur MCP relaie cette demande à l’API du calendrier d’entreprise, qui permet de créer la réunion.

En apparence, le mécanisme est simple. En pratique, il introduit un changement majeur : le modèle ne se contente plus d’assister l’utilisateur ; il devient un intermédiaire actif entre l’intention humaine et l’exécution technique dans le SI.

Un mode de fonctionnement opaque

Cette architecture soulève immédiatement une difficulté de sécurité : dans de nombreux cas, le composant d’intégration ne dispose que d’une visibilité partielle sur le contexte d’origine. Il reçoit une requête structurée, mais pas nécessairement l’intégralité de la requête initiale, des arbitrages du modèle ou des éléments qui ont conduit au choix de l’outil invoqué. Le système d’information voit alors arriver une action, sans toujours pouvoir reconstituer de manière fiable la chaîne complète qui relie la demande utilisateur, le raisonnement du modèle, l’appel d’outil et l’effet final produit. Cette perte de contexte est d’autant plus critique lorsque l’appel à l’API est porté par un jeton OAuth : selon l’architecture, le service cible peut ne voir qu’une identité applicative (compte de service / application) et non l’utilisateur réel à l’origine de la demande. Cela fragilise l’attribution, la détection d’abus et la capacité à appliquer des politiques conditionnelles différenciées entre action humaine et action agentique.

Autrement dit, l’agent interagit avec le SI selon une logique partiellement opaque, qui rompt avec les schémas plus traditionnels d’interaction applicative. Cette opacité complique le contrôle en temps réel, la traçabilité ex post, ainsi que l’attribution claire de responsabilité.

Une technologie émergente qui pose des défis de sécurité

L’IA agentique introduit des cas d’usage nouveaux, mais aussi des risques nouveaux, qui doivent être analysés et traités au niveau de l’IAM. Quatre défis apparaissent comme particulièrement structurants.

Défi 1 : Recenser les agents IA 

Le premier défi est celui de la visibilité. Dans de nombreuses organisations, il n’existe aujourd’hui ni cartographie exhaustive des agents IA déployés, ni inventaire consolidé des outils auxquels ils sont connectés.

Cette situation résulte de deux dynamiques :

• D’une part, les usages se développent souvent en dehors des circuits de gouvernance historiques : certaines équipes déploient des agents pour leurs besoins propres, sans associer en amont les équipes sécurité, IAM ou architecture et dans parfois dans des solutions plateformes qui permettent à chacun de construire ses propres usages.
• D’autre part, les modalités techniques d’intégration sont diverses. Le MCP constitue une approche montante, mais il coexiste avec des intégrations propriétaires, des connecteurs natifs à certains écosystèmes, des mécanismes d’exécution locale de code, ou encore des capacités embarquées directement dans les plateformes des éditeurs.

Le sujet n’est donc pas seulement celui du recensement des agents eux-mêmes, mais celui de l’identification de l’ensemble de la chaîne d’exécution : agent, interface, outils exposés, applications cibles, comptes utilisés, données manipulées et flux générés. Sans cette visibilité, aucune gouvernance sérieuse n’est possible.

Défi 2 : Attribuer et gouverner les droits des agents IA

Le deuxième défi concerne l’autorisation. Les modèles IAM traditionnels ne disposent pas encore, dans la plupart des environnements, d’un objet natif et généralisé permettant de représenter proprement un agent IA comme une identité gouvernable à part entière.

En pratique, les composants intermédiaires sont fréquemment enregistrés comme des applications techniques ou opèrent à l’aide de comptes de service. Il en résulte plusieurs dérives connues : droits trop larges, absence de séparation fine entre les capacités d’un agent et celles du composant qui l’héberge, difficulté à appliquer le moindre privilège, et impossibilité de différencier clairement une action humaine directe d’une action exécutée par un agent.

Le risque est majeur : l’agent n’exécute plus seulement une intention métier ; il devient un vecteur d’accès indirect au SI, parfois avec un niveau de privilège supérieur à ce qui serait acceptable pour un utilisateur ou une application classique.

Défi 3 : Authentifier un agent IA

L’authentification constitue le troisième défi, à deux niveaux distincts. Il faut d’abord authentifier correctement l’utilisateur final, afin de garantir que l’agent n’agit pas dans un vide identitaire. Mais il faut également authentifier l’agent lui-même, ou à tout le moins le composant qui agit pour son compte, afin de pouvoir lui appliquer des politiques spécifiques, des restrictions adaptées et des exigences de supervision proportionnées.

Cette double exigence est nouvelle par son intensité : avec les agents IA, le système doit simultanément gérer l’identité du demandeur, l’identité du système exécutant, et la relation précise entre les deux.

Défi 4 : Tracer les actions réalisées par les agents IA

Le dernier défi est celui de la traçabilité. Dans de nombreuses architectures actuelles, les journaux permettent surtout d’observer l’appel technique émis vers le service cible. En revanche, il reste difficile de reconstituer de manière fiable :

• quel utilisateur est à l’origine de la demande ;
• quel agent a décidé ou exécuté l’action ;
• dans quel contexte métier l’appel a été réalisé ;
• quelles étapes intermédiaires ont conduit à l’exécution finale.

Ce déficit d’auditabilité fragilise à la fois la détection, l’investigation et la responsabilité. Lorsqu’une action sensible est déclenchée, il doit être possible de déterminer si elle résulte d’une instruction légitime, d’une mauvaise interprétation, d’une dérive autonome, d’un abus de privilège ou d’une compromission du contexte d’entrée, par exemple via une attaque de type prompt injection.

L’IAM comme cadre de référence pour sécuriser les agents IA

Les grands principes IAM restent inchangés

Face à cette transformation, un point doit être clairement affirmé : les fondamentaux de l’IAM ne disparaissent pas avec l’IA agentique. Au contraire, ils redeviennent essentiels.

Un système d’information maîtrisé repose sur quelques principes simples et robustes :

• centraliser l’authentification autant que possible autour d’un fournisseur d’identité de référence ;
• éviter les comptes génériques lorsqu’un usage nominatif est possible ;
• limiter les privilèges au strict nécessaire ;
• gouverner les habilitations dans la durée ;
• tracer les accès et les actions ;
• distinguer clairement les rôles, les responsabilités et les périmètres d’exécution.

L’arrivée des agents IA ne remet pas en cause ces principes. En revanche, elle révèle leurs angles morts actuels et impose de faire évoluer la gouvernance comme les mécanismes techniques. Ce n’est pas l’IAM qu’il faut réinventer ; c’est son modèle d’application qu’il faut adapter à une nouvelle catégorie d’acteurs numériques, capables de prendre des initiatives et de déclencher des effets dans le SI.

Une trajectoire de sécurisation en quatre étapes

1. Recenser les cas d’usage et les agents

La première étape consiste à obtenir une visibilité exhaustive. Cela suppose d’identifier :

• les agents déployés ;
• les environnements dans lesquels ils opèrent ;
• les outils et connecteurs qu’ils utilisent ;
• les applications qu’ils peuvent atteindre ;
• les comptes, identités techniques ou jetons qu’ils mobilisent ;
• les données qu’ils peuvent lire, modifier ou transmettre.

Cette cartographie n’est pas un exercice documentaire accessoire : elle constitue la condition préalable à toute politique de contrôle d’accès cohérente. Pour la réaliser, des outils du marché émerge, comme la solution Agent 365 de Microsoft.

2. Introduire un type d’identité spécifique pour les agents IA

La deuxième étape consiste à reconnaître les agents IA comme une catégorie spécifique d’identités non humaines. Ce marquage est essentiel, car il permet d’appliquer des politiques différenciées : interdiction de certaines actions, limitation à certains périmètres, exigences de validation préalable, surveillance renforcée ou restrictions conditionnelles.

Cette distinction est structurante. Une application classique n’a pas le même niveau d’autonomie, ni le même profil de risque, qu’un agent IA capable de sélectionner lui-même un outil, d’enchaîner plusieurs actions ou de réagir à un contexte ambigu. L’IAM doit donc être en mesure de dire non seulement qui agit, mais aussi de quelle manière le système agit.

À titre d’exemple, un utilisateur peut disposer du droit d’envoyer un courriel ou de créer un ordre de modification. Cela ne signifie pas qu’un agent puisse exécuter cette action sans garde-fou. Selon la sensibilité du processus, une politique dédiée peut imposer une validation humaine, un périmètre restreint ou une interdiction pure et simple.

3. Rattacher l’authentification et la gestion des droits à un fournisseur d’identité unique et à l’utilisateur final

La troisième étape consiste à ramener l’authentification dans le giron d’un fournisseur d’identité central, afin que les droits soient gouvernés de manière homogène. L’objectif est double : éviter le recours incontrôlé à des comptes techniques sur-privilegiés, et faire en sorte que l’agent opère, autant que possible, dans la limite des habilitations de l’utilisateur à l’origine de la demande.

Cela ne signifie pas que l’agent doit être transparent du point de vue de la sécurité. Au contraire, l’enjeu est de pouvoir appliquer une logique du type : « même si l’utilisateur a le droit, l’agent n’a pas nécessairement le droit de le faire seul, dans n’importe quel contexte, et sans contrôle complémentaire ».

4. Mettre en place une approbation humaine avant certaines actions initiées par les agents

La sécurisation des agents IA ne peut pas reposer exclusivement sur l’authentification et l’autorisation. Elle suppose aussi de définir le niveau d’autonomie acceptable selon la criticité des actions concernées.

Trois modèles sont classiquement distingués.

Human-in-the-loop

C’est le mode le plus protecteur. L’agent prépare l’action, mais son exécution reste conditionnée à une validation explicite. Ce schéma doit être privilégié pour les opérations sensibles : mouvement financier, modification de droits, envoi externe engageant l’entreprise, accès à des données sensibles, action à effet irréversible, etc.

Son intérêt est majeur : la validation finale est portée par une interface de contrôle indépendante du raisonnement de l’agent. Même si le modèle a été influencé, manipulé ou simplement trompé, l’utilisateur ou l’opérateur conserve la maîtrise de la décision.

Human-over-the-loop

Dans ce modèle, l’humain ne valide pas chaque action individuellement, mais supervise l’exécution et conserve une capacité d’interruption immédiate. Ce schéma peut convenir à des processus fréquents, encadrés et faiblement risqués, à condition que la surveillance soit réelle et que le mécanisme d’arrêt soit effectivement opérationnel.

Human-out-of-the-loop

Ici, l’agent exécute de manière autonome, sans intervention humaine immédiate. Ce niveau d’autonomie ne devrait être envisagé que pour des usages à très faible criticité, dans des environnements strictement bornés, avec des périmètres d’action réduits, des mécanismes de contrôle compensatoires solides et une tolérance explicite au risque résiduel.

Pour un RSSI, la logique est simple : plus l’impact métier, réglementaire ou sécurité est élevé, plus la boucle humaine doit être proche de l’exécution.

Une cible claire, mais encore freinée par plusieurs limites

Obstacles fonctionnels

La cible de sécurisation peut être formulée de manière claire. Sa mise en œuvre se heurte toutefois à plusieurs obstacles majeurs d’un point de vue fonctionnel.

Le premier concerne le manque de granularité des autorisations. Aujourd’hui, un utilisateur peut vouloir demander à un agent d’effectuer une action précise sur une ressource précise. Pourtant, les mécanismes disponibles imposent souvent des permissions bien plus larges que nécessaire. Traiter un courriel peut conduire à ouvrir l’accès à toute une boîte de messagerie ; planifier une réunion peut impliquer un accès étendu à l’agenda ; interagir avec un référentiel peut nécessiter des droits de lecture ou d’écriture bien au-delà du besoin exprimé. Ce décalage est particulièrement problématique dans un contexte agentique. Une IA étant par nature non déterministe dans sa manière de sélectionner et d’enchaîner ses actions, un accès trop large devient mécaniquement un risque disproportionné. Une adoption sécurisée suppose donc d’évoluer vers des mécanismes d’autorisation plus fins, contextualisés, temporaires et proportionnés à la requête réellement formulée.

Le second obstacle porte sur l’authentification et la propagation de l’identité. Dans beaucoup de cas, les architectures actuelles reposent encore sur des comptes techniques, des secrets partagés ou des mécanismes d’authentification peu satisfaisants au regard d’une gouvernance IAM mature. La cible consiste au contraire à faire en sorte que chaque action soit reliée de manière explicite à (i) l’utilisateur à l’origine de la demande, et (ii) au fait qu’elle a été exécutée par un agent — ce qui implique de distinguer l’identité du demandeur et l’identité du système exécutant, tout en documentant la relation de délégation entre les deux.  En pratique, cela renvoie à des mécanismes de délégation contrôlée tels que les flux OAuth “On‑Behalf‑Of (OBO)” : l’agent (ou sa couche d’orchestration) appelle une API en portant une autorisation dérivée de l’utilisateur, mais avec des contraintes supplémentaires (portée limitée, durée réduite, contexte, politiques conditionnelles). L’objectif est de réduire la dépendance aux comptes techniques sur‑privilégiés tout en conservant une chaîne de responsabilité exploitable.  À ce stade, le marché ne propose toutefois pas encore un modèle totalement homogène et interopérable couvrant à la fois l’authentification, l’autorisation fine, la traçabilité et la gouvernance des agents à grande échelle.

Dernier obstacle fondamental, la traçabilité : chaque action doit être liée de façon explicite à une chaîne de responsabilité intelligible. Sans cette capacité, il n’y a ni auditabilité robuste, ni contrôle effectif, ni gouvernance défendable devant les métiers, les auditeurs ou le régulateur. Et cela a un coût pour les SIEM…

Un marché encore fragmenté, qui complique la sécurisation

Du point de vue des entreprises, la difficulté n’est pas seulement technique : elle est aussi liée à la maturité du marché. Les capacités agentiques se diffusent plus vite que les standards de sécurité et de gouvernance capables de les encadrer de manière homogène. Résultat : les organisations doivent composer avec des solutions hétérogènes, dont le modèle d’identité, d’audit et de contrôle varie fortement d’un éditeur à l’autre.

Le MCP peut-il s’imposer comme standard de marché ?

Certains éditeurs exposent leurs applications via des serveurs MCP ou des mécanismes comparables, tandis que d’autres privilégient des intégrations natives, plus fermées, au sein de leur propre écosystème. Dans les faits, il n’existe pas encore de cadre pleinement homogène couvrant de manière satisfaisante les enjeux d’authentification, d’autorisation, de traçabilité, de gouvernance et de nomenclature des capacités exposées.

Deux trajectoires peuvent être envisagées :

• La première serait celle d’une convergence vers un socle standardisé, permettant l’interopérabilité des agents, des outils et des plateformes. Une telle évolution faciliterait le déploiement à grande échelle, améliorerait l’expérience utilisateur et rendrait possible une gouvernance plus cohérente à l’échelle de l’entreprise.
• La seconde serait celle d’une fragmentation durable du marché. Dans ce scénario, chaque éditeur continuerait à privilégier ses propres mécanismes, ses propres objets de sécurité et ses propres modèles d’intégration. Les conséquences seraient lourdes pour les entreprises : multiplication des angles morts, hétérogénéité des contrôles, difficulté à centraliser la supervision et impossibilité pratique d’appliquer une politique IAM homogène sur l’ensemble du périmètre agentique.

À court terme, les signaux du marché suggèrent une co‑existence : des initiatives d’interopérabilité émergent, mais les grands éditeurs conservent des logiques d’écosystèmes intégrés. Pour un RSSI, cela impose de raisonner non seulement “outil par outil”, mais aussi en termes de capacité à gouverner un portefeuille d’agents sur un périmètre multi‑éditeurs.

Vers des registres d’agents IA

La montée en puissance des agents IA justifie l’émergence d’un nouvel objet de gouvernance : le registre d’agents. Parce qu’un agent est un système autonome capable de déclencher des actions, il ne peut plus être traité comme un simple composant applicatif invisible. Il doit être identifié, qualifié, rattaché à un propriétaire, inscrit dans un cycle de vie, évalué en fonction de son périmètre d’action et soumis à des règles spécifiques.

Ce registre doit, à terme, permettre de répondre à des questions simples mais décisives :

• quels agents existent dans l’organisation ;
• qui en est responsable ;
• dans quel environnement opèrent-ils ;
• à quels outils et à quelles données ont-ils accès ;
• quels mécanismes d’authentification utilisent-ils ;
• quelles validations humaines sont exigées ;
• quels journaux produisent-ils ;
• quand doivent-ils être revus, requalifiés, suspendus ou retirés.

Certains fournisseurs d’identité commencent à introduire des capacités dédiées à cette nouvelle catégorie d’identités non humaines. C’est un signal important. Mais la maturité du marché reste naissante, et la gouvernance ne pourra pas être déléguée aux seuls éditeurs. Le vrai sujet est avant tout d’entreprise : définir un modèle de responsabilité, de contrôle et de sécurité adapté à l’autonomie croissante des systèmes d’IA.

Quand s’attaquer à l’IAM des agents IA ? Maintenant !

L’essor des agents IA marque une évolution majeure dans la transformation des systèmes d’information. En passant d’une logique d’assistance à une logique d’action, ces systèmes déplacent profondément les enjeux de sécurité : il ne s’agit plus seulement de maîtriser les données qu’une IA peut consulter, mais bien les actions qu’elle est en mesure d’exécuter, les droits qu’elle mobilise et les responsabilités qu’elle engage.

Dans ce contexte, l’IAM s’impose comme un levier structurant. Il constitue le socle permettant de rendre visibles les agents, de maîtriser leurs habilitations, de tracer leurs actions et de définir les conditions dans lesquelles leur autonomie peut être acceptée. Autrement dit, la sécurisation des agents IA ne pourra pas reposer sur des mesures périphériques : elle suppose une approche de gouvernance intégrée, articulant identité, contrôle d’accès, supervision et validation humaine.

Pour les organisations, l’enjeu n’est pas de freiner l’adoption de l’IA agentique, mais de l’encadrer dans un modèle de confiance soutenable. Cela implique dès aujourd’hui de poser des choix structurants : cartographier les usages, intégrer les agents dans les dispositifs IAM, distinguer les identités humaines et non humaines, adapter les politiques d’autorisation, et définir des garde-fous proportionnés à la criticité des actions confiées.

À mesure que les architectures se standardiseront et que les offres du marché gagneront en maturité, les entreprises les mieux préparées seront celles qui auront traité les agents IA non comme de simples assistants innovants, mais comme de nouveaux acteurs du SI, soumis aux mêmes exigences de sécurité, de traçabilité et de gouvernance que tout composant critique.

La question n’est donc plus de savoir si les agents IA trouveront leur place dans l’entreprise, mais dans quelles conditions de maîtrise. Pour les RSSI, le sujet est clair : la capacité à industrialiser l’IA agentique dépendra moins de la performance des modèles que de la robustesse du cadre IAM et de gouvernance mis en place pour l’encadrer.

Si, vous aussi, vous vous interrogez sur la gestion des accès des agents IA ou souhaitez approfondir la sécurisation de ces nouveaux usages, nous serions ravis d’échanger avec vous. N’hésitez pas à nous solliciter pour partager vos enjeux ou explorer ensemble des pistes adaptées à votre contexte.

1. Wavestone – Global AI Survey 2025  – AI Adoption and Its Paradoxes: Global AI survey 2025 | Wavestone)
2. PagerDuty (2025) More than Half of Companies (51%) Already Deployed AI Agents. Pager Duty, March 2025. Available at: 2025 Agentic AI ROI Survey Results (Accessed: 2 January 2026)
3. Cybernews (2025) Unapproved AI Tools in the Workplace. September 2025. Available at: https://cybernews.com/ai-news/ai-shadow-use-workplace-survey/ (Accessed: 2 January 2026).

Cet article Sécuriser les agents IA : pourquoi l’IAM devient central est apparu en premier sur RiskInsight.

Aussi, malgré de belles réussites et le rôle cardinal de l’identité dans les transformations des entreprises, l’IAM demeure une thématique dénigrée dans les organisations, synonyme de « mal nécessaire » plutôt que « d’enjeu clé » pour l’entreprise.

Comment redorer le blason de l’IAM ? Comment mieux l’expliquer pour lui donner sa juste place dans l’entreprise ?

Le paradoxe de l’identité

Un moteur essentiel des programmes de transformation…

Cette situation est paradoxale tant l’identité joue un rôle fondamental dans les programmes de transformation actuels, en présentant trois atouts majeurs.

• Elle est tout d’abord un pilier de la cybersécurité en permettant de :
  • Disposer d’une connaissance homogène de l’ensemble des utilisateurs, en centralisant les informations essentielles comme le nom, le manager, la fonction et bien d’autres caractéristiques propres à chacun ;
  • Garantir l’unicité des personnes via la publication d’un référentiel unique ;
  • Contrôler et adapter les accès des utilisateurs tout au long de leur cycle de vie ;
  • S’inscrire dans une démarche Zero Trust en veillant à ce que seules les bonnes personnes, avec le bon niveau de droit et le bon niveau d’authentification accèdent aux ressources appropriées.
• Elle constitue également un facilitateur métier essentiel, notamment pour :
  • Accélérer l’adoption de service Cloud, et le déploiement de nouvelles applications grâce à la création automatique de comptes et l’attribution simplifiée des droits (souvent par le biais d’un outil IGA – Identity Governance & Administration) ;
  • Faciliter l’ouverture contrôlée du SI à et vers des tiers : des partenaires, des fournisseurs ou en cas de création de Joint Ventures ;
  • Améliorer, grâce au CIAM (Customer Identity and Access Management), la relation client et la mise en conformité réglementaire en simplifiant la création progressive des comptes et le respect des règlements sur la vie privée tels que la RGPD en France.
• Enfin, avoir une gestion des identités efficiente est une condition sine qua none pour offrir une expérience utilisateur à l’état de l’art, combinant confort et exigences de sécurité :
  • Un accès fluide et sans couture à toutes ses applications et ses données, quel que soit son contexte d’accès ;
  • Des droits d’accès accordés automatiquement et disponibles le jour de son arrivée ;
  • D’un portail unique pour effectuer et suivre ses demandes ad hoc.
  • Des tableaux de bord parlants et des campagnes de revues ciblées pour répondre aux exigences réglementaires sans sur-solliciter les managers et les process owners.

… mais une thématique injustement considérée

Malgré les avantages significatifs qu’elle représente, la thématique de l’identité est rarement au centre des préoccupations des entreprises. Elle est plutôt perçue comme un mal nécessaire, voire occupe une place de « vilain petit canard ». Ainsi, il est commun de constater les écueils lorsque l’identité est insuffisamment bien gérée, et encore plus courant de considérer comme normaux et acquis les avantages qu’elle produit.

Au-delà du simple constant, il convient de comprendre les raisons qui ont mené à cette situation de manque d’investissements, de sponsoring, voire de reconnaissance.

Première explication du paradoxe : la dispersion des gains attendus vers différents bénéficiaires. En effet, l’IAM est, par nature, très transverse dans l’entreprise. Pour réussir, elle se doit d’embrasser un large panel de sujets et mobilise donc de nombreuses parties prenantes. Si chacune d’elles y verra des gains ; aucune ne se démarquera suffisamment pour endosser la responsabilité première. À titre d’exemples :

• L’identité permet de simplifier la mise en relation client, sujet d’intérêt majeur pour un responsable marketing/digital, mais pas pour le responsable conformité.
• Ce dernier verra dans l’identité un avantage significatif pour répondre aux exigences des commissaires aux comptes en matière de revue des accès.
• Le DSI attendra de l’identité une gestion homogène et automatique de l’attribution des comptes et des droits, synonymes de gains financiers, notamment en coûts de licences, en charge de support, etc.
• Quant au RSSI, sa priorité sera de supprimer les accès en cas de départ et d’appliquer le principe de « moindre droits attribués » ou encore la détection au plus tôt des comportements « suspects ».

Deuxième explication : comme toute transformation, qui plus est transverse, le lancement et la réussite d’un projet d’identité sont conditionnés par des prérequis indispensables.

La difficulté et l’effort nécessaire pour réunir ces prérequis dépendent du contexte de chaque entreprise ; mais les prérequis eux-mêmes sont relativement constants et peuvent s’articuler autour de 4 axes :

• La qualité des données : aussi bien pour les données consommées par l’IAM (organisations, structures, données d’identité provenant des RH…) que pour les données que l’IAM doit mettre à disposition (identifiants des comptes applicatifs, attributs dans les applications…).
• La connaissance profonde des processus de bout-en-bout : celle-ci est indispensable pour prévoir les impacts sur les utilisateurs des changements à venir mais surtout pour être en capacité de changer et d’harmoniser les manières de faire et ne pas reconduire l’existant « parce que l’on a toujours fait ainsi ».
• La maîtrise des applications à raccorder : il est nécessaire de mobiliser à la fois des sachants techniques (technologies utilisées, API disponibles…) et des sachants fonctionnels (populations utilisatrices, modèle de données, modèle d’habilitation…).
• Enfin et surtout, la capacité à imposer un cadre IAM « normatif », à trouver un compromis et à arbitrer tant sur la cible (modèle opérationnel, cadre fonctionnel, attributs et règles de gestion, processus d’arrivée/mobilité/départ, cadre de raccordement normé pour les applications…) que sur la trajectoire et les indicateurs de réussite (priorités, lotissement…). Pour le dire en une phrase « Ce n’est pas à l’IAM de panser ce qui a été mal pensé ou ce qui est devenu inadapté avec le temps».

Troisième et dernière explication : une gestion complète de l’identité repose sur plusieurs briques technologiques complémentaires. Avec des origines variées et des dénominations quelque peu ambigües, il n’est pas toujours facile pour un non-expert du domaine de comprendre précisément l’apport en propre de chacune de ces briques :

• IGA – Identity Governance & Administration: Gouvernance des identités
• IAI – Identity Analytics & Intelligence : Analyse et contrôle des données
• PAM – Privileged Access Management: Gestion des comptes à privilèges
• AM – Access Management: Authentification et contrôle d’accès
• CIAM – Customer Identity & Access Management: Gestion des identités clients

De plus, ces dénominations ont évolué dans le temps, parfois de manière légitime pour rendre compte d’évolutions majeures, parfois plutôt sous l’effet d’éditeurs souhaitant démarquer leur proposition de valeur. L’apparition de nouvelles fonctionnalités (détection temps réel, gestion du consentement, etc.) et les innovations proposées par les éditeurs font également évoluer le champ lexical de l’IAM.

Comment donner à l’identité sa juste place dans l’entreprise ?

Pour surmonter ce paradoxe, les pistes usuelles (sponsor de haut niveau, plus de moyens, évangélisation…) sont nécessaires mais souvent insuffisantes. Des transformations plus structurantes s’imposent.

Unifier les forces de l’identité sous une même bannière

Les thématiques IAM sont apparues en ordre dispersées dans les entreprises et ont muries à des rythmes très différents. Il en résulte que, encore trop souvent, les équipes sont isolées.

Il est donc impératif de rapprocher toutes les équipes et les budgets traitant de l’identité sous une même barrière. Et si l’union fait la force comme dit le proverbe, l’objectif n’est pas uniquement de « faire nombre » pour être visible, légitime et avoir voix au chapitre dans l’organisation.

Les synergies sont en effet nombreuses :

• Faire de l’identité un sujet pérenne et récurrent, a minima au niveau du CoDIR DSI, et dans toutes les évolutions de l’entreprise.
• Définir une proposition de valeur globale, proposer une offre unifiée plus lisible pour les métiers et les responsables applicatifs qui pourront s’appuyer sur un interlocuteur unique.
• S’inscrire dans la durée pour tirer parti des feuilles de route des éditeurs, créer une démarche d’amélioration continue et se préparer aux évolutions à venir de l’entreprise : réorganisations, fusions-acquisitions, nouvel ERP…
• Améliorer la cohérence des services IAM et se piloter avec des indicateurs de service de bout-en-bout.
• Garantir un haut niveau d’expertise en valorisant les savoir-faire des équipes, en les fidélisant et en offrant des perceptives d’évolution plus riches.

Cette transformation profonde peut apparaître comme délicate et source de risques pour les entreprises les moins matures en IAM. C’est pourquoi il est possible de l’initier progressivement, en partant d’un des axes suivants :

• Rapprocher sous une même organisation les équipes travaillant sur les différentes thématiques IAM : IGA, IAI, AM, PAM et même CIAM.
• Unifier les équipes en charge des projets et celles en charge du « RUN » afin de proposer une approche « produit » de chaque service d’identité, et s’inscrire dans une logique d’amélioration continue.
• Étendre la responsabilité des équipes IAM sur le contrôle des données enfin de pouvoir s’engager sur des indicateurs et, au final, sur la qualité du service rendu et perçu.

Sur ce dernier point, précisons néanmoins que les équipes IAM ne peuvent endosser la responsabilité de la qualité des données et des référentiels de l’entreprise. Il s’agira néanmoins de garantir la qualité du service rendu en s’assurant à la fois du bon fonctionnement des services IAM (le « contenant ») et de la qualité des données manipulées (le « contenu »). Ainsi, les équipes IAM doivent s’outiller et s’organiser pour superviser, contrôler et alerter la qualité des données reçues comme l’usage qui en est fait.

Une unification avantageuse mais qui oblige

Cette ambition d’unification, qui met l’IAM en pleine lumière, oblige de facto le responsable Identité à être exemplaire dans son rôle et ses responsabilités :

• Face à ses clients: disposer d’une offre de service claire, tenir compte des retours et des réalités du terrain, définir et respecter une feuille de route d’évolutions, fournir des indicateurs de qualité du service rendu « parlants » c’est-à-dire ayant un sens dans le quotidien des métiers, valoriser les gains et les bénéfices…
• Vis-à-vis des autres parties prenantes dans l’entreprise (RH, Achats, Cybersécurité, Conformité réglementaire, Audit et contrôle…) : communiquer, matérialiser et aider à l’appropriation de la proposition de valeur de l’Identité au quotidien et lors de transformations structurantes (réorganisations, acquisitions…), trouver des voies de compromis, monter le caractère « gagnant-gagnant » des évolutions de processus et de modèle opérationnel, partager les rôles et responsabilités de chacun, illustrer les impacts en cas de manquements…
• Pour ses équipes: disposer d’un modèle opérationnel robuste, équilibrer les responsabilités entre collaborateurs internes et prestataires externes, construire une véritable ambition RH à moyen et long terme (validation de l’expertise, gestion des talents, construction de parcours d’évolutions, valorisation de la filière IAM…).

Conclusion

L’unification des services IAM est une tendance de fond et, d’ici 3 ans, une large majorité des grandes entreprises aura convergé vers ce modèle, a minima partiellement.

Ce mouvement ne résulte pas toujours d’une volonté de repositionner de manière durable l’identité dans l’organisation. Il est parfois subi par les équipes pour pallier des manques de ressources, d’expertise ou dans un espoir de maîtrise des coûts ; renforçant dans ce cas le sentiment de manque de considération.

Pourtant, les opportunités sont nombreuses pour démontrer la nécessité de repenser en profondeur son ambition IAM et de lui donner sa juste place : obsolescence technique des outils IAM, stratégie d’entreprise pour basculer vers des solutions Cloud, difficultés à accompagner les transformations structurantes de l’organisation, nouvelles exigences réglementaires, ou résultats d’une simple enquête de satisfaction auprès des utilisateurs ou des responsables d’applications…

Oserez-vous les saisir ?

Cet article Comment donner à l’identité sa juste place dans l’entreprise est apparu en premier sur RiskInsight.