Autorisation runtimePartenaire technologique — autorisation fine et dynamique
Avoir un droit ne suffit pas
à savoir si l'action doit être autorisée.
Une plateforme de gouvernance sait qui possède quel droit. Une plateforme d'Access Management sait qui vient de s'authentifier. Ni l'une ni l'autre ne peut décider, au moment précis d'une action, si celle-ci doit réellement avoir lieu dans ce contexte.
C'est ce constat, issu de nos projets, qui nous a conduits à l'autorisation fine et dynamique — puis à Axiomatics, après plusieurs mois d'étude et de tests.
- Une page de conviction, pas une brochure produit.
- Notre position reste indépendante : tout système n'a pas besoin d'un moteur d'autorisation externe.
Le point de départ : une limite structurelle de l'IAM classique
Une plateforme IGA gouverne très bien la légitimité d'un droit : qui le possède, pourquoi il lui a été attribué, pour combien de temps, qui l'a validé, comment il doit être revu.
Une plateforme d'Access Management sécurise très bien l'entrée : elle authentifie l'utilisateur, protège son parcours et applique des politiques d'accès aux applications.
Mais certaines décisions ne peuvent raisonnablement être prises qu'au moment exact où l'action est exécutée — parce qu'elles dépendent de la ressource concernée, de la situation et du contexte, pas seulement du profil du demandeur.
Des questions qu'un rôle ne peut pas trancher seul
Toutes ces questions supposent des informations disponibles uniquement au moment de l'action.
- Ce médecin peut-il consulter CE dossier patient, maintenant ?
- Ce conseiller bancaire peut-il consulter CE client, alors qu'un lien particulier existe entre eux ?
- Cette application peut-elle utiliser CETTE donnée dans CE contexte ?
- Cet utilisateur peut-il effectuer CETTE action depuis CET environnement ?
- Cet agent IA est-il autorisé à appeler CET outil, avec CES données, pour CETTE finalité ?
La question n'est plus seulement « a-t-il le rôle ? » mais « dans ce contexte précis, cette action précise doit-elle réellement être autorisée ? ».
C'est exactement le territoire de l'autorisation fine et dynamique.
Le RBAC est essentiel. Il ne peut simplement pas tout exprimer.
Nous concevons, enseignons et implémentons des modèles de rôles. Le RBAC reste le meilleur outil pour structurer et gouverner un très grand volume de droits, et il le restera.
Notre conviction est plus nuancée : le RBAC organise très bien les droits, mais certains usages ont besoin de davantage de contexte pour être décidés correctement.
RBAC
Décider par les rôles
La décision repose principalement sur l'appartenance à un rôle. Lisible, gouvernable, auditable — et suffisant pour l'essentiel des droits d'une organisation.
RBAC au glossaireABAC
Ajouter les attributs et le contexte
La décision prend en compte des attributs du demandeur, de la ressource, de l'action et de l'environnement.
ABAC au glossaireReBAC
Comprendre les relations
Certaines décisions dépendent des liens entre les personnes et les objets : propriétaire, responsable, délégataire, rattachement.
ReBAC au glossairePolicy-based
Expliciter la règle
La règle métier et de sécurité devient une politique explicite et centralisée, au lieu de conditions dispersées dans le code des applications.
PBAC au glossaire
« Les conseillers peuvent consulter les dossiers clients. »
« … sauf si le conseiller entretient une relation personnelle avec ce client, sauf cas particulier explicitement autorisé. »
La première phrase est un rôle. La seconde est une politique contextuelle : elle mobilise une relation, une exception et une décision prise au moment de la consultation. C'est ce type de scénario qu'Axiomatics documente publiquement pour illustrer le passage d'une logique de rôles à une logique enrichie par des attributs.
L'objectif n'est pas d'empiler les acronymes, mais de repérer la limite : le moment où la décision cesse de tenir dans un rôle.
Une technologie intéressante ne suffit pas à faire un partenaire.
Nous n'avons pas ajouté une case « Authorization » à notre catalogue. Le chemin a été plus long, et c'est ce qui donne sa valeur au partenariat.
La révélation
En dix ans d'IAM, je n'avais jamais véritablement compris ce que les éditeurs me disaient sur l'autorisation. Quand j'ai enfin compris, ça a été une révélation — et c'est cette révélation qui a mis tout ce qui suit en mouvement, jusqu'à ce partenariat.
— Matthieu Filizzola, fondateur La veille
C'est en étudiant les analyses Gartner sur l'évolution de l'IAM et de l'autorisation que nous avons commencé à regarder Axiomatics de près.
L'étude
Nous avons analysé la technologie, audité l'approche, examiné les modèles d'autorisation proposés et la manière dont ils s'articulent avec les architectures existantes.
Les tests
Nous avons testé la plateforme pendant plusieurs mois : politiques, sources d'attributs, points d'enforcement, comportement réel des décisions.
Le challenge
Nous avons confronté les cas d'usage à nos propres projets IAM, pour distinguer ce qui relève vraiment de l'autorisation runtime de ce qui reste mieux traité ailleurs.
Les rencontres
Nous avons rencontré leurs équipes, longuement échangé, dîné ensemble, confronté nos visions du marché et de l'avenir de l'IAM.
L'alignement
Nous avions validé la technologie. Restait à savoir si nous voulions construire avec les personnes qui la portent, et si leur stratégie rejoignait la nôtre. La réponse a été oui.
Le partenariat
Aujourd'hui, la relation dépasse la mise en avant d'un logo : échanges réguliers, interventions et talks communs, vision partagée de l'évolution de l'autorisation.
Nous voulions comprendre ce qu'ils construisaient, pourquoi ils le construisaient, et où ils pensaient que l'IAM allait.
Ce que nous avons aimé dans leur stratégie
Axiomatics défend une autorisation fine, policy-based, dynamique, externalisée et contextualisée, applicable aux applications, aux APIs, aux microservices et aux données. La société se présente comme à l'origine d'une approche runtime de l'autorisation fine, largement fondée sur l'ABAC.
Sa stratégie « Orchestrated Authorization » vise à séparer et centraliser la logique de décision plutôt que de laisser chaque application réimplémenter ses propres règles. C'est précisément le point qui nous parle.
Notre conviction : les règles d'autorisation critiques ne devraient pas être disséminées sous forme de centaines de conditions opaques dans les applications, les APIs, les microservices, les scripts et les développements métier.
Gouverner les droits
Décider qui devrait légitimement disposer de quoi, et pourquoi.
Authentifier
Établir de manière fiable qui est en train d'agir.
Décider l'autorisation
Évaluer, au moment de l'action, si elle doit être permise dans ce contexte.
Appliquer la décision
Faire respecter cette décision là où l'action se produit réellement.
Ce que cette séparation rend possible
- Davantage de cohérence entre applications
- Des politiques centralisées plutôt que dupliquées
- Une modification plus maîtrisable des règles
- Une décision réellement contextualisée
- Une meilleure auditabilité
- La capacité d'expliquer pourquoi une action a été autorisée ou refusée
Cela ne signifie pas qu'une architecture externalisée soit nécessaire partout : pour de nombreux systèmes, les mécanismes classiques restent parfaitement pertinents. Nous la recommandons quand la complexité métier, la sensibilité des ressources ou le caractère dynamique de la décision le justifient.
Quatre couches, quatre questions différentes
Ces briques ne se remplacent pas : elles répondent à des questions distinctes, et c'est leur articulation qui fait l'architecture.
01
Gouvernance
IGA — par exemple Netwrix Identity Manager
Qui devrait avoir quels droits ?
Attribution, justification, durée, revue et cycle de vie des habilitations.
Offre Gouvernance des identités02
Authentification et accès
Access Management — Ping Identity, Entra ID selon l'architecture
Qui est en train de se connecter ?
Parcours d'authentification, SSO, fédération, MFA, politiques d'accès applicatives.
Offre Access Management & CIAM03
Autorisation runtime
Axiomatics
Cette action précise est-elle autorisée dans ce contexte précis ?
Évaluation d'une politique à l'instant de la demande, à partir d'attributs, de relations et de signaux de contexte.
Offre Autorisation fine04
Enforcement
Application, API gateway, microservice, couche de données (PEP)
Où applique-t-on effectivement la décision ?
Le point où la décision devient un effet réel : autoriser, refuser, filtrer, masquer.
Une demande, une politique, une décision
Sans entrer dans le détail d'un dialecte XACML : conceptuellement, la mécanique tient en trois temps.
- WHOQuiL'identité qui agit — humaine ou non — et ses attributs.
- WHATQuoiLa ressource visée et ses propres caractéristiques.
- ACTIONActionL'opération demandée : lire, modifier, exporter, exécuter.
- CONTEXTContexteEnvironnement, moment, canal, relations, signaux de risque.
- PURPOSEFinalitéPourquoi l'action est demandée, lorsque cette information est disponible.
Le point de décision (PDP)
La politique évalue ces éléments. Axiomatics sait recevoir des signaux provenant de différentes sources — systèmes d'identité, solutions de sécurité, attributs propres à l'organisation — pour évaluer la règle en fonction du contexte.
- PermitL'action est autorisée dans ce contexte.
- DenyL'action est refusée, avec la traçabilité correspondante.
- + éléments d'enforcementSelon l'architecture, la décision peut s'accompagner des informations nécessaires au point d'application (PEP) : filtrage, périmètre, masquage.
PDP : point de décision. PEP : point d'application. Deux rôles distincts — décider n'est pas appliquer.
Pour aller un peu plus loin : ALFA
Axiomatics est étroitement associée à ALFA — Abbreviated Language for Authorization — un langage conçu pour exprimer les politiques d'autorisation de façon nettement plus lisible que le XACML XML brut.
Ce détail compte : quand une politique est lisible, elle peut être relue, discutée avec le métier, gouvernée et maintenue. C'est une condition pratique de l'auditabilité.
- Politiques fondées sur les attributs
- Prise en compte des relations
- Structures hiérarchiques
- Mécanismes de combinaison et de priorité
L'autorisation ne concerne plus seulement les utilisateurs
Le système d'information n'est plus peuplé uniquement de personnes. Applications, services, workloads, APIs, machines et agents IA demandent eux aussi l'accès à des données, des outils et des actions métier.
Pour un agent IA, être correctement authentifié ne dit rien de ce qu'il devrait pouvoir faire. La question devient : que peut faire cet agent, sur quelles ressources, dans quel contexte, avec quelles données et pour quelle finalité ?
- humains
- applications
- services
- workloads
- APIs
- machines
- agents IA
C'est pourquoi nous considérons l'autorisation runtime comme une composante particulièrement intéressante des architectures agentiques. Axiomatics traite publiquement ces sujets AI, LLM et agents — mais reste avant tout une plateforme d'autorisation : l'IA en est un cas d'usage, pas la définition.
Une relation qui se vit ailleurs que sur une page de logos
Les échanges se poursuivent bien au-delà de la phase d'évaluation : nous discutons régulièrement avec leurs équipes, nous intervenons ensemble et nous partageons notre lecture de l'évolution de l'IAM et de l'autorisation.
La photo ci-contre a été prise à l'European Identity and Cloud Conference 2025, à Berlin : c'est le type de moment où une relation technologique devient un vrai travail commun.
- Plusieurs mois d'étude, d'audit et de tests de la plateforme
- Des échanges approfondis avec leurs équipes technologie et stratégie
- Des talks et interventions communs
- La présence d'Axiomatics dans nos architectures et nos offres liées à l'autorisation
Nous préférons une page honnête à une accumulation de logos clients : nous ne publions aucune référence Axiomatics qui ne soit pas explicitement confirmée par le client concerné.
Depuis 2025, Axiomatics est une société du groupe Leonardo
Leonardo a annoncé l'acquisition d'Axiomatics en 2025 ; la société apparaît désormais comme « a Leonardo company ». Le rapprochement a été présenté autour du Zero Trust, de l'autorisation dynamique et fine, des environnements critiques et d'une cybersécurité de confiance.
Pour un acteur européen comme Ariovis, c'est un élément de contexte intéressant. Nous n'en tirons aucune conclusion au-delà de ce qui a été annoncé.
Ce qu'Ariovis apporte, au-delà de l'outil
Une bonne politique d'autorisation ne commence pas par écrire du code ALFA. Elle commence par comprendre le métier, la ressource, les identités, les règles, les risques et les exceptions.
Avant la technologie
- Identifier les décisions réellement complexes
- Cartographier les règles existantes
- Distinguer ce qui relève du rôle, de l'attribut, de la relation ou du contexte
- Arbitrer ce qui reste dans l'application et ce qui mérite d'être externalisé
- Identifier les sources d'attributs
- Définir la gouvernance des politiques
Concevoir et construire
- Concevoir l'architecture d'autorisation
- Identifier les points d'enforcement
- Construire les politiques
- Intégrer le moteur de décision
- Connecter les sources de contexte
- Intégrer les PEP et tester les décisions
Faire vivre et transmettre
- Documenter les politiques et leurs justifications
- Organiser leur maintenance et leur cycle de vie
- Accompagner développeurs, architectes, sécurité et métiers
- Former les équipes aux modèles d'accès
Notre position de conseil
Tout ne mérite pas un moteur d'autorisation.
Externaliser une règle simple, stable et portée par une seule application n'apporte pas nécessairement de valeur — elle ajoute une dépendance et une complexité d'exploitation.
La technologie doit rester proportionnée au problème. C'est une conviction Ariovis fondamentale, et elle vaut aussi quand elle nous conduit à ne pas proposer un moteur d'autorisation.
L'autorisation fine devient réellement intéressante quand
- Les règles sont nombreuses
- Le contexte change la décision
- Plusieurs applications doivent appliquer la même politique
- Les données sont sensibles
- Les règles métier évoluent souvent
- L'accès dépend de relations entre personnes ou objets
- Les décisions doivent pouvoir être expliquées
- Des agents ou systèmes autonomes accèdent à des outils puissants
Si aucun de ces critères ne s'applique, nous le disons — et nous restons sur les mécanismes déjà en place.
Questions fréquentes
L'ABAC remplace-t-il le RBAC ?
Non. Le RBAC reste le meilleur moyen de structurer et gouverner un grand volume de droits, et nous continuons à le concevoir et à l'enseigner. L'ABAC, le ReBAC et les politiques contextuelles complètent le modèle de rôles là où la décision dépend d'attributs, de relations ou de circonstances que le rôle ne peut pas porter.
Quelle différence entre gouvernance des identités et autorisation runtime ?
La gouvernance des identités décide de la légitimité d'un droit : qui devrait l'avoir, pourquoi, pour combien de temps, et comment il est revu. L'autorisation runtime décide de l'usage réel de ce droit au moment précis d'une action, en fonction du contexte. Les deux sont complémentaires et ne se remplacent pas.
Autorisation runtime et authentification, est-ce la même chose ?
Non. L'authentification établit qui agit ; l'autorisation détermine si l'action demandée doit être permise. Un utilisateur ou un agent parfaitement authentifié peut légitimement se voir refuser une action précise dans un contexte précis.
Comment Ariovis a-t-il choisi Axiomatics ?
En étudiant les analyses Gartner sur l'évolution de l'IAM et de l'autorisation, nous avons commencé à regarder Axiomatics. Nous avons ensuite étudié la technologie, audité l'approche et testé la plateforme pendant plusieurs mois, avant d'échanger longuement avec leurs équipes sur leur stratégie. Le partenariat est venu au bout de ce cheminement, pas avant.
Faut-il externaliser toutes ses règles d'autorisation ?
Non, et nous le déconseillons. Pour de nombreux systèmes, les mécanismes classiques restent parfaitement adaptés. L'externalisation devient intéressante quand la complexité métier, la sensibilité des ressources, le nombre d'applications concernées ou le caractère dynamique de la décision le justifient.
Axiomatics est-il un produit de sécurité des agents IA ?
Non. Axiomatics est une plateforme d'autorisation fine et dynamique pour les applications, les APIs, les microservices et les données. La sécurisation des usages IA et des agents en est un cas d'usage particulièrement intéressant, traité publiquement par l'éditeur, mais ce n'est pas la définition du produit.
Une décision d'accès ne tient pas toujours dans un rôle.
Si votre modèle de rôles commence à porter des exceptions, des conditions et des cas particuliers, c'est souvent le signe qu'une partie de vos règles relève désormais de l'autorisation contextuelle. Parlons de votre contexte : nous vous dirons aussi si un moteur d'autorisation n'est pas nécessaire.