Catégorie : Articles

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. 

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 : 

https://test.joindns4.eu

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.

Pour bénéficier d’un accompagnement personnalisé, contactez nous ou visitez notre site ariovis.fr 

Mise en situation

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 application 2FA (Aegis, Proton Authenticator, Google Authenticator…)
• 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 :

1. Verrouillez et localisez votre téléphone à distance dès que possible, depuis n’importe quel appareil connecté à votre compte.
2. Lancez les procédures de récupération de compte de chaque service, une par une, même si elles sont longues.
3. 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.
4. 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.

L’interconnexion indispensable : IAG et Access Management

Pour opérer cette bascule, le PAM doit cesser de jouer en solo et s’orchestrer avec les deux autres piliers de l’IAM :

• L’IAG (Identity Governance & Administration) : Elle apporte la couche de sens et de conformité. Qui est l’utilisateur ? Quel est son rôle réel ? Quelle logique métier justifie son élévation ? Sans l’IAG, le PAM contrôle, mais ne justifie rien.
• L’Access Management : Il fournit l’intelligence contextuelle en temps réel. Depuis quel environnement la demande émane-t-elle ? Avec quel niveau de confiance et quels signaux de risque ?

Moderniser son bastion sans revoir son modèle d’accès global est un leurre fréquent. On se retrouve alors avec une technologie rutilante, mais des processus flous et des exceptions permanentes. La vraie maturité consiste à lier l’authentification, le contexte et le contrôle.

Vers une cyber-maturité transformante

En décloisonnant le PAM, l’entreprise bascule d’une posture défensive à une dynamique de transformation. Les privilèges dormants s’effacent, les revues d’accès gagnent en lisibilité et la trajectoire Zero Trust devient enfin une réalité opérationnelle.

Le futur du PAM n’est pas dans l’autonomie, mais dans l’interconnexion maîtrisée. Traiter le privilège pour ce qu’il est vraiment — un droit sensible, éphémère par nature et hautement contextuel —, c’est là que se situe la frontière de la maturité cyber.

 

Environnement : Debian 12 • PingIDM 8.0.1 • PostgreSQL 17 • Java Temurin 17

Conventions : Toutes les commandes sont exécutées en tant qu’utilisateur standard avec sudo quand l’élévation de privilèges est nécessaire.
Le répertoire d’installation est /opt/openidm/ (le zip extrait un dossier openidm/).

Étape 1 – Mise à jour du système

sudo apt update -y && sudo apt upgrade -y

Étape 2 – Installation de Java (Temurin JDK 17)

PingIDM 8 requiert JDK 17.0.3 ou supérieur. La doc officielle recommande Eclipse Temurin.

sudo apt install -y wget apt-transport-https gnupg

wget -O - https://packages.adoptium.net/artifactory/api/gpg/key/public \
    | sudo tee /usr/share/keyrings/adoptium.asc

echo "deb [signed-by=/usr/share/keyrings/adoptium.asc] \
  https://packages.adoptium.net/artifactory/deb \
  $(awk -F= '/^VERSION_CODENAME/{print$2}' /etc/os-release) main" \
  | sudo tee /etc/apt/sources.list.d/adoptium.list

sudo apt update -y
sudo apt install -y temurin-17-jdk

Configurer JAVA_HOME

echo "export JAVA_HOME=/usr/lib/jvm/temurin-17-jdk-amd64" | sudo tee -a /etc/environment
source /etc/environment
java -version

Étape 3 – Installation de PostgreSQL

PingIDM 8.0.1 supporte PostgreSQL 16 et 17.

sudo apt install -y postgresql postgresql-contrib
sudo systemctl enable --now postgresql
sudo systemctl status postgresql

Étape 4 – Installation des utilitaires

sudo apt install -y wget unzip curl

Étape 5 – Créer un utilisateur dédié et déployer le binaire PingIDM

Le zip contient un dossier openidm/. On l’extrait directement dans /opt/ pour obtenir /opt/openidm/.

sudo useradd -r -m -d /opt/openidm -s /bin/bash openidm
cp IDM-8.0.1.zip /tmp/
cd /opt
sudo unzip /tmp/IDM-8.0.1.zip
sudo chown -R openidm:openidm /opt/openidm
rm /tmp/IDM-8.0.1.zip

Étape 6 – Configurer PostgreSQL pour IDM

6.1 – Modifier pg_hba.conf

sudo nano /etc/postgresql/17/main/pg_hba.conf

Ajouter :

local   all   openidm   trust
local   all   postgres  trust

Note : trust est acceptable en lab. En production, utiliser md5 ou scram-sha-256.

Puis redémarrer PostgreSQL :

sudo systemctl restart postgresql

6.2 – Créer la base de données et le rôle openidm

sudo -u postgres psql -f /opt/openidm/db/postgresql/scripts/createuser.pgsql

6.3 – Créer les tables IDM

psql -U openidm < /opt/openidm/db/postgresql/scripts/openidm.pgsql

6.4 – Créer les tables Flowable (workflow engine)

psql -d openidm -U openidm < /opt/openidm/db/postgresql/scripts/flowable.postgres.all.create.sql

6.5 – Créer les tables d’audit (optionnel)

psql -d openidm -U openidm < /opt/openidm/db/postgresql/scripts/audit.pgsql

6.6 – Optimisation des index (recommandé)

Relire le script avant exécution pour vérifier que les index correspondent à votre déploiement :

sudo -u postgres psql -d openidm -f /opt/openidm/db/postgresql/scripts/default_schema_optimization.pgsql

Étape 7 – Configurer IDM pour PostgreSQL

7.1 – Supprimer la config DS par défaut

cd /opt/openidm/conf/
sudo rm repo.ds.json

7.2 – Copier les fichiers de configuration PostgreSQL

sudo cp /opt/openidm/db/postgresql/conf/datasource.jdbc-default.json \
        /opt/openidm/conf/

sudo cp /opt/openidm/db/postgresql/conf/repo.jdbc.json \
        /opt/openidm/conf/

7.3 – Configurer la connexion JDBC

Éditer datasource.jdbc-default.json si vous avez changé le mot de passe de l’utilisateur openidm :

sudo nano /opt/openidm/conf/datasource.jdbc-default.json

Contenu attendu :

{
  "driverClass" : "org.postgresql.Driver",
  "jdbcUrl" : "jdbc:postgresql://&{openidm.repo.host}:&{openidm.repo.port}/openidm",
  "databaseName" : "openidm",
  "username" : "openidm",
  "password" : "openidm",
  "connectionTimeout" : 30000,
  "connectionPool" : {
    "type" : "hikari",
    "minimumIdle" : 20,
    "maximumPoolSize" : 50
  }
}

7.4 – Configurer boot.properties

sudo nano /opt/openidm/resolver/boot.properties

Ou exporter la variable OPENIDM_OPTS :

export OPENIDM_OPTS="-Xmx2048m -Xms2048m -Dopenidm.repo.host=localhost -Dopenidm.repo.port=5432"

Étape 8 – Configurer les locales (si nécessaire)

sudo dpkg-reconfigure locales
sudo nano /etc/default/locale
sudo reboot

PostgreSQL nécessite des locales UTF-8 correctement configurées.

Étape 9 – Démarrer PingIDM

sudo su - openidm
cd /opt/openidm
./startup.sh

Sortie attendue :

Using OPENIDM_HOME: /opt/openidm
Using PROJECT_HOME: /opt/openidm
Using OPENIDM_OPTS: -Xmx2048m -Xms2048m ...
-> OpenIDM version "8.0.1"
OpenIDM ready

IDM écoute par défaut sur les ports 8080 (HTTP) et 8443 (HTTPS).

Note production : Configurez openidm.host dans boot.properties sur l’URL de votre déploiement, sinon les redirections vers /admin ne fonctionneront pas correctement.

Références

• Documentation officielle PingIDM 8.0.1 — Installation
• PostgreSQL Repository
• Java Requirements
• Before You Install

Introduction : L’IAM, bien plus qu’une question technique

À l’ère de la transformation numérique, la gestion des identités et des accès (IAM) est souvent perçue comme un sujet réservé aux équipes IT. Pourtant, une cartographie IAM bien conçue est un levier stratégique pour les entreprises qui souhaitent concilier sécurité, conformité et performance. Comment ? En rendant visible l’invisible : les liens entre les identités, les droits d’accès et les objectifs métiers.

Exemple concret : Un groupe industriel a réduit de 40 % les délais d’intégration de ses équipes après une fusion en cartographiant ses accès selon les nouveaux processus métiers — un gain direct sur sa capacité à capitaliser sur la synergie post-acquisition, sans surcoût.

La cartographie IAM : Un outil au service de la performance business

Pourquoi cartographier son IAM ?

La cartographie IAM est une représentation dynamique des identités, des rôles, des droits d’accès et des flux au sein de votre système d’information. Son objectif : aligner la gestion des accès sur les enjeux métiers et en mesurer l’impact.

Enjeu Business	Apport de la cartographie IAM	Exemple concret	Impact mesurable
Croissance	Standardiser les accès pour les nouvelles filiales ou partenaires.	Un acteur du retail a déployé 8 enseignes en 3 mois (au lieu de 6) grâce à des profils d’accès préconfigurés.	Intégration 2x plus rapide.
Innovation	Sécuriser l’accès aux environnements cloud et aux données R&D.	Un laboratoire pharma a réduit de 70 % les demandes d’accès urgentes, accélérant la mise sur marché.	Lancement de produits accéléré de 25 %.
Conformité	Faciliter les audits et réduire les risques de sanctions (RGPD, NIS2, etc.).	Une institution financière a cartographié les accès aux données clients sensibles par métier, évitant des pénalités coûteuses.	-40 % d’écarts détectés en audit.
Expérience collaborateur	Simplifier l’accès aux outils (SSO, délégation de droits).	Une ESN a mis en place un portail d’accès unifié, réduisant de 60 % les demandes de réinitialisation de mot de passe.	-50 % de tickets IT liés aux problèmes d’accès.
Maîtrise des coûts	Éliminer les comptes inutiles et optimiser les licences logicielles.	Un groupe logistique a identifié et désactivé 1 200 comptes inactifs, libérant des licences sans achat supplémentaire.	Jusqu’à 20 % d’économies.

Comment construire une cartographie IAM alignée sur le business ?

6 étapes clés pour une IAM « Security meet Business »

1. Impliquer les métiers dès le départPourquoi ? Parce qu’une cartographie efficace commence par comprendre les processus critiques (ex. : vente, production, RH) et leurs besoins réels en accès.Bénéfice : Réduction des coûts cachés liés aux accès mal gérés.
2. Prioriser en fonction des enjeux stratégiquesQuestion clé : « Quels projets (digitalisation, expansion) seront accélérés par une IAM optimisée ? »Exemple : Une banque a priorisé l’accès aux données clients pour son projet de plateforme digitale, évitant des retards coûteux.
3. Cartographier les rôles métiers, pas les postesRésultat : Moins de doublons, moins de temps perdu à gérer des droits inutiles.
4. Visualiser les liens entre IAM et performanceExemple : Un schéma partagé entre DSI et RH a permis de réduire les délais d’intégration de 30 %, avec un impact direct sur la productivité.
5. Automatiser la gouvernanceAvantage : Des règles dynamiques (accès temporaires, revues automatiques) réduisent les coûts manuels.
6. Itérer et s’adapterObjectif : Une cartographie qui évolue avec la stratégie, sans investissements répétés.

Étude de cas : L’IAM au cœur de la transformation

Contexte : Un acteur de la logistique digitalise sa supply chain. Les accès fragmentés ralentissent la collaboration et génèrent des coûts évitables.

Solution :

• Cartographie des rôles supply chain (ex. : « Approvisionneur Europe ») et de leurs besoins.
• Automatisation des droits en fonction des événements métiers (ex. : ouverture d’un nouveau site).

Résultats :

• Réduction de 30 % des délais de traitement des commandes.
• Baisse de 60 % des erreurs liées aux droits manquants.
• Économies significatives sur les licences et le support.

Conclusion : L’IAM, un accélérateur invisible mais puissant et rentable

Une cartographie IAM bien conçue est invisible pour les utilisateurs, mais visible pour la stratégie et le ROI. Elle permet de : 

✅ Sécuriser sans freiner l’innovation, tout en réduisant les coûts cachés (licences, support, retards). 

✅ Concilier conformité et agilité, en évitant les amendes et les risques opérationnels. ✅ Transformer les accès en levier de performance, avec un retour sur investissement mesurable (jusqu’à 300 % sur 2 ans pour les projets alignés).

Prochaine étape : Auditez votre maturité IAM avec notre grille d’analyse « Security meet Business » pour identifier vos gains potentiels.