Transformation et RUN
Migrer depuis SailPoint IdentityIQ : reprendre la gouvernance sans reproduire la complexité
Remplacer SailPoint IdentityIQ ne consiste pas à reproduire une plateforme IGA dans une autre technologie. Un environnement IdentityIQ concentre souvent plusieurs années de règles d'habilitation, de workflows, de connecteurs, de certifications et de développements spécifiques. Une migration doit préserver les processus utiles, corriger les incohérences existantes et garantir la continuité des accès.
Contrairement à une migration depuis SAP Identity Management, structurée par une échéance de maintenance, quitter SailPoint relève généralement d'une décision d'architecture, d'exploitation ou d'investissement. L'organisation peut rechercher davantage d'autonomie, une meilleure maîtrise des coûts, une gouvernance plus lisible ou une plateforme adaptée à l'évolution de son système d'information.
Chez Ariovis, nous commençons par vérifier que le remplacement de la plateforme constitue réellement la bonne réponse. Certaines difficultés peuvent provenir du modèle de gouvernance, de l'intégration ou de l'organisation plutôt que du produit. Lors d'une étude menée pour un groupe industriel international de 10 000 identités, nous avons ainsi recommandé de conserver et d'automatiser le dispositif existant après avoir étudié plusieurs solutions. Une décision de migration doit reposer sur la valeur attendue, pas sur la seule volonté de changer d'éditeur.
Notre méthodologie de reprise SailPoint IdentityIQ repose sur quatre étapes : découvrir l'existant, traduire les fonctions métier, construire et valider la cible, puis organiser la coexistence et la bascule.
1. Découverte de l'existant : récupérer l'intelligence d'IdentityIQ
La première étape consiste à comprendre ce que SailPoint fait réellement. La console IdentityIQ propose des mécanismes documentés d'extraction d'objets XML, notamment les règles, workflows et configurations applicatives. Ces exports, réalisés avec les autorisations nécessaires, facilitent l'inventaire technique, mais ne constituent ni une sauvegarde fonctionnelle exhaustive ni un format directement importable dans un autre IAG.
Nous complétons cette extraction par l'analyse des identités, des comptes corrélés, des rôles, des habilitations, des connecteurs, des traitements planifiés, des règles SoD et des campagnes de certification. Pour chaque système, nous identifions les flux de lecture et d'écriture, les dépendances, les personnalisations et les traitements manuels. Les historiques de certification et les preuves d'audit font l'objet d'un inventaire spécifique.
L'enjeu principal consiste à retrouver les décisions métier derrière les configurations. Qui justifie un accès ? Quelle source fait autorité ? Comment une mobilité modifie-t-elle les habilitations ? Qui valide une exception et comment est-elle révoquée ? Ces questions permettent de distinguer les règles encore légitimes de celles qui ont simplement survécu aux évolutions de l'organisation.
Retour d'expérience — 15 000 identités dans les services RH. Ariovis a repris une plateforme IGA existante dont les traitements et l'exploitation nécessitaient une stabilisation. L'intervention a porté sur l'analyse des incidents, la fiabilisation des workflows, la maintenance et la préparation de nouveaux raccordements. Ce projet, réalisé sur Netwrix Identity Manager, illustre notre méthode de reprise d'un patrimoine IGA : comprendre avant de transformer, puis documenter les responsabilités et les dépendances.
La découverte produit une cartographie fonctionnelle et technique, un inventaire des développements spécifiques, une analyse de qualité des données et un registre des risques. Ces livrables permettent de définir les premiers lots de migration sans découvrir les dépendances critiques lors de la bascule.
2. Traduction fonctionnelle : conserver les décisions, pas les configurations
Les objets IdentityIQ et ceux de la plateforme cible ne sont pas nécessairement équivalents. Notre méthode consiste à reconstruire les fonctions de gouvernance autour des identités, des rôles, des droits, des demandes, des validations et des contrôles de conformité. Chaque composant est évalué pour déterminer s'il doit être conservé, simplifié, reconstruit différemment ou abandonné.
Le modèle de rôles mérite une attention particulière. Reproduire les rôles SailPoint sans les analyser peut reconduire des habilitations excessives ou une granularité devenue ingérable. Le role mining permet d'identifier des regroupements de droits, mais leur fréquence d'attribution ne démontre pas leur légitimité. Nous croisons donc les données techniques avec les responsabilités métier pour construire des rôles compréhensibles et des exceptions gouvernées.
Faire de la conformité un objectif de migration
La migration offre également l'occasion de revoir les contrôles attendus par les politiques internes, les audits et les référentiels réglementaires.
La fiche ANSSI « ReCyF en pratique — Gestion des identités », publiée en septembre 2026, détaille notamment l'objectif de sécurité 10 : identification des utilisateurs, authentification, gestion des droits d'accès et traçabilité. Les mesures 10.A et 10.C sont particulièrement pertinentes pour vérifier le rattachement des comptes aux identités, l'attribution des droits selon les responsabilités, leur révision et leur retrait lorsqu'ils ne sont plus justifiés.
Nous traduisons ces exigences en critères de recette : démontrer qui détient une habilitation, pourquoi elle est accordée, qui l'a validée, quand elle a été revue et si son retrait a effectivement été exécuté. La conservation des historiques et la distinction entre désactivation et suppression des comptes doivent également être traitées.
Une plateforme IGA contribue à ces objectifs, mais ne couvre pas à elle seule toutes les exigences NIS2. L'authentification forte, la supervision et certains contrôles de privilèges relèvent d'autres composants, conformément à notre approche de l'IAM et de la conformité NIS2.
Retour d'expérience — Harmonisation IGA dans la défense. Ariovis a accompagné l'extension d'un dispositif de gouvernance des identités de la France vers l'Allemagne, dans un environnement comportant des populations sensibles et des contraintes locales distinctes. La démarche a consisté à harmoniser les principes de gouvernance sans effacer les particularités organisationnelles. Cette expérience est directement transposable à la traduction fonctionnelle d'un environnement SailPoint multinational.
Le résultat de cette phase est un modèle cible validé : matrice de correspondance fonctionnelle, catalogue des rôles, workflows, règles SoD, traitement des exceptions et exigences de conformité. Les adaptations spécifiques sont identifiées avant leur développement.
3. Construction et validation : démontrer les processus de bout en bout
Nous privilégions la construction d'un premier périmètre associant une source RH, un référentiel d'identités, un annuaire et une application métier. Il doit permettre de démontrer les processus Joiner, Mover, Leaver, les demandes d'accès, les validations et les opérations de provisioning avant de généraliser les raccordements.
Les tests ne doivent pas seulement vérifier la création de comptes. Une mobilité doit entraîner l'attribution des nouveaux droits et le retrait des anciens ; un départ doit provoquer les révocations attendues dans les applications ; une erreur de connexion doit être détectée, journalisée et reprise selon une procédure définie. Les résultats sont comparés aux règles métier approuvées, et pas uniquement aux comportements historiques d'IdentityIQ.
Exploiter les capacités de Netwrix Identity Manager
Lorsqu'une migration vers Netwrix Identity Manager, anciennement Usercube, est envisagée, nous confrontons les besoins extraits de SailPoint aux capacités documentées du produit.
Les fiches Netwrix Identity Manager présentent notamment la gestion centralisée des identités, les rôles métier et techniques, les workflows de demandes et de validation, l'automatisation du cycle de vie, les campagnes de certification, les contrôles SoD et la réconciliation continue. Cette dernière capacité permet de comparer les habilitations réellement constatées aux droits attendus et d'identifier des attributions réalisées directement dans les applications.
Les fiches consacrées aux connecteurs distinguent les interfaces standards, les modules additionnels et les opérations prises en charge. Active Directory, Entra ID, LDAP, SQL, SCIM, SAP ou Salesforce figurent parmi les environnements documentés, mais leur présence dans un catalogue ne garantit pas une couverture identique des opérations de lecture, d'écriture et de suppression.
Nous vérifions donc les capacités exactes de chaque interface, les licences nécessaires et les adaptations éventuelles. Lorsque le système cible permet d'utiliser une API ou le protocole SCIM, nous étudions la possibilité de remplacer un connecteur spécifique historique par une intégration standardisée, sous réserve de valider son comportement réel.
Retour d'expérience — Construction IGA dans les services financiers. Pour un environnement d'environ 700 identités, Ariovis a construit un socle Netwrix Identity Manager intégrant plusieurs environnements SaaS, les données RH, Active Directory, Entra ID, SharePoint, Exchange et EasyVista. Le projet a associé modélisation des rôles, workflows, intégrations et formation des équipes, démontrant la nécessité d'évaluer les processus complets plutôt que les seules capacités de connexion.
La construction s'achève par une recette fonctionnelle, technique et de conformité. Les tests, les écarts acceptés, les procédures d'exploitation et les critères d'acceptation constituent les éléments permettant d'autoriser le passage en production.
4. Coexistence et bascule : maintenir la gouvernance sans doubles écritures
La migration peut s'effectuer par vagues, avec IdentityIQ conservé sur les périmètres non migrés. Pour chaque application, nous définissons quelle plateforme est autorisée à écrire, laquelle peut uniquement lire et comparer, et comment les opérations en attente sont traitées lors du transfert.
Lorsque l'architecture le permet, la nouvelle solution fonctionne d'abord en lecture ou en simulation. Les droits attendus sont comparés aux habilitations existantes avant l'activation du provisioning. Cette précaution limite notamment le risque de révocations massives provoquées par une erreur de corrélation ou une règle incorrecte.
Chaque bascule comprend un plan de déploiement, des contrôles de non-régression et une stratégie de retour arrière tenant compte des écritures déjà réalisées. Les historiques de certification, les décisions sensibles et les journaux utiles doivent rester consultables selon les obligations de conservation applicables, même après l'arrêt d'IdentityIQ.
Retour d'expérience — Migration IGA dans une collectivité. Ariovis a accompagné la migration d'un environnement Netwrix Identity Manager d'environ 2 000 identités, depuis une architecture SaaS vers une plateforme on-premises. Le projet comprenait les flux RH, Active Directory, les processus Joiner/Mover/Leaver et plusieurs connecteurs. Il s'est prolongé par une activité de support et de maintenance, avec environ quarante évolutions fonctionnelles, illustrant notre capacité à assurer la continuité entre migration et exploitation.
Le décommissionnement de SailPoint intervient après validation du transfert des responsabilités, de la stabilité des traitements et de la conservation des preuves nécessaires. La reprise en RUN IAM prévoit la supervision, le support N2/N3, la maintenance des connecteurs et l'amélioration continue du dispositif.
Piloter la migration avec des décisions et des résultats vérifiables
Une migration SailPoint ne se pilote pas uniquement avec un planning de connecteurs. Les processus RH, les règles d'habilitation, les validations métier et les contrôles de conformité nécessitent une gouvernance associant le responsable IAM, le RSSI, les équipes techniques, les propriétaires applicatifs et les métiers.
Nous structurons le programme autour d'un backlog priorisé, d'un RACI, de comités projet et de jalons d'acceptation. Les arbitrages fonctionnels précèdent les développements, tandis que les validations métier accompagnent chaque lot. La documentation et le transfert de compétences sont réalisés pendant le projet pour préparer l'autonomie des équipes internes.
Retour d'expérience — Reprise du pilotage IAM dans le retail. Ariovis a accompagné un groupe de distribution en assurant des responsabilités de pilotage produit, d'architecture et de coordination métier, auprès d'une équipe de 21 experts. La mission a permis de clarifier les priorités, de structurer la roadmap et de stabiliser les opérations. Elle illustre l'importance de notre méthode de reprise des programmes IAM lorsque la complexité organisationnelle dépasse la seule intégration technique.
Nous mesurons les résultats à partir des écarts identifiés lors du diagnostic initial : comptes correctement corrélés, comptes orphelins, délais de retrait des accès, taux de certification, conflits SoD non résolus, erreurs de provisioning et opérations manuelles résiduelles. Ces indicateurs sont associés à des objectifs définis avec le client selon ses risques, ses exigences de conformité et ses contraintes d'exploitation.
Préparer votre migration depuis SailPoint avec Ariovis
Ariovis accompagne les organisations depuis l'analyse d'IdentityIQ jusqu'à la conception, l'intégration, la recette, la bascule et le maintien en conditions opérationnelles de leur nouvel IGA.
Notre première intervention vise à qualifier la plateforme existante, identifier les dépendances et définir un périmètre pilote représentatif. Cette démarche permet d'établir une trajectoire réaliste, de comparer les architectures possibles et de sécuriser les premières décisions avant d'engager les travaux de migration.
Vous envisagez de remplacer SailPoint IdentityIQ ou souhaitez évaluer la pertinence de votre plateforme actuelle ? Échangez avec nos experts IAM pour construire une trajectoire de reprise adaptée à votre organisation.