Fin de SAP IDM : 2027 approche. Ne remplacez pas votre tour de contrôle IAM par une simple brique technique

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

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.