IA pour l’IAM : Une trajectoire pragmatique plutôt qu’une révolution

1.    L’IA n’est plus un fantasme, c’est une réalité que l’IAM ne doit pas manquer

Il y a deux ans, nous posions la question de savoir si l’IA pouvait constituer une révolution pour l’IAM dans notre article « L’intelligence artificielle, une révolution pour l’IAM ? – RiskInsight ». Nous insistions déjà sur la nécessité d’une approche nuancée, fondée sur des cas d’usage concrets, une logique de test and learn et une exigence de confiance compatible avec les enjeux propres à l’identité et aux accès.

Aujourd’hui, le constat a gagné en précision : l’IA n’a pas provoqué la rupture que certains annonçaient, mais elle commence à y trouver une place réelle, plus ciblée et surtout plus pragmatique.

Ce que l’on observe aussi c’est que l’IA entraine un élargissement du périmètre de l’IAM : l’IAM doit désormais aussi traiter les enjeux liés à l’IA et aux agents IA.
Pour approfondir ce point, nous vous invitons à consulter notre article « Sécuriser les agents IA : pourquoi l’IAM devient central – RiskInsight ».

Pour rappel, l’intelligence artificielle s’impose progressivement comme un levier de transformation des systèmes d’information, et l’IAM n’échappe pas à cette dynamique. Face à la multiplication des identités portée par des transformations de nature différente, qu’il s’agisse d’évolutions d’infrastructure avec le cloud, de changements de vision métier avec l’essor du CIAM ou encore de l’arrivée de nouvelles technologies comme les agents d’IA, les organisations doivent composer avec des modèles d’habilitation toujours plus riches et difficiles à maintenir.

Dans ce contexte, l’IA promet de rendre les services IAM plus efficaces et plus accessibles, qu’il s’agisse de recommandations intelligentes, d’assistants conversationnels, d’une meilleure exploitation des données ou du traitement de volumétrie difficilement gérable par des approches classiques.

Toutefois, ces apports appellent à la prudence. L’IAM touche directement à la sécurité des accès : à ce stade, l’IA doit y rester un outil d’assistance, sous supervision humaine, car la responsabilité ne saurait lui être déléguée. Sur le terrain, elle se manifeste d’ailleurs encore majoritairement sous forme de briques périphériques (copilots, chatbots, agents) qui viennent enrichir l’existant sans bouleverser les fonctions critiques. L’enjeu n’est donc plus tant de savoir si l’IA a sa place en l’IAM, mais d’identifier où et comment l’appliquer de manière réellement pertinente.

 

2.    Quels cas d’usage IA ont réellement du sens en IAM ?

Les apports de l’IA dans l’IAM sont répartis de manière inégale :

• L’​​​​Identity Governance & Administration (IGA) concentre l’essentiel des initiatives grâce à ses volumes de données et ses décisions fréquentes (revues, validations, recommandations)
• L’Access Management (AM) est lui aussi largement mis en avant, avec des projets visant avant tout à accélérer et fluidifier le parcours d’authentification des utilisateurs.
• Le Privileged Access Management (PAM) voit émerger des usages plus ciblés, notamment autour de la détection et de la surveillance des comportements à privilèges.
• Le potentiel de l’IA dans le Customer Identity and Access Management (CIAM) reste encore relativement peu exploité, alors même qu’il tend à devenir stratégique. Il apparaît notamment dans l’émergence d’agents IA capables d’interagir ou d’agir pour le compte des utilisateurs, en particulier via des chatbots.
• L’IA présente aujourd’hui une valeur limitée pour les Trust Services, dont les processus sont déjà largement automatisables sans IA, et se positionne davantage en support périphérique

Pour structurer ces initiatives sans tomber dans l’effet catalogue, deux grandes familles de cas d’usage se distinguent :

1. Ceux qui visent à résoudre des irritants connus dans les processus existants
2. Ceux qui permettent de traiter des problématiques que les approches traditionnelles ne parviennent pas à adresser.

La valeur de l’IA émerge d’abord des irritants actuels de l’IAM…

Cette première famille de cas d’usage constitue généralement le point d’entrée le plus naturel, car elle s’appuie sur des processus IAM déjà en place.

L’IA y joue alors un rôle d’accélérateur, en réduisant les coûts et la charge opérationnelle, tout en améliorant l’expérience, la qualité de service et la rapidité d’exécution, sans remettre en cause le modèle de contrôle.

…pour devenir un levier permettant de dépasser les limites des approches traditionnelles

La seconde famille de cas d’usage relève d’un registre différent : l’IA n’y vise plus seulement un gain de temps, mais ouvre des capacités d’analyse inaccessibles aux approches classiques, en croisant de multiples signaux (identité, organisation, droits, usage, événements) sur des volumes importants. Elle permet notamment de détecter à grande échelle des accès atypiques, tels que des combinaisons rares de droits, des habilitations incohérentes avec une fonction ou des accumulations liées à des exceptions successives.

L’IA rend également possible l’analyse de trajectoires d’habilitation, en identifiant comment certains profils dérivent au fil des mobilités, projets ou urgences, afin de cibler les actions de remédiation. Elle permet aussi une priorisation intelligente de ces remédiations en combinant criticité des applications, sensibilité des données et signaux d’usage, tandis que dans le domaine du PAM, des usages émergents visent à repérer des comportements à privilèges inhabituels pour déclencher des contrôles renforcés.

Enfin, cela ouvre également la voie à une délégation de tâches à plus faible valeur ajoutée, comme le traitement de tickets de niveau 1, pour lesquelles l’automatisation était techniquement envisageable mais économiquement difficile à justifier. Aujourd’hui, certaines solutions IAM « boostées » à l’IA rendent cette substitution réaliste et accessible.

La multiplication des irritants et des pistes d’automatisation ne doit pas pour autant conduire à déployer l’IA de manière indiscriminée. Certains besoins se traitent efficacement à l’aide de règles ou d’algorithmes simples, et dès lors que l’on touche aux accès, chaque erreur potentielle comporte un risque de sécurité. Il est donc essentiel, une fois les cas d’usage identifiés, de les sélectionner et de les prioriser, plutôt que d’accumuler les initiatives.

 

3.    Prioriser l’IA dans l’IAM avant qu’elle ne devienne un empilement d’initiatives

Une fois les cas d’usage pertinents identifiés, il convient de déterminer ceux sur lesquels concentrer les efforts, car tous ne justifient pas le même niveau d’investissement. La priorisation peut ainsi s’appuyer sur deux axes clés : la valeur ajoutée et la complexité de mise en œuvre.

La difficulté réside ici dans la capacité à analyser rigoureusement ces deux axes pour chaque cas d’usage.

Le premier axe, relatif à la valeur, peut ainsi être appréhendé à travers plusieurs sous critères :

• La réduction des coûts opérationnels : mesurer comment le cas d’usage permet d’éviter certains coûts récurrents
• Les gains d’efficacité et la réaffectation des efforts : la capacité à libérer du temps et à réorienter les équipes vers des tâches à plus forte valeur ajoutée.
• La diminution du risque cyber: l’impact du cas d’usage sur la réduction d’un risque identifié en matière de cybersécurité, d’informatique ou de contrôle
• La contribution aux enjeux réglementaires et stratégiques : dans quelle mesure le cas d’usage répond à une attente réglementaire ou stratégique prioritaire (par exemple, DORA, BCE, audits)
• L’impact sur les populations concernées : apprécier à qui le cas d’usage rend service et avec quelle fréquence d’usage, car un usage modeste mais mobilisé au quotidien par un grand nombre d’utilisateurs peut créer plus de valeur qu’un cas d’usage plus ambitieux mais limité à un périmètre restreint. Les principales populations à considérer sont généralement les administrateurs IAM, les intégrateurs IAM, les utilisateurs finaux et les managers approbateurs.

Le second axe, la complexité peut être évaluée selon quatre dimensions complémentaires. Elle inclut :

• L’exploitation des données : dans quelle mesure les données nécessaires au cas d’usage sont disponibles, de qualité suffisante et accessibles dans des conditions compatibles avec sa mise en œuvre.
• La complexité technique : l’effort technologique requis pour déployer le cas d’usage, qu’il s’agisse des intégrations, de l’architecture, des modèles d’IA mobilisés ou des dépendances vis-à-vis du système d’information existant.
• La complexité organisationnelle : le niveau de coordination nécessaire entre les équipes, les périmètres et les processus pour porter le cas d’usage de manière effective.
• Les risques associés : les risques cyber, réglementaires ou opérationnels susceptibles d’être introduits ou renforcés par la mise en œuvre du cas d’usage.

Pour rappel, cette approche vise avant tout à guider la réflexion et à structurer les arbitrages, et n’est qu’une proposition qui doit donc être adaptée à chaque contexte.

Les cas d’usage à fort impact mais rapides à déployer doivent être privilégiés. À l’inverse, ceux mobilisant des efforts importants (données indisponibles, intégrations complexes, exigences de sécurité élevées) pour un bénéfice limité doivent être écartés ou différés. Pour rendre l’arbitrage concret, une logique “matrice” fonctionne bien :

Toutefois, cette démarche suppose aussi d’être lucide sur un point : l’IA dépend fortement des données (qualité, complétude, traçabilité, référentiels) et de la capacité à l’exploiter de manière sécurisée. Sans fondations solides, même un cas d’usage prometteur restera au stade de démonstration. Car pour produire de la valeur en conditions réelles, il doit pouvoir s’appuyer sur des bases IAM suffisamment robustes : qualité des données, structuration des référentiels, stabilité des processus, lisibilité du modèle d’habilitation, etc. Ainsi, la priorisation doit être confrontée à la réalité des solutions disponibles et à leur maturité.

 

4.    Un marché en effervescence, des usages encore largement inégaux

Le marché IAM s’anime fortement autour de l’IA, avec des feuilles de route qui s’étoffent et l’émergence de produits dits « IA-native », conçus dès l’origine pour intégrer des mécanismes d’assistance, d’analyse et d’automatisation. Ces approches répondent généralement soit à un besoin ciblé, soit à une logique de différenciation sur un marché en forte évolution.

En parallèle, les solutions IAM historiques enrichissent progressivement leurs offres avec des fonctionnalités d’IA et bénéficient généralement de moyens plus importants que les acteurs IA‑native pour soutenir cette transformation, principalement dans des environnements cloud, plus propices à leur déploiement que les architectures on‑premise.

Il subsiste toutefois un décalage notable entre promesse et réalité en production : la plupart des fonctionnalités disponibles aujourd’hui relèvent encore de l’assistance périphérique (recherche, résumé, copilots) plutôt que d’une IA véritablement embarquée dans les fonctions critiques.

L’adoption reste par ailleurs progressive, en particulier dans les grands comptes, où la priorité demeure l’optimisation de l’existant, la stabilisation des référentiels, la réduction de la dette technique et la conformité. Les approches IA-native, encore relativement nouvelles, doivent s’intégrer à une trajectoire réaliste et à un modèle d’exploitation clair. L’IA ne saurait être considérée comme un produit miracle, mais bien comme un levier à inscrire dans une transformation globale de l’IAM.

 

5.    Conclusion – De l’effet d’annonce à une trajectoire maîtrisée

L’IA appliquée à l’IAM semble franchir un cap. Le véritable enjeu n’est pas d’accumuler les cas d’usage : il s’agit de construire une démarche cohérente, sélective et durable. Parce qu’elle intervient sur la décision d’accès, l’IA en IAM exige un niveau de prudence supérieur à d’autres domaines. La promesse de l’automatisation ne doit jamais masquer la responsabilité de l’humain et des organisations. Toute recommandation doit pouvoir être comprise, contestée et justifiée, notamment en contexte d’audit. Il faut définir clairement qui valide et qui arbitre, garantir l’acceptation des équipes métier sans laquelle l’IA sera contournée, assurer la conformité réglementaire et cadrer rigoureusement les données exposées aux assistants pour prévenir toute exfiltration d’informations sensibles.

Pour tenir cette trajectoire, il ne suffit pas d’évaluer les cas d’usage isolément : il faut faire évoluer les fondations (qualité des données identitaires, référentiels, modèle de rôles, contrôles), définir un modèle opérationnel capable de superviser l’IA au quotidien et sécuriser les usages émergents, notamment autour des agents d’IA. L’IA pour l’IAM ne doit donc pas être pensée comme une révolution immédiate, mais comme une progression graduelle, des briques d’assistance vers des capacités d’analyse avancées pour finalement arriver à des automatisations mieux maîtrisées.

Au fond, bien aborder l’IA dans l’IAM, c’est avancer avec pragmatisme, en ciblant les usages présentant le meilleur équilibre entre valeur et complexité, en gardant la maîtrise des décisions sensibles et en restant attentif à la maturité réelle du marché.

 

6.    Cinq priorités pour lancer une trajectoire IA en IAM

En résumé, voici les points à garder en tête pour s’adapter à cette transformation :

1. Identifiez les cas d’usage IA qui ont réellement du sens pour l’IAM, qu’il s’agisse d’améliorer l’existant ou d’ouvrir de nouvelles capacités d’analyse et d’automatisation.
2. Définir objectivement la valeur et la complexité de chaque cas d’usage afin de les prioriser en vue de leur mise en œuvre.
3. Construisez une trajectoire progressive, maîtrisée et gouvernée, plutôt qu’accumuler des initiatives sans vision d’ensemble.
4. Le marché se structure rapidement : échangez avec vos éditeurs pour comprendre ce qu’ils proposent réellement.
5. Renseignez-vous aussi sur les nouvelles solutions émergentes, notamment IA-native, et n’hésitez pas à nous solliciter si vous souhaitez confronter vos premiers retours de terrain ou enrichir votre vision du marché.