Le privilège ne doit plus être permanent : pourquoi le PAM doit sortir de son isolement
Pendant longtemps, le PAM a été traité comme un sujet à part.
Un sujet sensible, certes. Un sujet critique, souvent. Mais un sujet séparé.
On y parlait coffres, comptes d’administration, sessions, secrets, rebonds, traçabilité. Bref, un univers technique, maîtrisé par quelques spécialistes, avec ses propres outils, ses propres pratiques, et souvent ses propres équipes.
Cette approche a eu son utilité. Elle a permis de reprendre le contrôle sur des accès très sensibles, de mieux tracer les usages à privilèges, de réduire certains risques évidents.
Mais elle ne suffit plus.
Aujourd’hui, le privilège ne peut plus être pensé comme un simple périmètre technique à sécuriser. Il doit être traité comme un objet de gouvernance, comme un sujet d’architecture, et comme une capacité dynamique de l’entreprise.
Autrement dit : le PAM doit sortir de son isolement.
Le vrai problème n’est pas seulement l’accès privilégié. C’est le privilège persistant.
Dans beaucoup d’environnements, le risque ne vient pas uniquement de l’existence de comptes à privilèges.
Il vient du fait que ces privilèges existent trop longtemps, trop largement, et trop silencieusement.
Un compte d’administration qui reste actif en permanence. Un droit élevé accordé “au cas où”. Un accès technique conservé après un changement de rôle. Une exception jamais revue. Une habilitation sensible héritée puis oubliée.
Le danger n’est donc pas seulement dans la puissance du privilège. Il est dans sa durée, dans sa banalisation, et dans son manque de gouvernance.
C’est là qu’un programme PAM purement technique atteint vite ses limites.
Le PAM historique a sécurisé l’accès. Il n’a pas toujours gouverné le privilège.
Le PAM classique a été construit pour répondre à des besoins très concrets :
Protéger les mots de passe sensibles ;
Encadrer les sessions d’administration ;
Tracer les actions ;
Limiter l’exposition des comptes les plus critiques.
C’est indispensable. Et cela le restera.
Mais ce socle ne répond pas, à lui seul, aux questions qui comptent désormais le plus :
Pourquoi cette personne dispose-t-elle encore de ce niveau de privilège ? Ce privilège est-il toujours justifié ? Pourrait-il être temporaire plutôt que permanent ? Ce droit est-il cohérent avec le rôle réel de l’utilisateur ?
Quelle articulation existe entre le cycle de vie IAM et l’élévation de privilège ? Comment réduire le standing privilege sans casser l’exploitation ?
Sans réponse à ces questions, le PAM protège l’exécution, mais ne transforme pas réellement le modèle d’accès.
Le bon changement de perspective : gouverner le privilège comme on gouverne l’identité
Chez Ariovis, nous défendons une conviction forte : le privilège ne doit plus être traité comme une couche annexe, en bout de chaîne.
Il doit être remis dans le flux global de l’identité.
Cela signifie que l’accès à privilèges ne doit plus être regardé seulement comme :
Une session à ouvrir ; Un secret à protéger ; Un coffre à consulter.
Il doit être lu comme :
Un droit sensible à justifier ; Une élévation à encadrer ; Une durée à limiter ; Un contexte à évaluer ; Une gouvernance à rendre explicite.
À partir du moment où l’on fait ce déplacement, le PAM change de nature.
Il ne disparaît pas. Il devient plus intelligent.
Du privilège statique au privilège dynamique
C’est probablement l’évolution la plus structurante.
Dans beaucoup d’organisations, le privilège reste encore statique : il est attribué à l’avance, conservé longtemps, et utilisé quand nécessaire.
Ce modèle crée mécaniquement :
Plus de surface d’exposition ; Plus de dette d’habilitation ; Plus de difficultés d’audit ; Plus d’écarts entre l’usage réel et le droit accordé.
Le modèle cible, lui, consiste à tendre vers un privilège plus dynamique :
Accordé quand nécessaire ;
Borné dans le temps ;
Conditionné par le contexte ;
Tracé de bout en bout ;
Révocable rapidement ;
Cohérent avec le rôle réel et le besoin réel.
On parle souvent ici de JIT (Just-in-Time), d’élévation temporaire ou de Zero Standing Privilege.
Mais derrière les termes, l’idée est simple :
Ne plus laisser des droits puissants dormir en permanence dans le système.
Pourquoi le PAM a besoin de l’IAG
C’est ici que le lien avec l’Identity and Access Governance (IAG) devient fondamental.
Un PAM isolé sait protéger un accès.
Mais pour gouverner réellement le privilège, il a besoin d’un cadre plus large :
Qui est la personne ? Quel est son rôle ? Quel est son périmètre réel ? Quelle est sa relation à la ressource ?
Quelle exception a été validée ? Quelle durée a été prévue ? Quel processus métier justifie cette élévation ?
Sans cette couche d’information gouvernée, le PAM reste très fort sur le contrôle, mais faible sur la justification.
L’IAG, elle, peut fournir précisément cette lecture :
Qualification des populations ;
Gouvernance des rôles ;
Visibilité sur les comptes et permissions ;
Articulation avec les processus JML (Joiner, Mover, Leaver) ;
Campagnes de revue pertinentes ;
Lien entre identité, habilitation et privilège.
Quand le PAM et l’IAG restent séparés, l’organisation protège mieux ses comptes sensibles, mais peine à rationaliser le privilège.
Quand ils travaillent ensemble, elle commence à reprendre la main sur sa trajectoire.
Pourquoi le PAM a aussi besoin de l’Access Management
Le second lien clé est celui avec l’Access Management.
Car un privilège moderne n’est plus seulement une question de compte technique.
C’est aussi une question de contexte d’accès.
Qui se connecte ? Depuis quel environnement ? Avec quel niveau d’assurance ? Sur quel périmètre ? Dans quelle situation de risque ? Pour accéder à quoi, exactement ?
Dans une architecture mature, l’accès sensible ne devrait pas être traité comme un bloc uniforme.
Il devrait être modulé selon :
La criticité de la ressource ; Le niveau de confiance sur l’identité ; Le contexte de connexion ; Le type d’action demandée ; Les signaux de risque disponibles.
Autrement dit, le privilège devient un sujet d’orchestration entre identité, authentification, contexte et contrôle.
Le piège à éviter : moderniser le PAM sans revoir le modèle d’accès
C’est une situation fréquente.
Une organisation modernise son bastion, améliore la rotation des secrets, renforce la traçabilité, industrialise les sessions, parfois même introduit des scénarios d’élévation.
Mais dans le même temps :
Les rôles restent flous ; Les comptes techniques restent mal gouvernés ; Les exceptions persistent ; Les habilitations en amont restent mal maîtrisées ; Les décisions d’accès restent peu lisibles.
Résultat : le PAM devient plus propre, mais le modèle global reste fragile.
La vraie modernisation du privilège ne consiste donc pas seulement à améliorer l’outil.
Elle consiste à réduire le privilège inutile, à mieux qualifier le privilège nécessaire, et à rendre sa gestion cohérente avec le reste de l’architecture IAM.
Ce que cela change concrètement pour les entreprises
Quand le PAM sort de son isolement, plusieurs effets apparaissent progressivement.
D’abord, les populations à privilèges deviennent mieux identifiées.
Ensuite, les droits sensibles deviennent plus facilement révisables.
Les exceptions techniques cessent progressivement d’être des zones grises permanentes.
Les trajectoires JIT deviennent enfin réalistes.
Les audits gagnent en lisibilité.
Et surtout, l’organisation commence à réduire son stock de privilèges dormants.
C’est un changement discret en apparence, mais majeur en profondeur.
Car en sécurité, le risque ne vient pas seulement de ce qu’un utilisateur fait.
Il vient aussi de ce qu’il pourrait faire à tout moment, sans justification renouvelée.
La bonne ambition : un PAM moderne, connecté au reste de l’IAM
Le futur du PAM n’est pas l’autonomie complète.
C’est l’interconnexion maîtrisée.
Un PAM moderne doit rester excellent sur ses fondamentaux : protéger, tracer, contrôler, superviser.
Mais il doit aussi s’inscrire dans une logique plus large :
Relié à une gouvernance d’identité claire ; Articulé avec les processus d’habilitation ; Capable de soutenir une élévation temporaire ; Alimenté par le bon contexte ; Intégré dans une vision Zero Trust plus globale.
C’est à cette condition que l’on passe d’un PAM défensif à un PAM réellement transformant.
En conclusion
Le privilège ne doit plus être considéré comme une exception technique gérée dans une bulle.
Il doit devenir un sujet de gouvernance, de cohérence et d’orchestration.
Le PAM reste une brique essentielle.
Mais sa pleine valeur n’apparaît que lorsqu’il cesse d’être isolé du reste de l’IAM.
Sortir le PAM de son isolement, ce n’est pas compliquer l’architecture.
C’est enfin traiter le privilège pour ce qu’il est vraiment : un droit sensible, temporaire par nature, qui mérite mieux qu’un simple stockage sécurisé.
Et c’est souvent là que commence la vraie maturité.
Un projet d’outillage IGA sur quatre viserait à remplacer SailPoint. Derrière cette estimation, une réalité : de nombreuses entreprises réévaluent leurs plateformes de gouvernance des identités. Mais pourquoi ?
Votre projet SailPoint IdentityIQ devait automatiser les habilitations, fiabiliser les arrivées et départs des collaborateurs et simplifier les campagnes de certification. Pourtant, les intégrations prennent du retard, les développements spécifiques s’accumulent et les bénéfices tardent à se concrétiser.
Votre intégrateur évoque la complexité du système d’information, l’éditeur rappelle les capacités de sa solution et votre direction s’interroge sur les résultats obtenus.
Et si votre situation était moins exceptionnelle que vous ne le pensez ?
Dans leur lecture des évolutions du marché de l’IGA, les analystes évoquent un ordre de grandeur intéressant : près d’un projet d’outillage sur quatre concernerait une démarche de remplacement de SailPoint. Si sa méthodologie n’est pas publiquement documentée, plusieurs données de marché et retours d’expérience rendent cet ordre de grandeur plausible.
Un projet IGA sur quatre pour remplacer SailPoint : un chiffre crédible ?
SailPoint occupe historiquement une place majeure dans la gouvernance des identités.
Lors de son Investor Day de juin 2026, l’éditeur revendiquait 23,2 % du marché mondial IGA en chiffre d’affaires, selon des données Gartner. Son implantation dans les grandes entreprises est particulièrement importante :
29 % du Forbes Global 2000 sont clients de SailPoint
53 % du Fortune 500 américain utilisent ses solutions
3 310 organisations clientes étaient recensées au 31 juillet 2026
Ces chiffres permettent de comprendre pourquoi SailPoint apparaît naturellement dans de nombreuses consultations de remplacement.
Sur les 2 000 entreprises du Forbes Global 2000, environ 580 sont clientes de SailPoint. Si elles réévaluent leur plateforme à un rythme comparable aux autres organisations, SailPoint représente potentiellement une part importante des solutions remises en concurrence.
L’estimation d’un projet sur quatre devient donc plausible, sans constituer une statistique mondiale démontrée.
Surtout, envisager un remplacement ne signifie pas quitter effectivement l’éditeur. Une organisation peut comparer plusieurs solutions et finalement décider de conserver SailPoint.
Microsoft a remplacé SailPoint IdentityIQ : pourquoi ?
En août 2024, Microsoft a publié un retour d’expérience détaillant son remplacement d’IdentityIQ par Entra ID Governance.
Le périmètre concernait environ 350 000 identités humaines et non humaines, plus de 25 000 groupes de sécurité et 10 000 objets d’habilitation.
Selon Microsoft, les nombreuses personnalisations d’IdentityIQ rendaient la plateforme progressivement plus complexe à maintenir. Certaines règles de gestion nécessitaient des développements spécifiques importants, mobilisant des ressources techniques conséquentes.
Fin 2022, Microsoft estimait consacrer plus de 1,5 million de dollars par an à la maintenance de son environnement IdentityIQ.
L’entreprise a finalement choisi une migration progressive vers Entra ID Governance, réalisée en environ six mois.
Microsoft disposait naturellement de circonstances particulières, notamment puisqu’elle développait elle-même la solution cible. Son expérience ne démontre pas la supériorité générale d’un produit.
Elle illustre néanmoins un phénomène bien réel : même une organisation disposant de moyens techniques considérables peut considérer que la complexité et les coûts de maintenance de sa plateforme IGA justifient un changement de technologie.
Même rester chez SailPoint peut nécessiter une transformation importante
Le témoignage de Nelnet, cliente d’IdentityIQ depuis 2016, apporte un autre éclairage.
En 2024, l’entreprise a entrepris sa migration vers SailPoint Identity Security Cloud, tout en conservant son éditeur historique.
Initialement prévue sur deux mois, la phase de recueil et de formalisation des exigences en a finalement nécessité près de quatre.
La difficulté provenait notamment des différences architecturales entre IdentityIQ et Identity Security Cloud, qu’il ne fallait pas considérer comme une simple nouvelle version du même produit.
Le projet a finalement abouti.
Cette expérience montre qu’un planning initial dépassé ne traduit pas nécessairement une mauvaise gestion côté client. La complexité de transformation peut aussi avoir été sous-estimée lors du cadrage.
Produit, intégrateur, organisation : pourquoi les projets IGA se compliquent-ils ?
Les difficultés rencontrées sur les programmes de gouvernance des identités ne sont pas toujours imputables à un seul facteur.
Un connecteur présenté comme disponible peut nécessiter des adaptations importantes pour couvrir réellement le provisionnement et les règles d’habilitation. Des personnalisations successives peuvent créer une dette technique difficile à maîtriser. Une architecture insuffisamment documentée peut également rendre chaque évolution dépendante de quelques experts.
IdentityIQ offre de puissantes possibilités de personnalisation. Cette flexibilité constitue un atout, mais peut également augmenter les coûts de maintenance lorsque les développements spécifiques se multiplient.
La qualité de l’intégration reste donc déterminante.
Lorsqu’une complexité technique prévisible n’a pas été identifiée en avant-vente ou pendant le cadrage, les difficultés qui en résultent ne peuvent pas être systématiquement attribuées à une mauvaise expression du besoin client.
Inversement, changer de logiciel sans revoir ses méthodes d’intégration ou ses règles de gouvernance peut reproduire les difficultés rencontrées.
L’essentiel est de comprendre ce qui relève du produit, de son implémentation ou de l’organisation du programme.
Un projet IGA en difficulté peut aussi être redressé
Chez un éditeur logiciel, Ariovis est notamment intervenu sur un programme à l’arrêt, marqué par une capacité de livraison insuffisante, un manque d’autonomie des équipes et une forte insatisfaction métier.
La reprise a consisté à clarifier les règles de gestion, restaurer les fondamentaux du cycle de vie des identités et reconstruire une feuille de route opérationnelle.
Cette intervention a permis de retrouver une trajectoire de livraison, de réduire les incidents et de renforcer l’autonomie des équipes.
Ce cas ne concerne pas spécifiquement SailPoint, mais il rappelle qu’un programme IGA en difficulté n’impose pas nécessairement un remplacement de sa plateforme.
La reprise de l’architecture, du delivery ou du pilotage peut parfois suffire.
Faut-il conserver ou remplacer SailPoint ?
Avant toute décision, trois trajectoires méritent généralement d’être étudiées : moderniser IdentityIQ, évoluer vers Identity Security Cloud ou sélectionner une nouvelle solution IGA.
En juin 2026, SailPoint indiquait que 85 % de sa base historique on-premises restait à migrer vers le SaaS, représentant environ 350 millions de dollars de revenu annuel récurrent.
L’annonce d’IdentityIQ 9.0 en octobre 2026 confirme par ailleurs la poursuite des investissements dans la solution on-premises.
Pour les organisations concernées, cette période constitue une occasion de réexaminer leur architecture, leurs coûts et leurs objectifs.
Une comparaison pertinente doit intégrer les capacités fonctionnelles, les personnalisations, les coûts d’intégration, la maintenance, le niveau d’autonomie et les risques de migration.
Un projet en difficulté ne signifie pas nécessairement un mauvais choix initial
Les décisions d’outillage reposent sur les informations disponibles au moment du choix : démonstrations, engagements techniques, références et estimations d’intégration.
Des difficultés peuvent ensuite apparaître lorsque la solution rencontre la réalité du système d’information. Elles peuvent également résulter de changements de besoins ou d’une évolution du marché.
Les expériences de Microsoft, de Nelnet et des entreprises qui réévaluent leurs plateformes historiques montrent que ces interrogations ne sont pas réservées aux organisations les moins matures.
L’estimation selon laquelle un projet IGA sur quatre viserait à remplacer SailPoint reste à confirmer. Elle ne constitue pas davantage un taux d’échec des projets SailPoint.
Mais elle rappelle une chose essentielle : remettre en question une plateforme IGA, ou chercher à comprendre les difficultés rencontrées pendant son déploiement, est une démarche légitime.
Le choix le plus pertinent n’est pas nécessairement de remplacer SailPoint, ni de poursuivre coûte que coûte le projet existant. C’est celui qui repose sur une compréhension objective des causes, des coûts et des bénéfices attendus.
Analyse Ariovis — octobre 2026. Les chiffres relatifs au marché et à la base installée proviennent des communications publiques de SailPoint. L’estimation « un projet sur quatre » est attribuée à Saviynt, sans méthodologie publique identifiée. Les témoignages Microsoft et Nelnet reflètent leurs contextes respectifs et ne constituent pas des statistiques représentatives du taux d’échec des projets IGA.
La question revient régulièrement dans les programmes PAM et dans les réflexions autour des systèmes d’information d’administration : faut-il réellement équiper tous les administrateurs d’un poste de travail d’administration dédié ?
Le coût matériel est la partie visible du problème. Une PAW, Privileged Access Workstation dans la terminologie Microsoft, implique aussi un deuxième environnement à maintenir, sécuriser, mettre à jour et supporter. Côté administrateur, elle ajoute un chemin supplémentaire entre le besoin métier et l’action technique.
Ce dernier point est essentiel. Un système d’information d’administration n’est pas uniquement conçu pour être sûr : il doit permettre aux administrateurs de comprendre facilement par où passer, avec quelle identité, depuis quel environnement et pour atteindre quelles ressources.
C’est une déclinaison très concrète de notre principe Security meets Business. Une sécurité tellement complexe qu’elle pousse les équipes à chercher des chemins parallèles finit par travailler contre elle-même.
La réponse en une phrase Il n’existe pas de Tier Model strict offrant exactement le niveau d’assurance d’une PAW sans les contraintes d’une PAW. Il est en revanche possible de concevoir plusieurs chemins d’administration, chacun associé à un niveau de risque, de confiance du terminal et de contrôle adapté.
Si votre objectif est d’appliquer strictement le Tier Model Microsoft et d’obtenir le niveau de garantie qu’il associe aux PAW, il n’existe pas de raccourci magique permettant d’obtenir exactement la même propriété de sécurité sans accepter les contraintes correspondantes.
Microsoft est aujourd’hui extrêmement explicite : le Tier Model AD DS fonctionne lorsque l’administration démarre depuis une station administrative approuvée correspondant au niveau administré. Pour Microsoft, la confiance commence dès le poste physique depuis lequel sont saisies les informations d’identification privilégiées.
L’ANSSI considère elle aussi que le poste physiquement dédié offre la meilleure garantie de sécurité. Mais lire uniquement cette recommandation ferait perdre une partie importante de son guide.
L’Agence précise que ses recommandations doivent être adaptées au contexte, que leur application linéaire n’est pas adaptée à tous les SI et invite explicitement à conserver « un esprit critique vis-à-vis du contexte d’application ». Le guide propose d’ailleurs plusieurs recommandations alternatives présentant différents niveaux de sécurité lorsque plusieurs architectures sont envisageables.
Le propos de cet article n’est donc pas : « comment éviter les PAW ? »
Il est plutôt : comment construire un SI d’administration dans lequel le niveau de protection est cohérent avec le risque, où les contrôles se complètent, et dans lequel les administrateurs savent simplement comment travailler ?
1. Commencer par les risques, pas par les PAW
Une organisation ne souffre pas du risque « absence de PAW ».
Elle peut en revanche souffrir :
qu’un malware présent sur un poste bureautique capture une identité d’administration ;
qu’un administrateur dispose en permanence de privilèges dont il n’a besoin qu’occasionnellement ;
qu’un prestataire puisse joindre directement un système sensible depuis un équipement non maîtrisé ;
qu’un compte permettant d’administrer vingt serveurs puisse en réalité atteindre deux cents machines ;
qu’une compromission initialement limitée devienne un mouvement latéral jusqu’au plan de contrôle.
C’est précisément pour cette raison que le guide ANSSI commence son architecture du SI d’administration par l’analyse de risques et la définition de zones de confiance, avant de descendre dans les composants techniques. L’Agence demande ensuite que ces zones soient matérialisées par les mécanismes appropriés : filtrage, authentification, chiffrement, cloisonnement, etc.
Ce que nous observons dans les programmes PAM
Notre retour d’expérience sur les programmes PAM conduit au même constat.
Nous avons audité ou fait évoluer des dispositifs dans lesquels une plateforme PAM existait déjà alors que subsistaient encore des privilèges permanents trop larges, des délégations incohérentes, des comptes historiques, des postes insuffisamment protégés ou des chemins d’administration mal maîtrisés. Un outil PAM peut sécuriser une partie du parcours sans corriger à lui seul le système de délégation, les flux réseau ou l’environnement depuis lequel le privilège est exercé.
Dans d’autres projets, le problème principal n’était même plus technique : il fallait clarifier ce qui était réellement privilégié, trouver les propriétaires, traiter les exceptions, modifier les habitudes d’exploitation et construire un modèle que les administrateurs utiliseraient effectivement.
C’est à cet endroit que la question économique devient saine. On ne cherche pas d’abord le contrôle le moins cher. On cherche à comprendre quel risque doit être réduit et quel niveau d’assurance est réellement nécessaire, sans imposer partout le parcours le plus lourd lorsque ce niveau n’est pas justifié.
C’est aussi l’approche que nous utilisons pour construire les trajectoires Zero Trust : partir des identités, des ressources, des processus, des risques et des contraintes d’exploitation avant de choisir les briques techniques.
Obtenez gratuitement une première évaluation de votre maturité et une feuille de route IAM Zero Trust adaptée à votre contexte. Générer ma feuille de route IAM Zero Trust
2. Ce que le Tier Model cherche réellement à préserver
Le Tier Model reste particulièrement utile parce qu’il introduit une idée très simple : toutes les ressources d’administration n’ont pas le même impact en cas de compromission.
Un contrôleur de domaine, une PKI, un système capable de déployer des agents sur les contrôleurs de domaine ou une infrastructure contrôlant les identités de l’entreprise ne sont pas au même niveau qu’une console permettant d’administrer une application métier isolée.
Microsoft définit aujourd’hui le Tier Model AD DS comme une hiérarchisation logique fondée sur les privilèges et capacités de contrôle, et non simplement sur la localisation physique dans le réseau. Microsoft précise immédiatement que la segmentation réseau reste complémentaire au modèle.
Cette notion de capacité de contrôle est fondamentale.
Un outil de sauvegarde capable de restaurer ou modifier les contrôleurs de domaine, un EDR disposant d’un contrôle système sur ceux-ci, un hyperviseur qui les héberge ou un service d’identité pouvant modifier les autorisations du domaine peuvent devenir des éléments équivalents au Tier 0, même s’ils ne s’appellent pas « Active Directory ».
C’est également la raison pour laquelle Microsoft a étendu le modèle historique avec son Enterprise Access Model : Control Plane, Management Plane et Data/Workload Plane. L’objectif reste d’empêcher qu’un plan inférieur puisse prendre le contrôle d’un plan supérieur, mais le raisonnement devient applicable aux environnements hybrides et cloud.
Schéma 1 — Classer les ressources selon leur capacité de contrôle
Le principe à préserver n’est donc pas « trois réseaux, trois comptes, trois ordinateurs » comme une recette immuable.
C’est plutôt :
Une source présentant un niveau de confiance insuffisant ne doit pas devenir le moyen de compromettre une ressource présentant un niveau supérieur.
À partir de là, il devient possible de réfléchir à l’ensemble du chemin d’administration.
3. Pourquoi Zero Trust ne supprime pas la segmentation réseau
Un raccourci fréquent consiste à opposer le Tier Model, supposément fondé sur le réseau, à une architecture Zero Trust supposément fondée uniquement sur l’identité.
Nous refusons cette opposition.
L’ANSSI présente le Zero Trust comme une démarche reposant notamment sur une évaluation dynamique du sujet, du contexte d’accès, de l’état de sécurité du poste utilisé et de la criticité de la ressource. Elle cite également explicitement la micro-segmentation parmi les principes utilisés par le modèle.
réseau seul → décision construite à partir de plusieurs signaux
Nous continuons à vouloir empêcher un administrateur base de données d’atteindre une console d’administration Active Directory s’il n’a aucune raison de le faire. Nous continuons à vouloir filtrer les ports, les destinations et les flux possibles. Nous continuons à vouloir isoler les zones d’administration.
En revanche, appartenir physiquement ou logiquement au « réseau admin » ne devrait plus automatiquement signifier que tout le réseau d’administration devient accessible.
Le réseau peut désormais participer à l’application d’une décision plus fine.
Schéma 2 — Une décision d’accès construite à partir de plusieurs signaux
Dans le cours IAM et Zero Trust que nous dispensons chez Ariovis, nous modélisons justement le ZTNA comme un Policy Enforcement Point supplémentaire : il applique la décision sur l’accès réseau tandis que le PAM contrôle certains accès privilégiés, l’Access Management les parcours d’authentification et les autres PEP les contrôles dont ils sont responsables.
Et nous insistons aussi sur une limite : le ZTNA ne remplace ni l’architecture du poste ni l’ensemble des mécanismes de segmentation.
L’objectif est que l’administrateur dispose du bon chemin, pas de tous les chemins.
4. Construire la confiance dans le terminal : le cas Ariovis
C’est ici que notre propre architecture permet de sortir de la théorie.
Chez Ariovis, nous n’utilisons pas une PAW dédiée pour chacune de nos opérations administratives.
Mais nous n’avons absolument pas retenu comme conséquence que tous les terminaux pouvaient être considérés de la même manière.
Les accès directs à notre SI sont réalisés depuis des équipements Ariovis enrôlés et administrés. Nos postes sont durcis, leurs possibilités d’exécution sont fortement contraintes — notamment avec AppLocker — et ils font l’objet d’une supervision de sécurité.
Notre Trust Center rend d’ailleurs publique une partie de ces mesures : comptes nominatifs, accès sensibles protégés, FIDO2, bastion journalisé et supervision de sécurité 24/7 opérée avec Dhala Cyberdéfense.
Les alertes et incidents de sécurité entrent ainsi dans une chaîne de supervision opérée 24/7 par notre SOC externalisé. Ce point est important dans une logique Zero Trust : nous ne considérons pas le niveau de confiance d’un terminal comme un état acquis définitivement parce qu’il a été fourni par Ariovis. La capacité à détecter une modification de ce contexte fait partie de la protection.
Mais la maîtrise du poste n’est qu’une partie du mécanisme.
Nos administrateurs sont placés dans des groupes dédiés. Ces groupes déterminent notamment leur possibilité d’utiliser Microsoft Global Secure Access pour joindre les zones réseau d’administration correspondant à leurs fonctions.
Un PC Ariovis ne dispose donc pas automatiquement d’un accès à toutes les zones internes parce qu’il est « corporate ».
De même, être administrateur ne revient pas à se retrouver dans un grand VLAN d’administration donnant accès à tout.
Nous cherchons plutôt à obtenir quelque chose de ce type :
Schéma 3 — Le chemin d’administration Ariovis
Microsoft Entra Private Access permet précisément de construire ce type de modèle. Les ressources privées peuvent être regroupées dans des applications, affectées à des utilisateurs ou groupes et associées à leurs propres stratégies Conditional Access.
Microsoft pousse d’ailleurs explicitement l’évolution depuis les modèles d’accès larges vers une segmentation par application, en observant quels utilisateurs et quels terminaux accèdent à quels FQDN, IP, ports et protocoles, puis en créant des règles plus précises.
Et nous ne prétendrions certainement pas qu’elle apporte automatiquement le même niveau d’assurance qu’une PAW dédiée utilisée pour administrer un Control Plane critique.
Elle illustre autre chose : la confiance dans un terminal peut être construite par niveaux et associée à des chemins différents selon le besoin.
Plusieurs niveaux de terminal, plusieurs niveaux d’assurance
Dans une autre entreprise, un premier niveau pourrait accepter certains usages depuis du BYOD après évaluation de quelques signaux de posture. Chez Ariovis, nous avions également étudié cette possibilité, notamment pour nos externes, mais nous l’avons rejetée au profit d’une expérience utilisateur plus simple et plus maîtrisée : un accès Guacamole, une authentification forte, puis une VM distante Ariovis déjà préparée avec tous les outils nécessaires. En pratique, l’utilisateur externe ouvre un navigateur web, s’authentifie une seule fois et accède immédiatement à son environnement de travail.
Nous basculons progressivement vers le passwordless. Même si le poste initial était compromis, il n’y aurait donc pas nécessairement de mot de passe réutilisable à voler. Nous envisageons même de cumuler un contrôle minimal du terminal entrant avec l’accès Guacamole : terminal suffisamment conforme + authentification forte + accès Guacamole = accès à l’environnement Ariovis.
Niveau
Environnement de départ possible
Exemple de contrôles
Usage envisageable
1
BYOD
Signaux de posture, authentification forte, rebond vers une VM maîtrisée
Isolation physique ou logique stricte, chaîne de confiance dédiée
Administration du plan de contrôle critique
Ces niveaux ne sont pas équivalents. Le niveau retenu doit découler de l’analyse de risque et de la criticité de l’opération.
L’ANSSI demande d’ailleurs l’utilisation d’équipements durcis et maîtrisés pour les accès aux données critiques et souligne les limites des informations remontées par un équipement personnel.
Le rebond ne transforme pas magiquement un équipement personnel en équipement Ariovis de confiance : il réduit ce que cet équipement peut atteindre et déplace une partie des contrôles dans une zone que nous maîtrisons.
Et si demain notre analyse de risque concluait qu’une opération extrêmement sensible ne doit jamais être réalisée depuis le même poste que les usages bureautiques habituels, la réponse serait probablement… une PAW.
Le raisonnement par le risque fonctionne dans les deux sens.
5. Pourquoi un bastion ne suffit pas
La même prudence doit s’appliquer à la stratégie PAM.
Dans plusieurs projets sur lesquels nous avons travaillé, une solution PAM était déjà présente mais le dispositif continuait de comporter des privilèges excessifs, des accès directs historiques ou des comptes dont le cycle de vie n’était pas réellement gouverné.
Autrement dit, faire passer une connexion RDP par un bastion ne suffit pas à rendre saine toute la chaîne qui précède et suit cette connexion.
Le bastion ne corrige pas automatiquement :
un compte trop puissant
un poste source compromis
un droit d’utilisation du bastion mal gouverné
une cible joignable par un autre chemin
un réseau autorisant des mouvements latéraux non nécessaires
une session enregistrée sans qu’aucune alerte exploitable soit produite.
La traçabilité doit devenir exploitable
Ce dernier cas est loin d’être théorique. Dans plusieurs environnements, nous avons constaté que la principale preuve PAM disponible était constituée d’enregistrements vidéo de sessions. Ils sont utiles en investigation mais extrêmement difficiles à exploiter de manière proactive à grande échelle.
C’est un retour d’expérience tellement fréquent que nous l’avons intégré à notre cours PAM : la traçabilité doit aller au-delà de l’enregistrement passif et alimenter des mécanismes de détection et de réaction.
L’embarquement PAM est un processus durable
L’autre retour d’expérience est celui de la durée. Dans des SI complexes, plusieurs années après le lancement d’un programme PAM, de nouveaux accès RDP ou SSH continuent encore à entrer dans le périmètre. L’embarquement n’est pas un événement unique : c’est un processus durable.
Cela change profondément le critère de réussite.
Le meilleur dispositif n’est pas celui qui produit le plus beau schéma d’architecture au lancement. C’est celui dans lequel un nouvel administrateur, un nouveau serveur, un nouveau prestataire ou une nouvelle application peuvent être ajoutés sans recréer une exception technique incompréhensible.
Nous avons même intégré dans notre enseignement un retour d’expérience particulièrement parlant : lors d’un exercice de Red Team, des actifs sensibles avaient été atteints non pas en cassant directement le bastion, mais en utilisant les droits gouvernés depuis l’IAG pour remonter vers celui-ci. Le PAM, l’IAG et l’Access Management formaient en pratique une même surface de contrôle, alors qu’ils avaient été pensés trop indépendamment.
C’est précisément pour cette raison que nous évaluons désormais les programmes PAM en regardant autant la gouvernance, l’identité, le terminal et les chemins réseau que le bastion lui-même.
Votre PAM protège-t-il réellement toute la chaîne d’administration ?
Évaluez gratuitement la maturité de votre dispositif, identifiez les écarts prioritaires et obtenez une première feuille de route adaptée à votre contexte. Lancer mon diagnostic PAM
6. Dessiner des chemins d’administration réellement utilisables
À ce stade, la question n’est plus simplement : « PAW ou pas PAW ? »
Pour chaque famille d’opérations, nous devons pouvoir répondre à six questions concrètes.
Question d’architecture
Points à qualifier
Quelle est la ressource ?
Quelle serait la conséquence de sa compromission ? Peut-elle en contrôler d’autres ?
Quelle identité l’administre ?
Compte quotidien ou identité distincte ? Droit permanent ou activé temporairement ? Quel périmètre réel ?
Depuis quel niveau de terminal ?
BYOD, équipement corporate, poste spécialisé ou PAW ?
Quel chemin réseau est nécessaire ?
Quels FQDN, IP, ports ou protocoles ? Pourquoi en ouvrir davantage ?
Faut-il un intermédiaire ?
PAM, bastion, gateway ou environnement de rebond ?
Quel contexte peut remettre en cause l’accès ?
Conformité du poste, niveau de risque, signal SOC, horaire, localisation ou changement de rôle ?
Le Tier Model reste utile pour déterminer la criticité de la destination.
Le Zero Trust permet d’être beaucoup plus précis sur les conditions dans lesquelles un chemin vers cette destination peut exister.
Et le travail d’architecture consiste à rendre le résultat exploitable.
Un administrateur ne devrait pas devoir connaître quinze règles de firewall et quatre technologies de sécurité pour comprendre comment faire son travail. Idéalement, son expérience est beaucoup plus simple : son identité détermine ce qu’il peut demander, le niveau de confiance de son poste détermine les environnements depuis lesquels cette demande peut être exercée, les privilèges sont limités au besoin et le réseau ne rend joignables que les interfaces utiles.
La complexité reste présente.
Mais elle est portée par l’architecture, pas par l’utilisateur.
C’est ce qui nous semble être le meilleur indicateur d’un SI d’administration correctement conçu : un chemin sûr doit également être un chemin compréhensible.
Faire monter vos équipes en maturité IAM et PAM
Nos formations relient les concepts, les architectures et les retours d’expérience terrain afin d’aider vos équipes à construire un dispositif adapté à leurs enjeux opérationnels. Découvrir nos formations IAM et PAM
7. Conclusion : quand faut-il conserver une PAW ?
Dans certains environnements, cette logique conduira à généraliser les PAW.
Dans d’autres, elle conduira à distinguer plusieurs populations et plusieurs niveaux de terminal.
Dans d’autres encore, elle fera surtout apparaître que le problème prioritaire n’est pas le poste mais les privilèges permanents, la mauvaise segmentation, les identités partagées ou les chemins d’accès directs laissés en parallèle du PAM.
Il n’existe donc pas de formule permettant d’implémenter « le Tier Model sans PAW ».
Il existe en revanche une manière beaucoup plus utile d’aborder le problème :
Comprendre ce que le Tier Model cherche à empêcher
Classer les ressources selon leur capacité de contrôle ;
Déterminer le niveau d’assurance nécessaire pour les atteindre
Construire le chemin d’administration le plus simple qui respecte ce niveau.
Une PAW est l’une de ces trajectoires.
Un poste corporate fortement maîtrisé associé à une identité dédiée, une segmentation réseau fine, du JIT et un contrôle continu peut en être un autre, pour les opérations dont le niveau de risque le permet.
Le point commun doit rester le même : un environnement moins fiable ne doit pas pouvoir devenir le chemin de compromission d’un environnement plus critique.
Et, surtout, l’administrateur doit toujours savoir par où passer.
Vous devez sécuriser ou faire évoluer vos chemins d’administration ?
Ariovis vous accompagne pour évaluer l’existant, qualifier les risques et construire une trajectoire PAM et Zero Trust cohérente avec vos contraintes d’exploitation. Parler de mon projet avec un expert Ariovis
SAP Identity Management entre dans sa dernière ligne droite. La maintenance principale de SAP IDM 8.0 s’arrête fin 2027 et SAP prévoit une maintenance étendue jusqu’en 2030. (SAP Community)
Il reste donc du temps. Mais plus vraiment celui d’attendre.
Pour les organisations qui utilisent encore SAP IDM, les deux prochaines années doivent servir à choisir la cible, reprendre la maîtrise de l’existant et engager réellement la migration.
Chez Ariovis, nous voyons aussi cette échéance comme une opportunité : celle de reprendre un IAM construit pendant parfois dix ou quinze ans, de comprendre ce qu’il fait réellement, d’éliminer une partie de sa dette et de reconstruire une véritable tour de contrôle des identités et des habilitations.
Et sur ce point, nous avons une conviction forte : la fin de SAP IDM ne doit pas conduire automatiquement à déplacer toute l’intelligence IAM dans Microsoft Entra.
2027 puis 2030 : le calendrier est maintenant connu
SAP IDM 8.0 reste en maintenance principale jusqu’à fin 2027, avec une possibilité de maintenance étendue jusqu’en 2030. SAP rappelle désormais explicitement à ses clients qu’il est temps de préparer leur future solution de gestion du cycle de vie des identités. (SAP Community)
Pour un SAP IDM significatif, nous préférons lire ce calendrier ainsi :
2026 : choisir la cible et commencer le projet.
2027 : sortir les premiers périmètres de SAP IDM.
2028-2029 : migrer les applications complexes, les rôles et la gouvernance.
Avant 2030 : ne plus dépendre de SAP IDM pour un processus critique.
Un SAP IDM encore en production aujourd’hui n’est pas nécessairement un problème.
Un SAP IDM dont personne ne sait précisément comment sortir en est un.
SAP oriente ses clients vers Microsoft Entra
C’est l’un des éléments importants du dossier.
SAP et Microsoft travaillent ensemble sur la transition des clients SAP IDM. SAP présente publiquement son partenariat avec Microsoft pour accompagner cette migration, et Microsoft maintient un guide détaillé expliquant comment déplacer différents scénarios SAP IDM vers Microsoft Entra. (SAP Community)
Le guide Microsoft couvre notamment le magasin d’identités, la gestion des utilisateurs, les scénarios de lifecycle, le provisioning vers des systèmes SAP et non-SAP et les mécanismes de gouvernance. (Microsoft Learn)
C’est une trajectoire crédible.
Mais il faut appeler les choses par leur nom : ce n’est pas une recommandation agnostique. SAP et Microsoft ont fait un choix de partenariat et proposent une trajectoire technologique commune.
Votre entreprise doit, elle, faire un choix d’architecture IAM.
Et surtout éviter un raccourci :
SAP IDM → Microsoft Entra ID → problème réglé.
Même Microsoft distingue d’ailleurs clairement Microsoft Entra ID de Microsoft Entra ID Governance et documente l’utilisation de composants SAP Cloud Identity Services dans certains flux de provisioning SAP. Pour S/4HANA, par exemple, les utilisateurs peuvent passer de Microsoft Entra ID vers SAP Cloud Identity Services, qui se charge ensuite du provisioning vers certaines applications SAP. (Microsoft Learn)
La disparition de SAP IDM ne fait donc pas disparaître les différentes fonctions qu’il remplissait.
Une IGA est une tour de contrôle
Microsoft Entra ID est une excellente plateforme.
Annuaire cloud, authentification, MFA, SSO, Conditional Access, intégration Microsoft : nous l’utilisons nous-mêmes très régulièrement dans les architectures de nos clients.
Mais une question reste essentielle :
où voulez-vous placer l’intelligence qui décide de qui doit avoir accès à quoi ?
Prenons un exemple.
Une collaboratrice devient responsable achats Europe au 1er octobre. Elle conserve son ancien poste jusqu’au 15 octobre pour assurer une transition. Son nouveau poste ouvre automatiquement certains accès. D’autres nécessitent une validation. Deux habilitations sont incompatibles au regard d’une règle de séparation des tâches.
Le sujet IAM n’est pas simplement :
« Dans quels groupes Entra faut-il mettre son compte ? »
Il faut déterminer :
Quelle personne occupe quel poste ?
À quelles dates ?
Quelles règles métier s’appliquent ?
Quels droits doivent être ajoutés ?
Lesquels doivent disparaître ?
Quelle exception nécessite une approbation ?
Existe-t-il un risque SoD ?
Les applications ont-elles réellement appliqué la décision ?
C’est cela, une tour de contrôle IGA.
L’IAM ne consiste pas seulement à créer des comptes. Il transforme le contexte et les règles métier en décisions d’accès, puis contrôle que ces décisions sont réellement appliquées.
C’est aussi ce que nous voulons dire chez Ariovis par Security meets Business.
Le risque inverse est de reconstruire un IAM essentiellement depuis les outils techniques : groupes, comptes, applications, scripts et packages d’accès.
Un IAM IT for IT.
Pourquoi nous regardons Netwrix Identity Manager pour remplacer SAP IDM
C’est précisément sur cette notion de tour de contrôle que Netwrix Identity Manager nous paraît particulièrement intéressant.
NIM distingue notamment la personne du ou des postes qu’elle occupe. Un collaborateur peut occuper plusieurs postes simultanément, avec des dates de début et de fin distinctes. Les habilitations peuvent suivre ces postes et être automatiquement retirées lorsque l’affectation prend fin.
Son modèle de données peut agréger les différentes informations nécessaires à la décision IAM : personnes, organisations, sites, postes, missions ou attributs propres au contexte de l’entreprise.
La logique devient alors simple :
le métier fournit le contexte ;
NIM gouverne et calcule ;
les briques techniques exécutent.
Microsoft Entra reste donc parfaitement à sa place.
NIM dispose d’un connecteur standard permettant la lecture et l’écriture avec Microsoft Entra ID.
Il ne s’agit donc absolument pas de choisir NIM contre Microsoft.
Il s’agit de choisir où vit l’intelligence IAM.
Votre SAP IDM existe déjà. Nous commençons par le récupérer.
Une migration de SAP IDM ne commence pas avec une architecture cible dessinée sur une slide.
Elle commence dans votre production.
Chez nos clients, nous rencontrons régulièrement des plateformes IAM historiques qui fonctionnent encore très correctement.
Elles ont simplement accumulé des années d’histoire.
Des règles Joiner/Mover/Leaver.
Des transformations de données RH.
Des rôles.
Des exceptions.
Des workflows.
Des connecteurs spécifiques.
Des scripts.
Des traitements batch.
Des rapports.
Des campagnes de certification.
Et parfois des comportements dont la connaissance est concentrée chez quelques personnes.
Sur un projet récent de remplacement d’une autre plateforme IGA historique, nous avons ainsi dû reprendre un environnement déjà structuré, avec plusieurs centaines de rôles métier, plusieurs unités organisationnelles et un lifecycle fonctionnel.
Ce client n’utilise pas SAP IDM.
Mais le problème de migration est exactement le même :
récupérer l’intelligence de l’ancien IAM avant de retirer l’ancien IAM.
Notre première intervention est donc très concrète.
Donnez-nous les accès de lecture nécessaires, la documentation disponible — même imparfaite —, les exports accessibles et les personnes qui connaissent encore la plateforme.
Nous prenons la photo.
Étape 1 : cartographier ce que SAP IDM fait réellement
Il faut retrouver les sources autoritaires, les flux RH, les règles de corrélation, les workflows, le modèle d’identité, les rôles métier et applicatifs, les affectations directes, le provisioning, les connecteurs, les spécifiques et la gouvernance.
L’enjeu est également de retrouver ce qui n’est plus correctement documenté.
Sur nos projets de migration IGA, cette première phase produit une véritable cartographie As-Is : connecteurs, workflows, rôles, intégrations, développements spécifiques, risques, dépendances et backlog de migration.
Aucune intelligence critique ne doit disparaître avec SAP IDM simplement parce qu’elle vivait dans un script oublié.
Étape 2 : ne pas migrer dix ans de dette
Tout ce qui existe dans SAP IDM ne mérite pas nécessairement d’être reconstruit.
Un rôle toujours utilisé et compris ? On le reprend.
Une règle métier légitime ? Elle doit survivre.
Un workflow qui ne correspond plus à l’organisation ? On le simplifie.
Un rôle créé huit ans plus tôt que personne ne sait expliquer ? On commence par demander pourquoi il existe encore.
Une intégration spécifique alors que l’application expose désormais SCIM ou une API propre ? C’est le bon moment pour la revoir.
Chaque élément doit pouvoir être :
repris, simplifié, fusionné, reconstruit ou supprimé.
Une migration IAM réussie ne reproduit pas l’ancien système avec un nouveau logo.
Étape 3 : construire Netwrix Identity Manager à côté de SAP IDM
Nous ne voulons pas couper le moteur historique puis découvrir ce que nous avons oublié.
NIM est donc construit en parallèle.
Les identités sont chargées. Le modèle de données est configuré. Les rôles sont reconstruits. Les règles sont réimplémentées. Les workflows sont mis en place. Les applications sont progressivement raccordées.
Mais le nouvel environnement n’a pas besoin de prendre immédiatement les commandes.
Sur nos migrations IGA, nous pouvons commencer par faire fonctionner la nouvelle plateforme en miroir : calculer les droits, charger les comptes et comparer les résultats sans lui confier immédiatement le provisioning réel. C’est exactement le principe du déploiement parallèle utilisé dans notre méthode de migration actuelle.
L’ancien IAM continue de faire tourner la production.
Le nouveau apprend à le remplacer.
Et les systèmes SAP ?
Évidemment, le sujet est central.
Netwrix Identity Manager dispose notamment de connecteurs standards permettant la lecture et l’écriture avec SAP S/4HANA et SAP ERP 6.0. Il propose également des connecteurs standards pour Active Directory, Microsoft Entra ID, SCIM, LDAP et de nombreuses autres technologies. SAP SuccessFactors figure par ailleurs parmi les applications déjà intégrées dans des projets NIM.
Lorsqu’une application ne dispose pas d’un connecteur dédié, les interfaces génériques permettent d’exploiter notamment SQL, LDAP, SCIM, OData ou PowerShell.
C’est essentiel parce qu’un SAP IDM installé depuis longtemps ne pilote généralement pas uniquement SAP.
Il peut être au centre d’un SI hétérogène.
Et savoir remplacer SAP IDM signifie savoir reprendre ces dépendances.
Provisionner n’est que la moitié du travail
Une API capable d’ajouter un utilisateur dans un groupe ne constitue pas à elle seule un connecteur IGA.
Une tour de contrôle doit également être capable de déterminer ce qui existe réellement dans les systèmes.
NIM calcule qu’Alice doit perdre le droit X.
La révocation est envoyée.
Très bien.
Mais a-t-elle été exécutée ?
Le compte est-il correctement corrélé ?
Un administrateur local a-t-il réattribué le droit ?
Existe-t-il des habilitations historiques qui ne correspondent à aucune règle ?
C’est le rôle de la réconciliation.
NIM prévoit justement des mécanismes de chargement initial et de réconciliation particulièrement utiles lors des migrations. Les identités et objets peuvent être rapprochés selon plusieurs informations — matricule, login, adresse e-mail ou autres combinaisons — et une association manuelle peut être conservée lorsque la corrélation automatique n’est pas suffisamment fiable.
La tour de contrôle doit connaître :
le droit théorique
et
le droit réellement présent.
L’écart entre les deux est précisément ce qu’elle doit gouverner.
Étape 4 : prouver avant de basculer
Lorsque le nouvel environnement est suffisamment mature, un premier lot peut être préparé.
Les identités sont contrôlées.
Les droits calculés sont comparés.
Les violations SoD sont analysées.
Une certification d’accès à blanc peut être réalisée avec les responsables concernés.
Un Go/No-Go est pris.
Et surtout, le scénario de retour arrière existe avant la bascule.
Notre méthode actuelle prévoit une bascule progressive lot par lot, une période de double RUN limitée à la stabilisation, un hypercare renforcé et un plan de fallback documenté.
Puis NIM prend réellement la responsabilité du provisioning sur le périmètre.
Le lot est stabilisé.
Et seulement ensuite, le suivant commence.
Pas de big bang. Pas de pari. Une succession de bascules que l’on sait contrôler.
Étape 5 : éteindre réellement SAP IDM
Quand tous les lots sont migrés, il reste une dernière étape.
Vérifier qu’aucun flux résiduel ne dépend encore de SAP IDM.
Conserver les historiques nécessaires.
Arrêter ses connecteurs.
Désactiver progressivement les accès.
Transférer la documentation.
Former les équipes.
Puis arrêter définitivement la plateforme.
Le décommissionnement d’un IAM n’est pas un arrêt serveur.
C’est le moment où l’organisation peut prouver qu’elle n’en dépend plus.
Et si votre cible était quand même Microsoft Entra ?
C’est possible.
Pour certaines entreprises fortement standardisées Microsoft (ou pour les associations qui ont de fortes réductions sur les abonnements Microsoft), dont les besoins de gouvernance correspondent bien aux capacités d’Entra ID Governance et dont l’écosystème SAP peut être traité avec les composants SAP et Microsoft associés, cette architecture peut être parfaitement pertinente.
Notre point n’est pas de dire que Microsoft fait fausse route.
Notre point est qu’il ne faut pas confondre :
la trajectoire proposée par deux éditeurs
avec
la stratégie IAM de votre entreprise.
Pour les organisations disposant d’un SI hétérogène, d’un modèle de rôles important, de règles métier nombreuses, de contraintes SoD, d’applications non-Microsoft et d’une volonté forte de conserver une tour de contrôle transverse, nous considérons Netwrix Identity Manager comme une cible particulièrement pertinente.
Et nous savons le déployer.
Combien votre SAP IDM vous coûte-t-il aujourd’hui ?
Avant même de parler migration, une autre question mérite d’être posée.
Combien coûte réellement le maintien de votre SAP IDM ?
Pas seulement la licence.
Le RUN.
Les traitements manuels.
Les scripts historiques.
Les corrections.
Les développements de connecteurs.
Les campagnes de contrôle.
Les demandes d’accès.
Les audits.
Les comptes oubliés.
Les droits conservés après une mobilité.
Et la dépendance à des compétences de plus en plus difficiles à mobiliser.
Nous avons développé ROI IAM pour objectiver cette discussion.
Notre outil permet de générer gratuitement une étude détaillée du retour sur investissement potentiel d’un projet IAM à partir de votre propre contexte.
Un environnement SAP IDM historique s’y prête particulièrement bien : les processus existent déjà et une partie importante de leur coût peut donc être mesurée.
Calculez gratuitement le ROI de votre projet IAM avec ROI IAM.
Vous utilisez encore SAP IDM ? Nous pouvons prendre le relais.
Vous n’avez pas besoin d’arriver avec une architecture cible parfaite.
Vous n’avez pas besoin non plus d’avoir documenté chaque script depuis dix ans.
Donnez-nous ce que vous avez :
les accès, les données, les règles, la documentation et les personnes qui connaissent encore le système.
Nous cartographions votre SAP IDM.
Nous récupérons ce qui doit survivre.
Nous supprimons ce qui ne mérite pas d’être migré.
Nous construisons Netwrix Identity Manager en parallèle.
Nous raccordons vos applications.
Nous comparons les droits.
Nous prouvons le résultat.
Puis nous basculons, lot après lot.
SAP vous laisse jusqu’en 2030. Notre objectif est que vous n’ayez pas besoin d’attendre 2030.
Vous préparez la sortie de SAP Identity Management ?
Parlez à Ariovis de votre environnement actuel et de votre projet de migration IAM.
Notre équipe accompagne le cadrage, la migration, l’intégration et l’exploitation de plateformes IAM et IGA.
Disclaimer : article
rédigé en juin 2026 sur un sujet en constante évolution. Il témoigne des idées
qui font actuellement consensus. L’émergence de nouveaux patterns (Aauth, AI
gateway, etc.) et leur impact sur l’architecture – façon 0 trust – proposée ici
peut être à revoir.
Une architecture IAM orientée
agents ne peut plus être dessinée uniquement comme une succession de composants
techniques. Elle doit raconter un parcours : celui d’un utilisateur, d’un
service ou d’un agent qui veut réaliser une action, et celui des contrôles qui
accompagnent cette action jusqu’à la ressource.
Le schéma proposé part de cette
idée simple : une action agentique n’est jamais seulement un appel technique.
C’est une combinaison d’identité, de contexte, de politique, de posture,
d’enforcement et d’audit.
L’objectif n’est donc pas d’opposer les briques entre elles. Au contraire, l’enjeu est de montrer comment elles se complètent : Netwrix Identity Manager pour la gouvernance, Netwrix 1Secure pour la visibilité et la posture, Ping Identity pour l’authentification, HashiCorp pour les secrets, Axiomatics pour la décision d’autorisation, Apigee pour
l’enforcement API, et Ariovis pour assembler cette trajectoire en architecture cohérente.
Alternative Microsoft (la
précédente image étant bâtie à partir des partenaires technologiques de
Ariovis) :
Le point de départ : une
demande utilisateur
Imaginons un utilisateur métier
qui demande à un agent IA de préparer une analyse client.
L’agent doit peut-être consulter
une application interne, appeler une API, interroger une base documentaire,
utiliser un outil MCP, puis restituer une synthèse. Pour l’utilisateur,
l’expérience doit rester fluide. Il ne veut pas voir toute la mécanique de
sécurité. Il veut que l’agent accomplisse la tâche attendue.
Mais côté architecture, plusieurs
questions doivent être traitées sans ambiguïté.
1. La fondation : identité et
gouvernance
La première zone du schéma est la Identity & Governance Foundation.
Elle regroupe les identités
humaines, les services, les workloads et les agents. Le choix de parler de Non-Human
Identity Governance est important : on ne parle pas seulement d’un “agent”
isolé, mais de l’ensemble des identités non humaines qui participent à
l’exécution.
Dans cette zone, Netwrix
Identity Manager porte la fondation IAG :
gouvernance des identités ;
cycle de vie ;
ownership ;
accès approuvés ;
séparation des tâches ;
revues ;
gouvernance des identités non humaines.
L’idée est de savoir, avant même
l’exécution, si l’agent ou le service est légitime dans l’organisation. Qui en
est responsable ? Quel est son périmètre ? Quels accès ont été accordés ? Quels
accès doivent être revus ?
À côté, Ping Identity
porte l’authentification non humaine. Il répond à la question de la preuve
d’identité au runtime.
HashiCorp intervient sur
les secrets et credentials. L’agent ou le service ne doit pas manipuler des
secrets de manière opaque ou non maîtrisée.
Cette première zone ne prend pas
toute la décision runtime, mais elle donne une base indispensable : sans
identité gouvernée, sans authentification fiable et sans secrets maîtrisés,
l’autorisation contextuelle repose sur du sable.
2. La décision : politique et
autorisation runtime
La deuxième zone est le cœur du
schéma : Policy & Runtime Decision.
C’est ici que Axiomatics
est positionné comme moteur de décision. Deux briques sont importantes autour
du PDP :
Advanced Policy Management,
pour modéliser les règles d’autorisation fines. Policy Governance, pour gérer, maintenir et faire évoluer ces règles
dans le temps.
Au centre, le bloc Runtime
Authorizations représente le PDP, le Policy Decision Point.
Quand l’agent veut agir, un point
d’enforcement appelle Axiomatics avec un contexte. Ce contexte ne se limite pas
à un rôle ou à un scope Aauth. Il combine plusieurs dimensions :
C’est là que le schéma devient
intéressant. La décision n’est pas seulement : “cet agent a-t-il un droit ?”
Elle devient : “cette action
précise est-elle acceptable dans ce contexte précis ?”
Par exemple :
l’agent peut lire une donnée, mais pas l’exporter ;
il peut appeler un outil MCP, mais pas avec
certains paramètres ;
il peut accéder à une API, mais uniquement dans un
environnement approuvé ;
il peut obtenir une réponse, mais avec masquage de
certains champs ;
il peut poursuivre, mais avec un niveau d’audit
renforcé.
Cette zone centrale explique
pourquoi l’IAG reste essentielle sans être le seul mécanisme. L’IAG donne la
légitimité structurée. Le PDP traite la décision contextuelle au moment de
l’usage.
3. La visibilité : posture,
découverte et audit
Le schéma place une couche Audit,
Visibility & Posture en haut, parce que ces capacités ne sont pas
uniquement des fonctions de reporting. Elles alimentent le reste de
l’architecture.
Netwrix 1Secure est
positionné sur :
la découverte ;
les insights ;
la posture ;
le risque ;
l’observabilité autour des agents et expositions.
Netwrix Identity Manager
est positionné sur :
Access & Authorization Audit & Insights ;
Administration Audit ;
Dashboards & Alerts ;
Governance Audit Trails.
C’est une distinction importante.
La visibilité n’est pas monolithique. Une partie relève de la posture et de
l’exposition. Une autre relève de la gouvernance, de l’administration et des
traces d’autorisation.
Dans le parcours utilisateur,
cette couche sert à répondre après coup, mais aussi à enrichir les décisions
suivantes :
Pourquoi l’agent a-t-il été autorisé ?
Quelle politique a été appliquée ?
Quel contexte de risque existait ?
Quel propriétaire est responsable ?
Faut-il revoir l’accès ?
Faut-il déclencher une action corrective ?
4. L’enforcement : là où
l’architecture reste volontairement ouverte
La troisième zone du schéma est Enforcement
& Consumption.
Elle contient les contrôles
proches de l’usage :
Input Guardrails ;
Data Access Controls ;
MCP & API Controls ;
Tool / Parameter Controls ;
Output Guardrails.
Elle montre aussi Apigee
comme API Gateway / Enforcement Point.
Mais le message n’est pas : “tout
passera toujours par une API Gateway”. Le message est plus nuancé : à date,
l’API gateway reste un point d’enforcement naturel pour beaucoup de flux. Mais
selon les architectures, d’autres points deviennent tout aussi importants : AI
gateway, MCP gateway, agent framework, MCP server, SDK d’enforcement, data
access layer.
C’est pour cela que le schéma
ajoute une bande en bas : Distributed PEP Fabric.
Ces PEPs ne remplacent pas le
PDP. Ils l’appellent. Ils collectent le contexte, demandent une décision, puis
appliquent le résultat.
Dans une architecture plus
mature, certains flux passeront probablement davantage par des AI gateways ou
des MCP gateways que par des API gateways classiques. Le schéma garde donc
Apigee comme brique concrète, mais il ne ferme pas l’architecture autour d’Apigee
uniquement.
C’est un point clé : le schéma
est une recommandation d’architecture à date, pas une prophétie figée.
Le parcours complet, vu
simplement
Reprenons notre utilisateur qui
demande à un agent de produire une analyse.
L’utilisateur est connu. L’agent
est gouverné. Le service qui l’exécute est identifié. Les secrets sont
récupérés proprement. L’agent prépare son action et passe par un point
d’enforcement : par exemple Apigee, une AI/MCP gateway ou un SDK.
Ce PEP rassemble le contexte :
Qui demande ?
Quel agent agit ?
Pour quelle ressource ?
Quelle action ?
Quelle sensibilité ?
Quel environnement ?
Quel risque ?
Il appelle Axiomatics.
Axiomatics applique les
politiques. Il peut s’appuyer sur les attributs d’identité, les règles de
gouvernance, le contexte de posture, la sensibilité de la donnée ou les
paramètres de l’action.
La décision revient au PEP.
Le PEP applique : autoriser,
refuser, limiter, masquer, journaliser, ou déclencher un workflow.
L’action atteint alors une
ressource protégée : MCP server, API, application, service ou data source.
En parallèle, les événements
remontent vers les couches d’observabilité et d’audit. Ils alimentent les
tableaux de bord, les traces de gouvernance, les revues et les éventuelles
actions correctives.
Ce qu’il faut retenir
Le schéma présenté en haut de l’article n’a pas vocation à figer une architecture une fois pour toutes. Il propose une lecture pragmatique d’une
architecture agentique recommandée aujourd’hui : une fondation IAG solide, une
décision runtime centralisée et gouvernée, et des points d’enforcement
distribués.
La valeur vient de l’assemblage.
Netwrix Identity Manager structure la légitimité.
Netwrix 1Secure apporte la visibilité et les signaux de posture.
Ping Identity authentifie.
HashiCorp protège les secrets.
Axiomatics décide.
Apigee applique sur les flux API.
Les autres PEPs étendent l’enforcement vers les agents, MCPs, SDKs et couches
de données.
C’est cette articulation qui
permet de garder une expérience utilisateur fluide tout en contrôlant
précisément ce que les agents peuvent réellement faire.
Pendant longtemps, les programmes IAM ont été pensés comme des assemblages d’outils.
Un annuaire d’un côté. Un SSO de l’autre. Un PAM à part. Et, au milieu, une gouvernance des identités souvent perçue comme un sujet de conformité, utile pour les campagnes de revue d’accès, mais loin des décisions d’accès réelles.
Cette lecture ne tient plus.
Aujourd’hui, les entreprises doivent gérer des collaborateurs, des prestataires, des comptes techniques, des API, des machines, des partenaires, demain des agents IA. Dans ce contexte, l’identité ne peut plus être un stock d’informations recopiées d’un système à l’autre. Elle doit devenir une capacité d’orchestration.
C’est là que l’IAG change de statut.
Non plus simple outil de gouvernance documentaire.
Non plus simple moteur de workflow joiner-mover-leaver.
Mais véritable tour de contrôle de l’identité.
Le vrai problème : trop de décisions d’accès sont encore dispersées
Dans beaucoup d’organisations, les droits sont encore décidés ou reconstruits à plusieurs endroits :
dans les applications ;
dans des groupes techniques ;
dans des règles locales peu documentées ;
dans des scripts ;
parfois même dans des fichiers Excel.
Résultat : les rôles dérivent, les exceptions s’accumulent, les revues d’accès deviennent pénibles, et personne ne sait vraiment où se prend la décision.
Le coût de cette situation n’est pas seulement technique. Il est aussi opérationnel et métier :
les onboardings ralentissent ;
les retraits d’accès prennent trop de temps ;
les projets redéveloppent leur propre logique d’habilitation ;
le privilège reste souvent trop permanent ;
les audits révèlent surtout une absence de lisibilité.
Le sujet n’est donc plus seulement “qui a accès à quoi ?”.
Le vrai sujet est : où s’organise l’intelligence de l’accès ?
L’IAG comme point de contrôle, pas seulement comme point de passage
Chez Ariovis, nous défendons une idée simple : l’IAG doit redevenir central, mais pas centralisateur.
La nuance est essentielle.
Il ne s’agit pas de faire de l’IAG un monolithe qui stocke tout, réplique tout et décide de tout.
Il s’agit d’en faire le point où l’on structure, qualifie et gouverne l’information d’identité utile aux décisions.
Autrement dit, l’IAG devient la couche qui :
consolide les bonnes données ;
qualifie les rôles, attributs et relations utiles ;
met en cohérence les règles de gouvernance ;
éclaire les décisions d’accès ;
prépare l’automatisation ;
et alimente, au bon moment, les bons mécanismes d’application.
C’est une logique de tour de contrôle : elle n’ouvre pas toutes les portes elle-même, mais elle permet que les bonnes décisions soient prises, au bon endroit, avec le bon niveau de contexte.
Sortir d’une logique de réplication
L’un des héritages les plus coûteux de l’IAM historique, c’est la copie.
On copie l’identité dans les applications.
On copie les rôles dans des annuaires secondaires.
On copie les attributs dans des bases locales.
Puis on essaie de réconcilier l’ensemble.
Cette approche donne une illusion de maîtrise, mais elle produit surtout de la dette.
À l’inverse, une approche moderne consiste à considérer l’identité comme une information orchestrée, consommée dynamiquement selon les usages. L’enjeu n’est plus d’avoir partout la même copie, mais d’avoir partout la bonne décision, fondée sur une information fiable, gouvernée et exploitable.
C’est précisément ce basculement qui permet de passer d’un IAM centré sur la réplication à un IAM centré sur l’orchestration.
Le trio à clarifier : information, décision, application
Une architecture d’identité mature distingue clairement trois rôles.
D’abord, il faut un endroit où l’on prépare l’information utile : rôles, attributs, statut, contexte, relations, signaux, périmètres.
Ensuite, il faut un endroit où l’on prend la décision d’accès.
Enfin, il faut un endroit où cette décision est appliquée.
Tant que ces trois responsabilités restent mélangées, l’organisation subit :
des règles incohérentes ;
des circuits opaques ;
des exceptions difficiles à gouverner ;
une explosion du RBAC ;
et des intégrations fragiles.
Quand elles sont clarifiées, l’IAG peut pleinement jouer son rôle : devenir le point d’information gouverné qui nourrit des décisions plus fines, plus auditables et plus évolutives.
Pourquoi cela change aussi le PAM et l’Access Management
Penser l’IAG comme tour de contrôle change immédiatement la lecture de deux autres domaines : l’Access Management et le PAM.
Côté Access Management
L’authentification ne suffit plus.
Le SSO, le MFA ou l’accès conditionnel ne créent de valeur que s’ils s’appuient sur un contexte d’identité propre, gouverné et exploitable.
Une politique d’accès n’est intelligente que si elle sait lire :
le bon statut utilisateur ;
le bon rôle ;
le bon niveau de risque ;
la bonne relation à la ressource ;
le bon contexte d’exécution.
Sans cette colonne vertébrale, l’Access Management reste performant sur le front door, mais limité sur la finesse réelle des décisions.
Côté PAM
Le privilège ne peut plus être géré uniquement comme un coffre et une session.
Bien sûr, les fondamentaux restent nécessaires : contrôle, traçabilité, rotation, supervision.
Mais ils ne suffisent plus dans un monde où l’on cherche à réduire le privilège permanent, à introduire du JIT, à mieux gouverner les comptes techniques, et à articuler les accès sensibles avec le reste du modèle d’identité.
Là encore, l’IAG a un rôle clé : qualifier les populations, structurer les droits, identifier les zones grises, soutenir les scénarios de privilège dynamique, et rendre le PAM plus lisible dans une architecture globale.
Le bénéfice concret : moins de dette, plus de cohérence
Quand l’IAG joue vraiment son rôle de tour de contrôle, les bénéfices sont très concrets.
Les projets redéveloppent moins de logique locale.
Les raccordements sont plus simples.
Les revues d’accès deviennent plus pertinentes.
Les scénarios JML sont plus robustes.
Les cas de privilège sont mieux gouvernés.
Les trajectoires Zero Trust deviennent enfin praticables.
Surtout, l’entreprise gagne ce qui manque le plus souvent dans les programmes IAM : de la lisibilité.
Et en IAM, la lisibilité n’est pas un luxe.
C’est une condition de la sécurité durable.
Ce que nous observons sur le terrain
Dans les programmes que nous accompagnons, le vrai déclic n’arrive pas quand une organisation ajoute un outil de plus.
Il arrive quand elle commence à poser les bonnes questions :
quelle information d’identité doit être gouvernée ici ?
quelle décision doit être prise là ?
quel composant applique réellement l’accès ?
où se trouvent les duplications inutiles ?
quels privilèges peuvent devenir temporaires ?
quels usages justifient une autorisation plus fine ?
À partir de là, le programme IAM cesse d’être un catalogue de briques.
Il devient une trajectoire d’architecture.
Et c’est exactement à cet endroit qu’Ariovis apporte le plus de valeur : transformer un paysage d’identité fragmenté en lecture claire, progressive et exploitable.
Cliquez sur l’image pour l’agrandir
En conclusion
L’IAG ne doit plus être regardée comme un sujet annexe de conformité.
Elle peut devenir la tour de contrôle qui redonne de la cohérence à l’ensemble : identité, accès, autorisation et privilèges.
Pas pour tout centraliser.
Pas pour complexifier.
Mais pour remettre de l’ordre dans la façon dont l’entreprise décide, applique et gouverne les accès.
Dans un monde où l’identité devient le point de passage de presque tout, cette évolution n’est plus un raffinement d’architecte.
Ariovis finalise une levée de fonds d’amorçage et un management package pour accélérer sa croissance dans la cybersécurité
Ariovis, société française innovante en cybersécurité fondée par Matthieu Filizzola, annonce la finalisation d’une levée de fonds d’amorçage et la mise en place d’un management package dédié à ses collaborateurs clés. Ces opérations, qui s’inscrivent dans une réorganisation stratégique de son capital, visent à renforcer sa capacité à innover et à accompagner ses clients dans la durée.
Une approche disruptive de la cybersécurité
Depuis sa création en 2024, Ariovis réinvente la sécurité informatique en la positionnant comme un levier de performance plutôt qu’une contrainte. Sa signature « Security meets Business » résume cette vision : intégrer la cybersécurité au cœur des stratégies métiers de ses clients pour en faire un facteur de croissance. Présente en Île-de-France, en Nouvelle-Aquitaine et dans plusieurs pays européens, la société couvre l’ensemble des enjeux cyber :
Gestion des identités et des accès (IAM/PAM)
Gouvernance et conformité (GRC)
Formation et sensibilisation à la cybersécurité
Une levée de fonds pour accélérer l’innovation
Cette levée de fonds d’amorçage permettra à Ariovis de renforcer ses équipes, de développer de nouveaux services et de consolider sa position de leader dans un secteur en pleine expansion. Elle vient récompenser l’expertise unique de la société, déjà saluée par deux distinctions majeures en 2026 :
Grand Prix des Cas d’Or 2026 (catégorie Cyber Gouvernance & Risk Management, secteur public)
Prix de la Gestion des Risques Cybersécurité du Service Public
Un management package pour ancrer la culture entrepreneuriale
Parallèlement, la mise en place d’un management package reflète l’engagement d’Ariovis à associer ses talents à la création de valeur et à fidéliser ses collaborateurs clés. Cette initiative s’inscrit dans sa volonté de bâtir une culture entrepreneuriale durable, au service de ses clients et de ses équipes.
Ariovis a été conseillée par Wan Avocats dans le cadre de cette opération (Isabelle Wekstein, associée, Ellogne Tigori, Counsel, et Pierre Diaz del Castillo, collaborateur)
Chez Ariovis, une conviction s’est installée progressivement
: le concept d’Identity Fabric doit désormais être maîtrisé non
seulement par les équipes techniques IAM, mais aussi par les experts GRC, les
auditeurs, les RSSI, les architectes et toutes les parties prenantes impliquées
dans la gouvernance de l’identité.
Non pas comme un slogan marketing.
Mais comme un cadre stratégique permettant enfin de relier, structurer
et piloter l’ensemble des disciplines de l’IAM.
Aujourd’hui, intégrer ce concept dans les audits et les
schémas directeurs est devenu indispensable pour dépasser une vision uniquement
centrée IAG et embrasser toute la richesse et la complexité de l’IAM
moderne.
Le déclic : EIC 2025, un moment fondateur
Le concept dépasse largement le marketing, et Ariovis en a
pris pleinement conscience lors de l’EIC 2025, le salon international de
référence organisé par KuppingerCole.
Invitée par Axiomatics à participer à plusieurs sessions, l’équipe Ariovis a
été marquée par une phrase prononcée lors d’une keynote (traduction libre) :
« Une Identity Fabric n’est pas un produit : c’est une
manière de penser l’IAM comme un tissu cohérent qui relie tous les services
d’identité au service du métier. »
Le mot tissu est resté.
Parce qu’il décrit parfaitement ce que vivent les organisations : un domaine
IAM éclaté, fragmenté, dispersé, difficile à gouverner et presque impossible à
piloter en stratégie globale.
Le problème fondamental : un IAM éclaté entre silos et
sponsors
Pour comprendre l’intérêt de l’Identity Fabric, il suffit
d’observer la réalité :
Le
PAM est piloté par l’infrastructure et la sécurité technique.
L’IAG
par les RH, le juridique ou la conformité.
L’AM
et le SSO par des équipes digitales ou applicatives.
Le
CIAM par le marketing.
Le
Password Management par l’IT opérationnel.
La
PKI par des équipes historiques parfois isolées.
L’autorisation
avancée (ABAC/PBAC/ReBAC) par… personne, très souvent.
Le
ZTNA par les équipes réseau.
Comment, dans ces conditions, bâtir une vraie stratégie
IAM globale ?
L’IAM n’est pas un empilement de technologies.
C’est un ensemble d’identités, de droits, de politiques et de signaux qui
doivent fonctionner ensemble.
Le découpage actuel des responsabilités rend la cohérence quasi impossible.
L’Identity Fabric propose enfin un cadre pour réunifier ces
domaines.
Le cœur de la vision : orchestration et unification
Ariovis défend une approche exigeante de l’Identity Fabric,
articulée autour de deux piliers majeurs.
1. L’orchestration : le chaînon manquant
Dans la majorité des organisations, l’IAM souffre moins d’un
manque de produits que d’un manque de liaison entre ces produits.
L’orchestration permet :
de
relier les différents silos d’identité,
de
normaliser les flux et événements,
de
gouverner les droits de manière transverse,
de
gérer les identités humaines, machines et services selon une logique
homogène,
de
créer un plan de contrôle unique.
Cette idée d’orchestrateur indépendant, fondé sur des
politiques explicites, résonne particulièrement avec les travaux modernes sur
l’autorisation, domaine dans lequel Ariovis est très engagée.
2. L’unification : rassembler tous les domaines de l’IAM
L’ambition n’est pas de fusionner les outils, mais d’avoir
une vision unifiée des domaines IAM.
Pour Ariovis, le périmètre de l’Identity Fabric couvre :
IAG
(gouvernance, cycles de vie, conformité)
AM / SSO (authentification, fédération,
MFA, risk-based)
Imaginez un bâtiment où tout le monde posséderait la même clé : du stagiaire au directeur, chacun pourrait ouvrir les mêmes portes. Gestion simple… mais surface de risque immense.
À l’inverse, imaginez un bâtiment où chaque porte, chaque tiroir, chaque armoire nécessiterait une clé spécifique : sécurité maximale, mais complexité ingérable.
Entre ces deux extrêmes se situe la réalité du contrôle d’accès moderne. Les organisations doivent ajuster finement la granularité de leurs autorisations, ni trop large, ni trop pointilliste afin de garantir sécurité, flexibilité et conformité.
Cet article présente les trois grands niveaux de granularité : coarse-grained, medium-grained et fine-grained authorization, et explique comment ils s’articulent dans les systèmes d’accès contemporains.
Comprendre ces niveaux est essentiel pour concevoir des architectures de sécurité robustes, adaptées à la conformité, à la résilience et aux exigences modernes de gouvernance des accès.
Les fondements du contrôle d’accès
Avant d’entrer dans la granularité, rappelons les deux piliers du contrôle d’accès :
Authentification : prouver qui est l’utilisateur.
Autorisation : déterminer ce qu’il peut voir, faire ou modifier.
Ces mécanismes reposent sur différents modèles :
DAC (Discretionary Access Control) : droits attribués à la discrétion du propriétaire d’une ressource. Simple, mais risqué.
MAC (Mandatory Access Control) : décisions centralisées basées sur des niveaux de classification. Très sûr, très rigide.
RBAC (Role-Based Access Control) : droits attribués par rôle, scalable et intuitif.
Les évolutions modernes incluent ABAC, PBAC et ReBAC, intégrant des décisions dynamiques basées sur des attributs, des politiques ou des relations.
La granularité se superpose à tous ces modèles pour définir le niveau de détail des autorisations.
L’autorisation à granularité grossière (Coarse-Grained Authorization)
Le coarse-grained repose sur un critère unique ou très large : rôle, service, groupe, réseau, etc.
Tous les utilisateurs partageant ce critère reçoivent le même niveau d’accès, sans variation contextuelle.
On met les utilisateurs dans de grands “paniers” : Employés, Managers, RH, IT… et chaque panier reçoit ou perd un bloc d’autorisations.
Exemples
« Utilisateur dans le département Ventes → accès CRM autorisé. »
« Adresse IP interne → accès au portail interne. »
Avantages
Très simple et rapide à administrer.
Performant et peu coûteux.
Lisible pour l’audit de haut niveau.
Limites
Manque de finesse : contrevient au principe du moindre privilège.
Rigidité : peu adapté aux cas particuliers.
Explosion du nombre de règles avec la croissance de l’organisation.
Risque élevé en cas de compromission d’un rôle large.
L’autorisation à granularité moyenne (Medium-Grained)
Le medium-grained se situe entre les accès globaux et les contrôles hyper précis.
Il s’applique généralement au niveau des API, services ou modules.
Il répond à des questions comme :
« Cet utilisateur peut-il exécuter GET/POST/DELETE sur ce point d’entrée précis ? »
Les décisions reposent sur :
rôle,
méthode HTTP,
scopes / claims du jeton,
métadonnées d’API.
Modèles associés
RBAC enrichi (rôles + actions par endpoint)
ABAC simplifié (quelques attributs simples)
Avantages
Parfait pour les architectures microservices.
Contrôle précis des opérations (GET vs DELETE).
Lisible, auditable, scalable depuis un RBAC existant.
Limites
Ne protège pas encore les données internes (ligne, champ…).
Multiplication rapide des règles si non centralisées.
Peu ou pas de contexte dynamique.
L’autorisation à granularité fine (Fine-Grained Authorization)
La FGA permet des décisions d’accès contextuelles, dynamiques, conditionnelles, souvent au niveau :
Aligné avec les stratégies Zero Trust et les exigences réglementaires
Limites
Très complexe à modéliser
Dépend fortement de la qualité des attributs
Impact potentiel sur la performance
Vers une approche multi-niveau
Les organisations modernes combinent les trois :
Coarse-grained pour déterminer l’accès global à l’application (SSO / IAM).
Medium-grained pour contrôler les actions dans l’application.
Fine-grained pour sécuriser les données sensibles selon le contexte.
Cette approche en couches permet un contrôle d’accès :
global, opérationnel, contextuel.
La granularité n’est pas un détail technique : c’est un indicateur de maturité en gouvernance des accès.
Le coarse-grained fixe le périmètre général.
Le medium-grained régule les actions.
Le fine-grained apporte la précision contextuelle indispensable.
Avec la montée des architectures distribuées et des exigences de conformité, combiner intelligemment ces trois niveaux devient un impératif stratégique. Les approches policy-as-code permettent désormais d’automatiser ces règles, de les centraliser et de renforcer la lisibilité globale du contrôle d’accès.
Chez Ariovis, on parle souvent de sécurité, de conformité, d’IAM ou de PAM. Mais au quotidien, il s’agit surtout d’un travail collectif où la rigueur, la curiosité et la confiance font la différence. Derrière chaque mission IAM, PAM ou Zero Trust, il y a des ingénieurs, des consultants et des profils hybrides, tous animés par la même exigence : faire les choses sérieusement, avec méthode et engagement.
Un recrutement exigeant, à l’image de nos projets
Rejoindre Ariovis, c’est intégrer une équipe qui aime les défis et valorise l’excellence technique. Notre approche du recrutement est simple : clarté, exigence et transparence. Chaque rencontre est l’occasion d’un échange sincère : comprendre les motivations, identifier les forces et s’assurer que la collaboration s’inscrira dans la durée. Les candidats échangent avec plusieurs membres de l’équipe, découvrent nos projets et nos méthodes avant même de signer.
Louis Munzner, consultant Ariovis
« Pour moi, le recrutement chez Ariovis se démarque surtout par sa transparence, et c’est clairement ce qui fait sa force. L’objectif est simple : exprimer clairement les besoins de l’entreprise, tout en cherchant à comprendre ceux du candidat. C’est un recrutement qui ne cherche pas à « tester » mais à comprendre, et c’est ce qui rend l’expérience à la fois humaine et constructive. »
Cette exigence dès le départ pose les bases : rigueur, bienveillance et envie de progresser ensemble.
Des experts reconnus, passionnés et engagés
Les équipes Ariovis rassemblent des profils confirmés IAM, PAM, sécurité applicative, gouvernance d’accès et certifiés sur les solutions phares du marché (Usercube, Netwrix, Ping Identity, CyberArk…).
Au-delà des outils, c’est la capacité à comprendre les enjeux, à structurer et à transmettre qui fait la différence.
Enaëlle Desclous, consultante Ariovis
« Ce qui m’a marqué dès le début du recrutement, c’est le fait que l’humain soit autant valorisé que les compétences techniques. L’entraide au sein de l’équipe, en plus des formations externes, m’a permis de prendre rapidement de nouvelles responsabilités. »
Ici, la progression n’est pas un mot creux : pair programming, retours d’expérience, échanges entre pairs et accompagnement par des référents font partie du quotidien. Pas de hiérarchie rigide, mais une exigence partagée. Une équipe soudée, exigeante et bienveillante
Quentin Joly, consultant Ariovis
« Dès le début, on a un visage lors des entretiens, on se met à notre place. Bien plus que le côté technique, c’est l’humain qui est retenu : sa motivation, ses envies. On ne m’a pas menti : s’il y a autant d’efforts sur le recrutement, c’est parce qu’ici, c’est une équipe soudée qui est recherchée pour travailler sur le long terme. »
Au fil des projets, cette cohésion s’exprime naturellement : on échange, on se challenge, on se forme mutuellement. Les succès individuels nourrissent la réussite collective, et chaque mission devient une opportunité d’apprentissage et d’évolution.
L’expertise Ariovis, une exigence partagée
Chez Ariovis, la maîtrise technique s’accompagne d’une culture forte de la qualité et du partage. Nos équipes interviennent sur des environnements complexes, souvent critiques, où précision, documentation et accompagnement client sont essentiels. Cette approche rigoureuse et collaborative garantit la fiabilité de nos interventions et la confiance durable de nos partenaires.
En résumé
Travailler chez Ariovis, c’est rejoindre un collectif d’experts exigeants, passionnés et accessibles. Des professionnels engagés dans leur travail, attachés à la qualité autant qu’à l’esprit d’équipe. On y apprend vite, on y progresse ensemble, et on y reste parce qu’on s’y sent utile.
Chez Ariovis, la compétence ne se revendique pas : elle se démontre, chaque jour, sur le terrain.
![[Schéma du Tier Model : le Tier 0 contrôle le Tier 1, qui contrôle le Tier 2, sans remontée de confiance possible]](https://wordpress.ariovis.fr/wp-content/uploads/2026/09/Image-Architecture-des-acces-privilegies-1024x576.png)
