L'identité ne se résume plus à donner des droits. Elle doit aider l'entreprise à avancer et à décider.
Pendant longtemps, l'IAM a surtout cherché à automatiser les opérations IT. Cette évolution reflète en réalité une transformation beaucoup plus large du rôle de l'informatique dans l'entreprise.
L'IT a longtemps été regardée principalement comme un centre de coûts à optimiser. Progressivement, les entreprises ont compris qu'elle pouvait aussi accélérer les métiers, réduire le time-to-market, permettre de nouveaux services et produire des données utiles à la décision.
L'IAM suit exactement cette transformation. Ariovis ne construit donc pas sa stratégie en partant d'un catalogue d'éditeurs : nous choisissons des technologies parce que nous croyons à leur place dans l'évolution du marché IAM.
Le marché IAM bouge extrêmement vite. Cette page représente notre lecture d'architectes, à date d'août 2026.
Les frontières entre IGA, Access Management, autorisation fine, PAM, identités machines et agents IA peuvent encore fortement évoluer. Ariovis suit attentivement ces transformations et fera évoluer cette lecture avec elles.
Trois générations de valeur se sont succédé dans l'informatique d'entreprise. L'IAM les a suivies, presque pas à pas.
Industrialiser et réduire les coûts
Comment automatiser ce que l'IT réalise manuellement ?
Cette première génération de l'IAM suit la vision historique de l'IT comme poste de dépenses à optimiser.
Accélérer les métiers
Comment l'identité permet-elle aux métiers d'aller plus vite ?
Au fur et à mesure que l'IT devient un accélérateur business, l'IAM cesse d'être uniquement un outil exploité par l'IT : il devient un service consommé par l'entreprise.
Piloter le risque et mieux décider
Comment l'identité permet-elle de prendre une meilleure décision ?
Le parallèle avec l'informatique décisionnelle est direct : le SI n'est plus seulement là pour exécuter, il produit aussi l'information nécessaire à la décision.
Netwrix Identity Manager, historiquement Usercube, occupe une place particulière dans notre lecture du marché.
Pour Ariovis, la v5 est une rupture majeure : Usercube a engagé extrêmement tôt une transformation que beaucoup d'éditeurs IGA historiques ont dû — ou doivent encore — entreprendre, celle du traitement de la dette architecturale nécessaire au SaaS.
Le point fondamental n'est pas seulement « Usercube sait fonctionner dans le Cloud ». Le point est que l'éditeur a traité son architecture suffisamment tôt pour devenir SaaS sans sacrifier son modèle on-premises.
Aujourd'hui, Netwrix Identity Manager conserve des possibilités SaaS et on-premises. Pour Ariovis, c'est une caractéristique extraordinairement importante : elle permet à une organisation de faire évoluer sa stratégie d'hébergement sans nécessairement devoir changer de produit IAM.
La réussite de Usercube n'est pas simplement d'être devenu SaaS. C'est d'être devenu SaaS sans condamner l'on-premises.
Dans les plateformes IGA que nous suivons, Ariovis considère cette continuité SaaS / on-premises comme exceptionnellement différenciante. Nous ne promettons pour autant aucune migration magique ou transparente : une vraie réversibilité se démontre projet par projet.
Netwrix Identity Manager est aujourd'hui la solution privilégiée d'Ariovis pour la gouvernance des identités.
Historiquement, l'Access Management se résumait vite à trois briques : authentification, SSO, MFA.
Aujourd'hui, le SaaS, les applications mobiles, les partenaires, les clients, les API, la fédération, l'authentification adaptative, la gestion des sessions et le CIAM font de l'identité le chemin d'accès direct aux services de l'entreprise.
L'Access Management est donc devenu une infrastructure business critique : quand il tombe, ce n'est pas l'IT qui s'arrête, c'est l'activité.
Une bonne plateforme d'Access Management doit faire oublier sa complexité à l'utilisateur sans la faire disparaître pour l'architecte.
Le rapprochement Ping / ForgeRock constitue une trajectoire de marché très intéressante : la plateforme élargit progressivement son périmètre autour de l'identité.
Notre réserve d'architecte arrive immédiatement : ce n'est pas parce qu'une plateforme élargit sa couverture fonctionnelle qu'elle doit nécessairement prendre toutes les décisions d'identité. C'est précisément le débat du chapitre suivant.
Les deux univers se rapprochent fonctionnellement. Leurs contraintes architecturales, elles, restent profondément différentes.
Plus de finesse → plus de contexte → plus de dynamisme → plus de runtime
Zone de rencontre ?
Plus de policy lifecycle → plus de gouvernance → plus d'audit → plus de contexte identitaire et organisationnel
Une plateforme IGA doit représenter le réel de l'organisation, avec des interfaces métier riches : managers, responsables applicatifs, équipes IAM, audit et sécurité doivent pouvoir travailler avec.
Elle travaille principalement sur le temps long : arrivée, mobilité, demande, certification, réconciliation, recalcul. Elle est parfaitement compatible avec une logique Web et SaaS.
Un moteur d'autorisation fine répond à une autre question : cette identité peut-elle effectuer cette action, sur cette ressource, avec ce contexte, maintenant ?
Il est directement dans le chemin d'exécution. Son budget de latence est donc extrêmement faible. Il a besoin de policies et d'attributs immédiatement utilisables — pas de devenir une énorme application métier pour rendre une décision.
L'IGA est la tour de contrôle. Le FGA est au plus proche du moteur.
Une plateforme IGA peut ajouter une fonctionnalité « runtime authorization ». L'architecte doit ensuite poser les vraies questions :
La convergence fonctionnelle ne fait pas disparaître la physique d'un système distribué.
Saviynt est un acteur majeur, innovant, et son évolution matérialise exactement la question que nous nous posons sur le marché. Avec Agent Access Gateway, l'éditeur ajoute une capacité destinée à contrôler au runtime certaines actions, notamment celles d'agents IA.
Nous suivons ce module avec attention, mais cela ne signifie pas que nous soyons convaincus par l'objectif de convergence lui-même. C'est une expérience architecturale très intéressante à observer, qui pose immédiatement la question des compromis.
Les organisations qui choisissent historiquement Saviynt recherchent notamment une plateforme IGA SaaS, moderne, riche fonctionnellement, avec une expérience utilisateur et un cockpit de gouvernance poussés, centralisée, capable de donner une vision large de l'identité et des accès. C'est exactement la logique de tour de contrôle décrite plus haut — ce n'est pas historiquement la même contrainte qu'un moteur d'autorisation conçu pour intervenir dans le runtime d'une application.
Un IGA peut vivre avec une interface Web riche, des traitements complexes, des workflows, des appels à un SaaS distant, des synchronisations et de l'asynchrone. Un moteur d'autorisation runtime, lui, se place dans le chemin critique d'une transaction : l'application attend sa décision avant de poursuivre. Son budget de latence doit rester extrêmement faible, presque imperceptible. Il n'existe pas de chiffre universel — cela dépend des architectures — mais quelques centaines de millisecondes tout à fait acceptables dans certaines interactions SaaS deviennent potentiellement problématiques lorsqu'elles s'ajoutent à chaque décision applicative.
Plus une plateforme IGA SaaS descend vers le runtime, plus elle risque de devoir introduire des composants, caches et mécanismes distribués qui l'éloignent de la simplicité architecturale ayant justement fait l'intérêt du modèle SaaS.
On choisit notamment une plateforme comme Saviynt pour obtenir un beau control plane SaaS centralisé. Mais pour prendre des décisions extrêmement rapides au plus près des applications, il peut falloir progressivement faire redescendre des briques dans l'infrastructure. C'est précisément là que nous nous interrogeons. Agent Access Gateway nous intéresse surtout parce qu'il rend visible le compromis architectural que le marché devra résoudre. Aujourd'hui, Ariovis est plus convaincu par la complémentarité de technologies spécialisées que par la recherche d'une plateforme unique capable de tout absorber : un excellent IGA conçu comme une tour de contrôle métier riche, et un excellent moteur d'autorisation conçu dès le départ pour décider vite dans le runtime — plutôt qu'une plateforme contrainte de faire des compromis dans les deux architectures. C'est notre conviction d'architectes en août 2026, pas une vérité définitive : le marché évolue vite et nous suivons notamment Saviynt avec attention pour voir comment ces contraintes seront réellement résolues.
Nous préférons aujourd'hui faire extrêmement bien dialoguer deux architectures spécialisées plutôt que demander à chacune de devenir l'autre.
Qui est Matthieu ? Dans quelle organisation travaille-t-il ? Quel rôle possède-t-il ? Qui a validé ses accès ? Jusqu'à quand ?
Matthieu peut-il effectuer cette action précise sur cette ressource précise, depuis cet appareil, avec ce contexte et ce niveau de risque, maintenant ?
Pourquoi obliger nécessairement la même plateforme à être simultanément une application métier riche de gouvernance et un moteur minimaliste, extrêmement rapide, placé dans le chemin critique de chaque transaction ?
L'IGA sait que Matthieu possède un rôle commercial. Il sait pourquoi ce rôle existe et qui l'a accordé.
Mais cela ne répond pas nécessairement à : Matthieu peut-il exporter 50 000 dossiers clients depuis cet appareil, dans ce contexte, maintenant ? C'est un autre problème.
Le principe est simple. Le PEP — application, API ou gateway — intercepte l'action et demande une décision. Le PDP évalue identité, action, ressource, contexte, attributs, risque et politique, puis rend sa décision.
Une règle d'autorisation importante n'a pas nécessairement à être recodée et maintenue indépendamment dans chaque application.
Notre conviction est nette : nous ne voulons pas qu'Axiomatics devienne un IGA. Nous voulons qu'Axiomatics soit excellent pour prendre une décision qu'un IGA n'a historiquement pas été architecturé pour prendre.
Et inversement : Netwrix Identity Manager n'a pas besoin de devenir Axiomatics pour parfaitement gouverner les identités, rôles et attributs nécessaires à cette décision.
Axiomatics est le partenaire privilégié d'Ariovis pour l'autorisation fine et dynamique.
Trois responsabilités distinctes, trois moments différents. Les informations circulent entre les couches, mais ces plateformes ne prennent pas la même décision.
Ces plateformes ne prennent pas nécessairement la même décision et n'interviennent pas au même moment. C'est précisément ce qui rend leur complémentarité intéressante.
La première manière de protéger un privilège consiste à ne pas le donner inutilement.
Selon les cas d'usage, nous utilisons Netwrix PAM / Privilege Secure et Keeper. Ces technologies servent une architecture, elles ne la remplacent pas.
Le PAM complète une bonne architecture d'identité. Il ne remplace ni la gouvernance des droits ni le moindre privilège.
Nos partenariats orientent notre expertise, pas notre diagnostic. D'autres plateformes sont parfaitement légitimes selon le contexte.
Dans un environnement très Microsoft-first, Entra peut être le meilleur choix.
Une architecture Keycloak saine peut parfaitement être conservée et enrichie.
Plateformes majeures, suivies par Ariovis et rencontrées chez nos clients.
Même logique : une plateforme mature et adaptée ne doit pas être remplacée simplement pour changer de partenaire.
Une plateforme déjà pertinente ne devient pas mauvaise parce qu'Ariovis possède un autre partenaire privilégié.
Nos partenariats nous permettent :
Mais un partenaire n'est jamais une conclusion d'architecture.
Être partenaire d'un éditeur nous donne de l'expertise. Cela ne doit jamais nous retirer notre indépendance de jugement.
Il pourrait être une architecture dans laquelle :
Les frontières bougent. Certaines fonctions convergeront probablement. D'autres resteront peut-être séparées à cause de leurs contraintes architecturales.
Notre travail n'est pas de prédire quel logo finira par absorber quel marché. Notre travail consiste à construire aujourd'hui des architectures capables de fonctionner, d'évoluer et de rester compréhensibles lorsque le marché aura encore changé.
Security meets Business.
