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.
Arriver le premier jour et pouvoir travailler tout de suite : ça paraît normal. En réalité, ça ne l’est pas du tout.
Quand ce n’est pas bien organisé, les conséquences sont immédiates :
Du temps perdu, parfois des heures ou des jours
Un onboarding raté dès le départ
Des accès oubliés qui créent des risques de sécurité
De la frustration pour l’employé, qui ne peut pas effectuer son travail
Pour éviter ça, certaines entreprises automatisent l’ensemble du processus d’identité, de l’arrivée jusqu’au départ, grâce à des outils comme Netwrix Identity Manager. Pour comprendre concrètement à quoi ça sert, suivons trois personnes : Léa, Camille et Sophie.
Le premier matin de Léa
Léa arrive dans l’entreprise le lundi.
Le vendredi précédent, les RH ont simplement enregistré son arrivée dans leur outil. Elles n’ont pas envoyé de mail à l’IT, ni créé de ticket. À partir de cette information, le système a tout préparé automatiquement : son compte, sa messagerie, ses accès aux outils internes. Il s’est basé sur des éléments simples : son poste, son équipe, son lieu de travail.
Résultat : le lundi matin, tout est prêt. Léa ouvre sa session et peut travailler immédiatement.
Pour l’entreprise, ça change beaucoup de choses :
L’IT n’a rien eu à faire manuellement
Il n’y a pas d’erreur ou d’oubli
Léa est opérationnelle dès la première heure
L’image de l’entreprise est positive dès le premier jour
Derrière, plusieurs systèmes ont été configurés. Mais pour elle, tout est fluide et invisible.
Camille a besoin d’un accès en plus
Quelques semaines plus tard, Camille a besoin d’accéder à un nouvel outil pour un projet. Elle fait une demande dans un portail. Avant même qu’elle l’envoie, le système vérifie automatiquement que cet accès ne pose pas de problème avec ceux qu’elle a déjà. La demande est ensuite envoyée aux bonnes personnes pour validation, avec toutes les informations nécessaires. Une fois validée, l’accès est donné automatiquement. Camille reçoit une notification.
Là encore, les bénéfices sont concrets :
Aucun aller-retour inutile avec l’IT
Une demande traitée plus rapidement
Une décision claire et tracée
Moins de risque d’accorder un accès inadapté
Personne n’a eu besoin de faire l’action à la main.
Sophie change de poste : le risque invisible
Sophie change d’équipe. Elle passe du marketing à la finance. Dans beaucoup d’entreprises, on ajoute simplement de nouveaux accès… mais on oublie de retirer les anciens. Petit à petit, certaines personnes accumulent des accès qu’elles ne devraient plus avoir. Cela peut devenir un vrai risque, surtout si ces accès donnent accès à des données sensibles. Ici, le système fait autrement.
Quand Sophie change de poste, ses accès sont recalculés entièrement :
Ceux dont elle n’a plus besoin sont supprimés
Ceux qui restent utiles sont conservés
En cas de doute, son manager est consulté
Résultat :
Moins d’erreurs humaines
Moins d’accès inutiles qui traînent dans le temps
Une meilleure protection des données
Une situation claire et maîtrisée
Elle n’a que ce dont elle a besoin, rien de plus.
Le départ de Sophie : le moment le plus risqué
Quelques années plus tard, Sophie quitte l’entreprise. Elle rend son badge et part. Mais ce qu’elle ne voit pas, c’est que tout a été préparé à l’avance. Sa date de départ, enregistrée en amont, a permis d’organiser automatiquement la fermeture de ses accès. C’est un moment très sensible : si quelque chose est oublié, un ancien employé peut encore accéder à des outils ou des données. Sans automatisation, cela peut prendre plusieurs jours et il est facile d’oublier quelque chose.
Ici, tout est fait automatiquement :
Ses accès sont coupés au bon moment
Tous les systèmes sont concernés, pas seulement les principaux
Une vérification est faite plus tard pour s’assurer que tout est bien fermé
Tout est enregistré pour garder une trace
Les gains sont immédiats :
Un énorme gain de temps pour l’IT
Presque aucun risque d’oubli
Une sécurité renforcée
Une gestion propre et complète du départ
En quelques minutes, tout est sécurisé.
Ce qu’on ne voit pas, c’est ce qui marche
Léa qui travaille dès son arrivée. Camille qui obtient un accès sans attendre. Sophie qui ne garde aucun accès inutile. Aucun de ces moments ne se remarque. Et c’est justement le signe que tout fonctionne bien.
Ce constat dépasse le seul quotidien des équipes IT : une cartographie IAM bien conçue suit la même logique à l’échelle de l’entreprise. Invisible pour les utilisateurs, mais directement visible sur la performance business.
Quand tout est bien organisé :
Les employés peuvent travailler sans blocage
L’IT passe moins de temps sur des tâches répétitives
Les erreurs humaines sont fortement réduites
Les accès sont toujours cohérents avec la réalité
Ce type d’outil ne fait pas “moins de travail”. Il effectue le travail au bon moment, de manière fiable, sans oubli. C’est cette mécanique invisible qui fait toute la différence au quotidien.
Ariovis et Netwrix Identity Manager
Mettre en place ce fonctionnement ne se résume pas à installer un outil. Il faut comprendre comment l’entreprise fonctionne, qui a besoin de quoi, et à quel moment. C’est ce travail de fond qui permet ensuite d’obtenir des situations comme celles de Léa, Camille et Sophie, sans effort au quotidien. Chez Ariovis, nous accompagnons les entreprises pour mettre en place ce type d’organisation, de façon simple, fiable et adaptée à leur réalité.
10 septembre 2026 – Paris, France et Menlo Park, Californie – AccuKnox, plateforme de protection des applications cloud-native (CNAPP) basée sur une approche Zero Trust, annonce la signature d’un partenariat avec Ariovis, pure player de l’Identity & Access Management (IAM).
À travers ce partenariat, Ariovis enrichit son accompagnement autour de la sécurité des identités en intégrant à son écosystème la plateforme CNAPP et AI Security d’AccuKnox. L’objectif : permettre aux entreprises de mieux protéger les environnements cloud, les applications et les workloads IA auxquels leurs identités humaines et non humaines accèdent.
Ariovis rejoint ainsi l’écosystème européen de partenaires spécialisés d’AccuKnox afin d’accompagner les organisations face à l’évolution des surfaces d’attaque, à la généralisation du cloud et de l’IA et au renforcement des exigences de sécurité et de conformité.
Pourquoi Ariovis a choisi AccuKnox
Ariovis accompagne les organisations dans la définition, la mise en œuvre et l’évolution de leurs stratégies de gestion des identités et des accès.
Son expertise couvre l’ensemble de la chaîne IAM : stratégie IAM et Zero Trust, gouvernance des identités, gestion des accès, PAM, autorisation fine, sécurité Active Directory et Entra ID, CIAM ou encore sécurité des identités non humaines et des agents IA.
Avec AccuKnox, Ariovis souhaite aller plus loin en reliant la maîtrise des identités et des droits d’accès à la protection effective des environnements cloud et IA au moment de l’exécution.
Car savoir qui peut accéder à une ressource constitue une première étape. Il faut également être capable de comprendre ce qui se passe une fois l’accès accordé, d’identifier les comportements à risque et de bloquer les actions qui ne devraient pas avoir lieu.
Après avoir étudié le marché des solutions CNAPP, Ariovis a retenu AccuKnox pour son approche unifiée et sa capacité à couvrir plusieurs dimensions de la sécurité cloud et IA au sein d’une même plateforme.
Cette complémentarité permet de prolonger concrètement une approche Zero Trust, depuis l’identité jusqu’aux ressources, applications et workloads auxquels elle accède.
Le rôle d’Ariovis dans ce partenariat
Dans le cadre de ce partenariat, Ariovis pourra commercialiser, intégrer, déployer et accompagner ses clients dans l’adoption de la plateforme AccuKnox.
La solution viendra compléter les expertises et offres existantes d’Ariovis et pourra être intégrée dans sa démarche d’intervention, du cadrage stratégique jusqu’au déploiement, à l’adoption et à l’évolution des dispositifs mis en place.
Ariovis intervient aussi bien dans le cadre de besoins ponctuels que dans des engagements de plus long terme, avec une priorité donnée aux prestations au forfait et à l’engagement de résultats.
Aujourd’hui, plus de 80 % du chiffre d’affaires d’Ariovis est réalisé dans le cadre de missions avec engagement de résultats, traduisant une approche orientée vers la mise en œuvre concrète et la valeur apportée aux organisations.
Pour AccuKnox, ce partenariat s’inscrit dans une stratégie de développement fondée sur des partenaires locaux disposant d’une expertise forte et capables d’accompagner les entreprises au-delà de la seule mise à disposition d’une technologie.
Paroles de dirigeants
« Notre mission chez Ariovis est de faire de la sécurité un levier pour l’entreprise, et non un frein. L’identité permet de savoir qui peut agir. AccuKnox permet de comprendre ce qui se passe réellement à l’exécution et de bloquer ce qui ne devrait pas avoir lieu.
En réunissant ces deux dimensions, nous pouvons proposer à nos clients une approche Zero Trust qui ne reste pas uniquement théorique, mais qui s’applique concrètement en production. Nous sommes fiers de pouvoir accompagner le développement d’AccuKnox sur le marché européen. »
Matthieu Filizzola, Expert IAM & PAM, Ariovis
« Nous sommes ravis d’accueillir Ariovis parmi les partenaires d’AccuKnox. Les entreprises européennes font face à une pression croissante liée notamment à NIS2 et DORA. Elles ont besoin de partenaires capables de comprendre à la fois les exigences réglementaires et les contrôles techniques nécessaires pour y répondre.
Ariovis a développé cette expertise dans le domaine de l’identité. Notre plateforme CNAPP et AI Security a précisément été conçue pour compléter ce type d’approche, en réunissant protection à l’exécution, réduction de la surface d’attaque et automatisation de la conformité au sein d’une plateforme unifiée. C’est le Zero Trust appliqué concrètement.»
Brooke Pietsch, VP Sales – Europe, AccuKnox
À propos d’Ariovis
Ariovis est un pure player de l’Identity & Access Management (IAM) qui accompagne les organisations dans la définition, la mise en œuvre et l’évolution de leurs stratégies de gestion des identités et des accès.
Ses expertises couvrent la stratégie IAM & Zero Trust, la gouvernance des identités (IGA), les accès et l’authentification, le Privileged Access Management (PAM), l’autorisation fine, la sécurité Active Directory et Entra ID, le CIAM ainsi que les enjeux liés aux identités non humaines et aux agents IA.
Ariovis intervient de manière ponctuelle ou dans la durée, du conseil à l’intégration et au RUN, avec une approche privilégiant l’engagement de résultats.
Présent notamment à Paris, Bordeaux, Berlin et Bruxelles, Ariovis accompagne des organisations de différents secteurs en France et en Europe.
AccuKnox propose une plateforme de sécurité Zero Trust couvrant la sécurité de l’IA, des API, des applications, du cloud et de la supply chain logicielle.
Issue des travaux de R&D de SRI International (Stanford Research Institute), AccuKnox détient plusieurs brevets dans le domaine de la sécurité Zero Trust et bénéficie du soutien d’investisseurs tels que National Grid Partners, Dolby Family Ventures, Avanta Ventures et le 5G Open Innovation Lab.
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.
Ariovis est spécialisé dans la sécurisation des identités et des accès. Nous avons néanmoins choisi de consacrer ce guide à DNS4EU. Cette initiative va dans le sens des valeurs que nous défendons : saluer les initiatives européennes qui contribuent concrètement à renforcer notre souveraineté numérique, la protection des données et la résilience de nos infrastructures.
DNS4EU ne relève pas directement de l’IAM, mais s’inscrit dans une même ambition : construire un environnement numérique européen plus sûr, plus maîtrisé et moins dépendant d’acteurs extra-européens.
Introduction
Souhaitez-vous renforcer la sécurité et la confidentialité de votre connexion Internet ? Configurer votre appareil pour utiliser les serveurs DNS4EU est une solution simple et efficace.
DNS4EU est une initiative soutenue par l’Union européenne qui vise à proposer un service DNS public, sécurisé et respectueux de la vie privée. Son objectif est d’offrir une alternative européenne aux services DNS publics non européens, comme ceux de Google, tout en contribuant à renforcer la souveraineté numérique de l’Europe.
DNS4EU propose plusieurs profils selon le niveau de protection souhaité. Chaque profil permet d’activer ou non certaines protections, comme le blocage des sites malveillants, le contrôle parental ou le blocage de publicités.
Protective Resolution bloque les sites frauduleux ou malveillants, comme les domaines liés au phishing, aux logiciels malveillants ou aux cybermenaces.
Protective + Child Protection ajoute un contrôle parental en bloquant les contenus inadaptés aux enfants, en plus des sites malveillants.
Protective + Ad Blocking bloque les sites malveillants ainsi que certains domaines liés à la publicité ou au tracking.
Protective + Child Protection + Ad Blocking combine les trois protections : sécurité, contrôle parental et blocage publicitaire.
Unfiltered Resolution ne bloque pas de contenu volontairement. Il permet simplement d’utiliser un résolveur DNS européen sans filtrage supplémentaire.
Profil DNS4EU
Blocage de publicités
Contrôle parental
Blocage des sites frauduleux / malveillant
Protective Resolution
NON
NON
OUI
Protective + Child Protection
NON
OUI
OUI
Protective + Ad Blocking
OUI
NON
OUI
Protective + Child Protection + Ad Blocking
OUI
OUI
OUI
Unfiltered Resolution
NON
NON
NON
Configuration de DNS4EU sur téléphone
ANDROID
Sur Android, la configuration recommandée par Ariovis se fait avec le DNS privé, qui utilise le DNS over TLS, aussi appelé DoT. Cette méthode permet de configurer DNS4EU directement au niveau du système, afin que le téléphone utilise le profil DNS choisi pour ses requêtes DNS.Pour configurer DNS4EU sur Android :
Option 1 : Selon le modèle de votre téléphone Android, le chemin d’accès peut varier.
Ouvrez l’application Paramètres de votre smartphone.
Accédez à la rubrique Connexions ou Réseau et Internet.
Cliquez sur Plus de paramètres de connexion ou Paramètres avancés, selon le modèle.
Accédez à DNS privé.
Sélectionnez l’option Nom d’hôte du fournisseur DNS privé.
Saisissez le DNS correspondant au profil DNS4EU choisi dans le tableau présenté plus haut.
Cliquez sur Enregistrer.
Option 2 : Depuis la recherche des paramètres
Ouvrez l’application Paramètres de votre smartphone.
Cliquez sur l’icône de recherche, généralement représentée par une loupe.
Recherchez DNS privé.
Accédez au menu DNS privé.
Sélectionnez l’option Nom d’hôte du fournisseur DNS privé.
Saisissez le DNS correspondant au profil DNS4EU choisi dans le tableau présenté plus haut.
Cliquez sur Enregistrer.
Une fois la configuration enregistrée, Android utilisera DNS4EU pour ses requêtes DNS. Les adresses à renseigner selon le profil choisi seront indiquées dans le tableau récapitulatif à la fin de l’article.
IOS (iPhone/iPad)
Sur iPhone et iPad, la configuration recommandée par Ariovis se fait en DNS classique IPv4. Cette méthode permet d’indiquer directement les serveurs DNS4EU à utiliser pour un réseau Wi-Fi donné.
À noter : cette configuration s’applique uniquement au réseau Wi-Fi sélectionné. Si vous utilisez plusieurs réseaux Wi-Fi, il faudra répéter la manipulation pour chacun d’eux.
Pour configurer DNS4EU sur iPhone ou iPad :
Ouvrez l’application Réglages.
Appuyez sur Wi-Fi.
Sélectionnez le réseau Wi-Fi utilisé en appuyant sur l’icône i.
Faites défiler jusqu’à la section DNS.
Appuyez sur Configurer DNS.
Sélectionnez Manuel.
Supprimez les serveurs DNS existants afin de vous assurer que l’appareil utilise uniquement le profil DNS4EU choisi. Si d’autres DNS restent configurés, certaines requêtes peuvent passer par ces serveurs et contourner le filtrage attendu.
Appuyez sur Ajouter un serveur.
Saisissez l’adresse DNS correspondant au profil DNS4EU souhaité.
Appuyez sur Enregistrer.
Une fois la configuration enregistrée, l’iPhone ou l’iPad utilisera DNS4EU pour les requêtes DNS effectuées sur ce réseau Wi-Fi. Les adresses à renseigner selon le profil choisi seront indiquées dans le tableau récapitulatif à la fin de l’article.
Configuration de DNS4EU sur ordinateur
Sur ordinateur, la configuration recommandée par Ariovis se fait en DNS classique IPv4/IPv6. Cette méthode permet d’indiquer directement les serveurs DNS4EU à utiliser par la connexion réseau de l’ordinateur.
À noter : la configuration s’applique à la connexion sélectionnée. Si vous utilisez à la fois le Wi-Fi et l’Ethernet, il faudra configurer les deux interfaces si vous souhaitez utiliser DNS4EU dans les deux cas.
Windows
W11
Ouvrez les Paramètres de Windows.
Accédez à Réseau et Internet.
Sélectionnez votre connexion active : Wi-Fi ou Ethernet.
Ouvrez les propriétés de la connexion.
Recherchez la section Attribution du serveur DNS.
Cliquez sur Modifier.
Sélectionnez Manuel.
Activez IPv4, selon les adresses DNS que vous souhaitez renseigner.
Saisissez les serveurs DNS correspondant au profil DNS4EU souhaité.
Supprimez les anciens serveurs DNS si vous souhaitez utiliser uniquement DNS4EU.
Enregistrez la configuration.
W10
Ouvrez les Paramètres de Windows.
Accédez à Réseau et Internet.
Cliquez sur Modifier les options d’adaptateur.
Faites un clic droit sur votre connexion active : Wi-Fi ou Ethernet.
Cliquez sur Propriétés.
Sélectionnez Protocole Internet version 4 (TCP/IPv4).
Cliquez sur Propriétés.
Sélectionnez Utiliser l’adresse de serveur DNS suivante.
Saisissez les serveurs DNS correspondant au profil DNS4EU souhaité.
Validez avec OK.
Une fois les paramètres enregistrés, Windows utilisera DNS4EU pour les requêtes DNS effectuées depuis cette connexion réseau. Les adresses DNS à renseigner selon le profil choisi seront indiquées dans le tableau récapitulatif à la fin de l’article.
macOS
Ouvrez les Réglages Système.
Accédez à Réseau.
Sélectionnez votre connexion active : Wi-Fi ou Ethernet.
Cliquez sur Détails.
Accédez à la rubrique DNS.
Cliquez sur le bouton + pour ajouter un serveur DNS.
Saisissez les serveurs DNS correspondant au profil DNS4EU souhaité.
Supprimez les anciens serveurs DNS si vous souhaitez utiliser uniquement DNS4EU.
Validez les modifications.
Une fois la configuration appliquée, macOS utilisera DNS4EU pour les requêtes DNS effectuées depuis cette connexion réseau.
Les adresses DNS à renseigner selon le profil choisi seront indiquées dans le tableau récapitulatif à la fin de l’article.
Linux
Sur Linux, la procédure peut varier selon la distribution utilisée, par exemple Ubuntu, Debian, Fedora ou Linux Mint, ainsi que selon l’environnement graphique installé.
Dans la plupart des cas, la configuration peut se faire depuis les paramètres réseau du système.
Ouvrez les Paramètres du système.
Accédez à la rubrique Réseau ou Wi-Fi.
Sélectionnez votre connexion active.
Ouvrez les paramètres de cette connexion.
Accédez à l’onglet IPv4.
Désactivez le DNS automatique si nécessaire.
Saisissez les serveurs DNS correspondant au profil DNS4EU souhaité.
Enregistrez les modifications.
Déconnectez puis reconnectez le réseau si nécessaire.
Une fois la configuration appliquée, Linux utilisera DNS4EU pour les requêtes DNS effectuées depuis cette connexion réseau. Les adresses DNS à renseigner selon le profil choisi seront indiquées dans le tableau récapitulatif à la fin de l’article.
Configuration de DNS4EU sur navigateur
Pour les navigateurs, la configuration recommandée par Ariovis se fait avec le DNS over HTTPS, aussi appelé DoH. Cette méthode permet au navigateur d’utiliser DNS4EU directement pour ses propres requêtes DNS.
À noter : cette configuration s’applique uniquement au navigateur concerné. Les autres applications de l’ordinateur continueront à utiliser les DNS configurés au niveau du système.
Opéra
Ouvrez Opera.
Accédez aux Paramètres.
Recherchez DNS ou DNS over HTTPS dans la barre de recherche des paramètres.
Activez l’option DNS over HTTPS ou DNS sécurisé.
Sélectionnez un fournisseur personnalisé si l’option est disponible.
Saisissez l’adresse DoH correspondant au profil DNS4EU souhaité.
Enregistrez ou fermez les paramètres.
Microsoft Edge
Ouvrez Microsoft Edge.
Cliquez sur le menu …, puis sur Paramètres.
Accédez à Confidentialité, recherche et services.
Faites défiler jusqu’à la section Sécurité.
Activez l’option Utiliser un DNS sécurisé.
Sélectionnez l’option permettant de choisir un fournisseur personnalisé.
Saisissez l’adresse DoH correspondant au profil DNS4EU souhaité.
Enregistrez ou fermez les paramètres.
Google Chrome
Ouvrez Google Chrome.
Cliquez sur le menu ⋮, puis sur Paramètres.
Accédez à Confidentialité et sécurité.
Cliquez sur Sécurité.
Activez l’option Utiliser un DNS sécurisé.
Sélectionnez l’option permettant de choisir un fournisseur personnalisé.
Saisissez l’adresse DoH correspondant au profil DNS4EU souhaité.
Enregistrez ou fermez les paramètres.
Firefox
Ouvrez Mozilla Firefox.
Cliquez sur le menu ☰, puis sur Paramètres.
Accédez à Vie privée et sécurité.
Recherchez la section DNS over HTTPS.
Activez le DNS over HTTPS en sélectionnant la protection renforcée.
Sélectionnez un fournisseur personnalisé.
Saisissez l’adresse DoH correspondant au profil DNS4EU souhaité.
Enregistrez la configuration.
Une fois la configuration appliquée, le navigateur utilisera DNS4EU pour ses requêtes DNS. Les adresses DoH à renseigner selon le profil choisi seront indiquées dans le tableau récapitulatif à la fin de l’article.
Tableau récapitulatif des adresses DNS4EU
Profil DNS4EU
DNS classique IPv4 pour iPhone, iPad, Windows, macOS et Linux
DNS over TLS (DoT) pour Android
DNS over HTTPS (DoH) pour Opera, Edge, Chrome et Firefox
Protective Resolution
86.54.11.1 86.54.11.201
protective.joindns4.eu
https://protective.joindns4.eu/dns-query
Protective + Child Protection
86.54.11.12 86.54.11.212
child.joindns4.eu
https://child.joindns4.eu/dns-query
Protective + Ad Blocking
86.54.11.13 86.54.11.213
noads.joindns4.eu
https://noads.joindns4.eu/dns-query
Protective + Child Protection + Ad Blocking
86.54.11.11 86.54.11.211
child-noads.joindns4.eu
https://child-noads.joindns4.eu/dns-query
Unfiltered Resolution
86.54.11.100 86.54.11.200
unfiltered.joindns4.eu
https://unfiltered.joindns4.eu/dns-query
Pour garantir un comportement cohérent, il est recommandé d’utiliser uniquement les adresses du même profil DNS4EU. Mélanger plusieurs profils, par exemple un profil avec contrôle parental et un profil sans filtrage, peut rendre le filtrage moins fiable.
Vérifier que DNS4EU est bien actif
Une fois la configuration terminée, il est recommandé de vérifier que votre appareil utilise bien DNS4EU.
Pour cela, ouvrez votre navigateur et rendez-vous sur le site de test officiel :
Si la configuration est correcte, le site indiquera que vous utilisez bien DNS4EU. Si ce n’est pas le cas, vérifiez que vous avez renseigné la bonne adresse DNS, que vous avez supprimé les anciens serveurs DNS si nécessaire, puis redémarrez votre navigateur ou reconnectez votre réseau.
Conclusion
Installer DNS4EU sur vos appareils est une solution simple pour renforcer la sécurité et la confidentialité de votre connexion Internet. En choisissant le profil adapté à vos besoins, vous pouvez limiter l’accès aux sites malveillants, activer un contrôle parental ou réduire certains contenus publicitaires.
Grâce à ce guide, vous pouvez configurer DNS4EU sur vos téléphones, ordinateurs et navigateurs, tout en bénéficiant d’un service DNS européen orienté vers la protection de la vie privée.
Ariovis, votre expert informatique pour sécuriser votre réseau
Changer de DNS est une première étape vers une meilleure protection de votre réseau. Toutefois, la sécurité informatique ne s’arrête pas à la configuration DNS : elle implique aussi la gestion des accès, la protection des équipements, la supervision et la sécurisation des infrastructures.
Ariovis accompagne les entreprises et les organisations dans leurs projets IAM et Zero Trust : gouvernance des identités, sécurisation des accès, PAM, autorisation fine et protection des environnements AD et Entra ID.
Imaginez-vous, vous sortez un soir, tout se passe bien. Vous marchez dans la rue à contempler l’architecture d’une nouvelle ville. Puis, sans que vous ne le voyiez venir, une silhouette se rapproche dans votre dos. Un geste rapide, presque furtif, et avant même que vous ne réalisiez ce qui se passe, votre téléphone n’est plus dans votre poche. 😬
Vous paniquez, cherchez à repérer le voleur dans la foule, mais sans succès.
Le stress monte d’un coup. Vous êtes dans un endroit que vous ne connaissez pas, sans téléphone pour vous repérer, sans aucune idée de comment rentrer.
Et au-delà de l’appareil lui-même, c’est tout ce qu’il contenait qui vous traverse l’esprit : vos photos, vos messages, vos accès aux comptes, toutes vos données personnelles, entre les mains de quelqu’un d’autre.
Il faut aussi penser au dépôt de plainte. Vous devez vous rendre au commissariat le plus proche, raconter les faits, donner l’heure, le lieu, la description, le modèle du téléphone, parfois sans même savoir précisément où vous êtes. Ce n’est pas juste désagréable, ça vient s’ajouter à une situation déjà bien assez stressante.
Vous rentrez enfin chez vous. Et là, heureusement que vous avez un PC connecté à votre portée de main : vous verrouillez votre téléphone à distance, et le voleur ne peut plus rien y faire.
J’ai bien dit votre PC connecté. Imaginez maintenant l’inverse : ce PC n’est pas connecté, et il ne vous reste qu’un vieux téléphone oublié au fond d’un placard pour essayer de vous reconnecter à votre compte Google, Proton, et j’en passe.
C’est là que le vrai problème apparaît : ce n’est pas le vol du smartphone en lui-même qui pose souci. C’est que ce smartphone est aussi votre passe-partout, votre identité de connexion.
Si vous mettez le même mot de passe partout, ou si vous ne dépassez pas le stade d’un mot de passe tout simple niveau sécurité, vous n’allez sans doute pas vous reconnaître dans tout ça. Mais restez, la suite vous concerne quand même.
Si vous avez donc activé la double authentification sur votre smartphone volé, à travers une clé, une application 2FA comme Proton Authenticator, Aegis, Google Authenticator… ou votre numéro de téléphone enregistré pour recevoir un code à 6 chiffres, c’est le mur face à vous. Vous ne pouvez plus vous connecter à votre/vos compte(s).
La bonne nouvelle, c’est que ce mur, vous pouvez le préparer à l’avance. Voici les trois filets de sécurité que je vous conseille de mettre en place, maintenant, pas le jour où ça vous arrive.
La double sécurité, l’avantage qu’on oublie trop souvent
La double authentification protège contre le vol de mot de passe. Mais elle a un angle mort qu’on ignore trop souvent : si elle repose entièrement sur un seul appareil, votre téléphone, alors ce téléphone devient votre unique point de défaillance.
Et c’est là le vrai message de cet article :
Si vous n’avez que votre téléphone comme moyen d’authentification, alors c’est vous la faille.
Pas votre mot de passe. Pas le service que vous utilisez. Vous, et le choix d’avoir tout misé sur un seul appareil.
L’idée, c’est de répartir vos moyens de preuve d’identité sur au moins deux appareils différents, pas deux fois le même type. Concrètement, ça peut être une combinaison parmi :
Un ordinateur (session déjà connectée, ou clé d’accès enregistrée)
Une clé physique de sécurité (YubiKey ou équivalent)
Un numéro de téléphone (par SMS, en dernier recours uniquement)
Une authentification sans mot de passe / biométrie (passkey, empreinte digitale)
Une lettre scellée avec vos mots de passe ou codes de secours, en notant la date, leur durée de validité si elle existe, le lien et le nom du site concerné
L’avantage, c’est que la perte d’un seul de ces appareils ne vous bloque jamais. Si votre téléphone disparaît, votre ordinateur ou votre clé physique prend le relais. C’est le même principe que le compte de secours du chapitre suivant, mais appliqué à chaque appareil de la chaîne, pas seulement au compte.
Les codes de secours (backup codes)
La plupart des services sérieux (Google, Proton, GitHub, votre gestionnaire de mots de passe…) génèrent une liste de codes de secours à usage unique quand vous activez la double authentification. C’est souvent caché dans les paramètres de sécurité, et c’est souvent ignoré. 🙈
Ces codes vous permettent de vous connecter une seule fois, sans votre téléphone, sans votre clé, sans rien d’autre. Le hic, c’est qu’il faut les avoir sous la main au moment où vous en avez besoin, donc pas dans un fichier texte sur le bureau de l’ordinateur que vous n’avez pas avec vous.
Ce que je fais : je les imprime, ou je les note à la main, et je les range dans un endroit physique sûr (pas dans mon portefeuille, à côté du téléphone qui vient justement de se faire voler). Un coffre, un tiroir chez un proche, ce que vous voulez, mais pas avec vous au quotidien.
Une clé de sécurité physique (FIDO2 / YubiKey)
Si vous voulez aller plus loin que les simples codes, une clé de sécurité physique (YubiKey, ou équivalent compatible FIDO2/U2F) est une excellente seconde clé. Le principe : vous en achetez deux, vous en enregistrez une que vous gardez sur vous, vous laissez l’autre planquée chez vous ou chez quelqu’un de confiance.
Si la première disparaît avec votre téléphone, ou même seule, la deuxième vous permet de continuer à vous connecter normalement, et surtout de révoquer l’accès à celle qui a été volée.
C’est un petit investissement, mais c’est largement le plus solide des trois filets, parce que contrairement aux codes papier, on ne peut pas vous la voler en même temps que votre téléphone.
Un compte ou contact de confiance
Certains services proposent un système de contact de confiance ou de récupération de compte (Google a son contact de confiance, Apple a son contact de récupération, Proton a sa procédure dédiée). Le principe est simple : une personne que vous désignez peut vous aider à prouver que c’est bien vous, même sans accès à votre 2FA.
Ce n’est pas magique, ça prend parfois plusieurs jours de vérification, mais ça reste une porte de sortie quand les deux solutions précédentes n’ont pas été préparées à temps.
Et si ça vous arrive sans rien de tout ça
Si vous n’avez rien préparé et que ça vous arrive, ne paniquez pas, mais soyez méthodique :
Verrouillez et localisez votre téléphone à distance dès que possible, depuis n’importe quel appareil connecté à votre compte.
Lancez les procédures de récupération de compte de chaque service, une par une, même si elles sont longues.
Changez vos mots de passe principaux depuis un appareil sain, en commençant par votre messagerie principale, c’est souvent la clé de tout le reste.
Désactivez ou révoquez les anciennes méthodes 2FA liées au téléphone volé, dès que vous avez de nouveau accès.
Petite checklist à faire maintenant, pas demain
Générer et imprimer ses codes de secours pour ses comptes principaux
Enregistrer une seconde méthode 2FA (clé physique ou autre appareil)
Configurer un contact ou une procédure de récupération
Vérifier que sa messagerie principale a, elle aussi, ces trois filets
Le vol de téléphone, on ne le contrôle pas. Mais l’accès à votre identité numérique, si. 💪
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.
Dans la cybersécurité, nous passons nos journées à protéger les systèmes contre les risques. Nous aidons les organisations à sécuriser leurs infrastructures, leurs données et leurs activités face à des menaces toujours plus complexes.
Mais la confiance ne se limite pas aux systèmes d’information.
Elle se construit aussi entre les personnes.
Chez Ariovis, nous sommes convaincus qu’un environnement de travail fondé sur le respect, l’écoute et la liberté d’être soi-même est un levier essentiel de performance, d’innovation et d’épanouissement professionnel.
Le Mois des Fiertés est l’occasion de rappeler cette conviction.
S’il est aujourd’hui célébré dans de nombreux pays, c’est parce que les personnes LGBTQIA+ continuent de faire face à des discriminations, y compris dans le monde professionnel. Pour beaucoup, parler librement de leur vie personnelle, de leur conjoint·e ou simplement être eux-mêmes au travail reste encore source d’appréhension.
Ces réalités nous rappellent qu’une entreprise a un rôle à jouer dans la construction d’environnements professionnels respectueux, sûrs et ouverts à tous·tes.
La responsabilité d’une entreprise ne s’arrête pas à ses services
Les enjeux de cybersécurité évoluent rapidement. Les organisations doivent s’adapter, innover et attirer les meilleurs talents pour relever des défis toujours plus complexes.
Mais cette capacité d’innovation dépend avant tout des personnes qui composent les équipes.
C’est pourquoi notre démarche RSE s’appuie sur une conviction forte : chaque collaborateur·trice doit pouvoir évoluer dans un environnement où il est respecté·e, reconnu·e pour ses compétences et libre d’exprimer pleinement son potentiel.
Cette approche se traduit par plusieurs engagements :
Favoriser l’égalité des chances ;
Encourager la diversité des profils et des parcours ;
Prévenir toute forme de discrimination ;
Développer une culture d’entreprise basée sur le respect et l’écoute ;
Créer un cadre de travail où chacun peut s’exprimer librement et être reconnu pour ses compétences.
Parce qu’au-delà des expertises techniques, ce sont aussi les conditions de travail et la qualité des relations humaines qui permettent à chacun de donner le meilleur de lui-même.
La diversité comme moteur de performance
Dans les métiers de la cybersécurité et du numérique, la diversité n’est pas uniquement une question de représentation.
Elle constitue un véritable avantage stratégique.
Des équipes composées de profils variés apportent des visions complémentaires, enrichissent les réflexions et permettent d’aborder les problématiques sous différents angles.
Cette pluralité favorise l’innovation, améliore la prise de décision et contribue à construire des solutions plus adaptées aux réalités des organisations que nous accompagnons.
Les cybermenaces évoluent en permanence. Pour y répondre efficacement, nous avons besoin de talents capables de remettre en question les certitudes, d’identifier des angles morts et de proposer de nouvelles approches.
La richesse des parcours, des expériences et des sensibilités contribue directement à cette capacité d’adaptation.
La confiance, une valeur essentielle en cybersécurité comme dans les relations humaines
La cybersécurité repose sur un principe fondamental : la confiance.
Les organisations nous confient la protection de leurs données, de leurs infrastructures et parfois de leurs activités les plus critiques.
Cette confiance ne peut exister sans transparence, écoute et respect.
Nous pensons que ces mêmes principes doivent également guider les relations humaines au sein de l’entreprise.
Créer un environnement où chacun peut être lui-même, sans avoir à masquer son identité ou ses différences, participe à construire cette confiance au quotidien.
Car une équipe dans laquelle les collaborateur·trices se sentent respecté·es et écouté·es est une équipe qui communique mieux, collabore davantage et ose exprimer ses idées.
Cette sécurité psychologique est essentielle. Elle favorise la circulation de l’information, la créativité, l’engagement et la capacité à relever collectivement les défis auxquels nous faisons face.
Un engagement qui dépasse le Mois des Fiertés
Le Mois des Fiertés permet de célébrer les avancées réalisées, mais aussi de rappeler que l’égalité et le respect ne doivent jamais être considérés comme acquis.
Pour nous, ces sujets ne se limitent pas à une prise de parole ponctuelle ou à une action symbolique.
Ils s’inscrivent dans une démarche continue visant à promouvoir un numérique plus responsable, plus ouvert et plus respectueux des individus.
Chez Ariovis, nous croyons qu’un environnement professionnel fondé sur la confiance et le respect n’est pas seulement une question de valeurs : c’est aussi une condition nécessaire pour attirer les talents, favoriser l’innovation et construire des organisations plus solides.
Construire un avenir numérique plus sûr passe également par la création d’environnements professionnels où chacun a sa place, où les différences sont respectées et où les compétences peuvent pleinement s’exprimer.
C’est cette vision que nous continuerons à porter, pendant le Mois des Fiertés et tout au long de l’année.
![[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)
