Un projet IGA ne commence paspar un connecteur
Le sujet n'est pas de provisionner des comptes. C'est de décider quels accès sont légitimes, puis de garder cette décision vraie dans le temps, alors que les personnes, les organisations et les applications changent.
Netwrix Identity Manager — anciennement Usercube — permet d'industrialiser la gouvernance des identités, des rôles et des habilitations. Nous l'utilisons pour transformer des processus IAM réels en système exploitable : sources RH, cycles de vie, rôles, provisioning, réconciliation, certifications, preuves d'audit, migration et RUN.
Page technique et méthodologique. Ce n'est pas une fiche produit : les capacités décrites sont celles documentées par l'éditeur, la méthode est la nôtre.
L'IGA ne commence pas par l'outil
Processus avant outils. Identité avant compte. Qualité des données comme fondation. Standard avant spécifique. Automatisation contrôlée, architecture progressive, documentation systématique, formation intégrée, RUN proactif. Ce sont ces principes qui décident de la configuration, pas l'inverse.
Ce que nous cherchons à comprendre avant de configurer
Avant la première règle, nous instruisons un ensemble de questions dont les réponses conditionnent tout le reste. Quand ces réponses manquent, le paramétrage ne fait que déplacer le problème.
- Quelles populations existent réellement : salariés, prestataires, alternants, intérimaires, comptes de service, identités non humaines ?
- Quelles sources font foi pour quelles données, et que faire quand elles se contredisent ?
- Quels événements déclenchent un cycle de vie, et qui les émet ?
- Qui possède chaque application, et qui valide ses droits ?
- Quels droits sont structurels, quels droits sont métier, quels droits sont exceptionnels ?
- Quels systèmes peuvent être écrits automatiquement, lesquels doivent rester en lecture ?
- Quels accès doivent être revus, à quelle fréquence, par qui ?
- Quelles preuves l'organisation doit-elle être capable de produire ?
- Quels écarts sont acceptables, et lesquels ne le sont pas ?
Le périmètre se priorise
Toutes les applications ne rejoignent pas la plateforme en même temps. Nous séquençons selon le risque, la volumétrie de demandes et la disponibilité d'un propriétaire côté métier.
La donnée se qualifie avant de se gouverner
Un référentiel RH incomplet produit des identités fausses, donc des droits faux. Nous mesurons la qualité des données avant d'en faire la source d'un provisioning automatique.
Le standard d'abord
Chaque spécifique se paie deux fois : à la construction, puis à chaque montée de version. Nous ne développons que lorsque la configuration standard ne couvre pas le besoin.
Ce que Netwrix Identity Manager permet de structurer
Ce ne sont pas des fonctionnalités à cocher, ce sont les objets que le projet doit définir. La plateforme les industrialise ; elle ne les invente pas à votre place.
- 01
Les identités
La plateforme consolide des informations issues de plusieurs sources pour constituer un référentiel d'identités. L'éditeur documente la couverture des identités humaines et non humaines : salariés, prestataires, comptes de service et autres populations selon le contexte.
- Salariés, prestataires, populations temporaires
- Comptes de service et identités non humaines
- Réconciliation des doublons entre sources
- Attributs structurants : organisation, poste, site, contrat
Une identité n'est pas un compte. Une même personne peut avoir plusieurs comptes, dépendre de plusieurs organisations, cumuler des responsabilités, changer de métier ou passer par une situation temporaire. Le modèle d'identité doit refléter la réalité métier avant de piloter les accès.
- 02
Le cycle de vie
Arrivée, mobilité, changement d'organisation ou de poste, suspension, départ, retour, corrections RH intermédiaires. L'enjeu est de transformer un événement de référence en décisions cohérentes.
- Identité, comptes, rôles, groupes, droits
- Notifications aux bons interlocuteurs
- Actions manuelles résiduelles assumées et tracées
- Workflows et provisioning pilotés par des règles
Le design du lifecycle est un travail fonctionnel avant d'être technique. Le plus difficile n'est jamais l'arrivée : c'est la mobilité, où l'ancien périmètre doit disparaître au moment où le nouveau apparaît.
- 03
Les rôles et les droits
Rôles métier, rôles techniques, compositions lorsque c'est pertinent, droits directs et exceptions. L'éditeur documente un modèle de rôles, du RBAC, du role mining assisté, la détection des accès excessifs et des conflits SoD.
- Rôles métier issus de l'organisation réelle
- Rôles techniques par application
- Droits exceptionnels isolés et datés
- Analyse des écarts et optimisation progressive
Le but n'est pas de créer cinq mille rôles pour « faire du RBAC ». Un bon modèle est compréhensible, reflète les métiers, reste maintenable, réduit les exceptions et sait évoluer. Le role mining aide à voir ; il ne décide pas à la place des responsables.
- 04
Les demandes d'accès
Une partie des accès doit être automatique parce qu'elle découle du poste. Le reste doit être demandable, justifiable et révocable.
- Attribution automatique par rôle
- Demande manuelle lorsqu'elle est justifiée
- Circuits d'approbation par propriétaire d'application
- Droits temporaires et exceptions avec échéance
L'objectif est d'éviter que chaque accès devienne un ticket ou un e-mail. Un accès prévisible ne devrait jamais nécessiter une décision humaine.
- 05
Le provisioning
L'écriture vers les systèmes cibles : automatique, manuelle ou hybride. L'éditeur documente la possibilité de revoir les ordres de provisioning avant leur exécution.
- Ordres de provisioning revus avant exécution si nécessaire
- Reprise sur erreur et rejeu non destructif
- Traçabilité de bout en bout
- Actions manuelles routées vers l'ITSM quand l'écriture est impossible
Tout ce qui peut être automatisé ne doit pas nécessairement être automatisé immédiatement. Dans les contextes sensibles, nous commençons en lecture, nous simulons, nous faisons valider, puis nous autorisons les écritures.
Les capacités listées correspondent à ce que l'éditeur documente pour Netwrix Identity Manager. Leur disponibilité exacte dépend de la version et de l'architecture retenue : nous la vérifions au cadrage plutôt que de la promettre par défaut.
Simuler avant d'écrire : une méthode de déploiement, pas une précaution
Sur les périmètres sensibles, nous ne donnons pas immédiatement à une nouvelle règle le droit d'agir. Nous lui demandons d'abord de montrer ce qu'elle compte faire. Selon le contexte, cela prend la forme d'une simulation, d'un mode bloqué, d'un traitement dupliqué sans étape d'écriture, ou d'un compte technique dépourvu de droits de modification.
- 1
Connecter la source et la cible
- 2
Lire l'existant sans rien modifier
- 3
Calculer les décisions attendues
- 4
Simuler les changements et compter les opérations
- 5
Vérifier les impacts objet par objet
- 6
Faire valider les règles par les propriétaires
- 7
Activer les écritures, périmètre par périmètre
- Limiter les régressions sur des systèmes en production
- Détecter les erreurs de mapping avant qu'elles ne deviennent des incidents
- Valider le modèle de rôles sur des données réelles
- Rassurer les équipes applicatives, qui gardent la main sur leur périmètre
- Mesurer les volumes avant toute modification réelle
Réconcilier le théorique et le réel
Une IGA qui ne calcule que ce qui « devrait » exister ne gouverne rien. Elle doit aussi relire ce que les systèmes contiennent réellement, puis comparer. L'éditeur documente la détection des affectations non conformes, des comptes non autorisés, des comptes orphelins ou inutilisés, ainsi que la réconciliation des rôles et des propriétés.
Ce que la plateforme calcule
- Identités issues des sources de référence
- Rôles attribués par les règles
- Droits attendus par application
- Comptes qui devraient exister
Ce que les systèmes contiennent
- Comptes réellement présents dans l'annuaire
- Groupes et habilitations effectifs
- Droits ajoutés directement dans la cible
- Comptes sans usage récent
Les écarts à traiter
- Affectations non conformes
- Comptes non autorisés
- Comptes orphelins ou dormants
- Provisioning non abouti
- Attributs divergents
Certifier les accès sans transformer les managers en auditeurs IAM
Netwrix Identity Manager permet de planifier des campagnes de certification sur des périmètres ciblés, de faire revoir les droits, de retirer les accès inappropriés et de produire le reporting associé. La difficulté n'est pas de lancer une campagne : c'est d'en obtenir un résultat exploitable.
Une campagne mal conçue produit des validations aveugles. Le reviewer valide tout, l'organisation en tire une preuve formelle sans valeur, et le risque reste exactement où il était.
Ce qui rend une campagne inutile
- Trop de lignes présentées d'un bloc
- Des libellés techniques incompréhensibles
- Trop de faux positifs, donc plus aucune attention
- Un reviewer qui n'est pas le bon
- Aucune conséquence donnée aux décisions
Ce sur quoi nous travaillons
- Identifier le bon reviewer pour chaque droit
- Traduire les habilitations en langage métier
- Limiter et séquencer le périmètre
- Contextualiser : depuis quand, pourquoi, qui d'autre
- Traiter réellement les retraits décidés
- Mesurer les résultats et améliorer la campagne suivante
Séparation des tâches et combinaisons sensibles
L'éditeur documente la détection des conflits de séparation des tâches et des accès excessifs. Le sujet n'est pas réglementaire en soi : il consiste à identifier les combinaisons de droits que votre organisation considère comme incompatibles, puis à les rendre visibles et gouvernables.
Nous ne promettons pas une conformité générique. Nous aidons à écrire les règles, à les traduire dans la plateforme et à assumer les exceptions qui subsistent.
- Définition des combinaisons incompatibles avec les métiers concernés
- Traduction des règles dans la plateforme
- Gouvernance des exceptions : qui approuve, pour combien de temps
- Contrôles récurrents plutôt que contrôle unique
- Traçabilité utilisable en audit
Une règle SoD sans propriétaire métier ne survit pas à la première exception.
Les connecteurs : là où le projet rencontre le vrai SI
Nos environnements croisent des systèmes très hétérogènes. Certains disposent d'une intégration standard, d'autres se traitent par API, par script, par traitement générique, par développement spécifique, ou restent volontairement manuels via l'ITSM.
- SIRH et sources RH
- Active Directory
- Microsoft Entra ID
- LDAP
- Exchange
- SharePoint
- EasyVista / ITSM
- SAP
- WebMethods
- API REST
- SCIM
- Bases de données
- Applications internes
- SaaS
- Systèmes historiques
Intégration standard
La cible est prise en charge par une intégration prévue par la plateforme. Le travail porte sur les mappings, les filtres et les conditions d'écriture.
Intégration configurable ou par API
La cible expose une API, du SCIM, une base ou des fichiers. Nous construisons le contrat d'échange, les opérations autorisées et la gestion des erreurs.
Traitement spécifique ou manuel
Certaines applications ne peuvent pas être écrites depuis l'extérieur. La décision reste gouvernée par la plateforme, l'exécution passe par un ordre suivi dans l'ITSM.
- Comprendre les opérations réellement supportées par la cible
- Définir les mappings attribut par attribut
- Décider ce qui est lu et ce qui est écrit
- Traiter les erreurs et les cas partiels
- Sécuriser les comptes techniques et leurs droits
- Documenter le connecteur pour ceux qui l'exploiteront
- Superviser et prévoir la maintenance dans le temps
SaaS ou on-premises
Netwrix Identity Manager existe en SaaS et en on-premises, et l'éditeur documente aujourd'hui la possibilité de passer d'un modèle à l'autre sans réimplémentation complète. Nous intervenons sur les deux. Le choix se justifie par le contexte, pas par une préférence.
Le SaaS peut répondre à
- Une exploitation simplifiée
- Une mise en route plus rapide
- Une réduction de l'infrastructure à maintenir
- Une volonté de standardisation
L'on-premises peut s'imposer pour
- Des contraintes d'hébergement ou de souveraineté
- Une architecture réseau ou des interconnexions particulières
- Des politiques internes de sécurité
- Une exigence de maîtrise opérationnelle complète
Build. Migrate. Take over.
Nous ne faisons pas que des déploiements neufs. Trois situations très différentes se présentent, et elles n'appellent ni la même équipe, ni la même méthode.
Build
Construire un nouveau socle de gouvernance des identités.
- Cadrage des populations et des sources
- Modèle d'identité et modèle de rôles
- Cycle de vie et workflows
- Premiers connecteurs, puis extension progressive
Migrate
Migrer un environnement existant, notamment du SaaS vers l'on-premises.
- Analyse des flux et des dépendances
- Préservation des processus en place
- Qualification des spécifiques et revue des connecteurs
- Bascule sécurisée, tests, documentation, continuité de service
Take over
Reprendre une plateforme déjà en production, parfois instable ou sous-exploitée.
- Comprendre et documenter ce qui existe
- Analyser les incidents récurrents
- Traiter les connecteurs fragiles
- Restaurer une gouvernance, reconstruire un backlog, stabiliser puis améliorer
Construire, migrer, reprendre : trois métiers, une même exigence de continuité.
Notre méthode projet
La même trame sert au build, à la migration et à la reprise. Seul le point d'entrée change.
- 1
Assess
Comprendre le terrain avant de proposer une cible.
- Populations
- Sources
- Applications
- Processus
- Irritants
- Risques
- Architecture
- 2
Design
Décider le modèle, puis seulement ensuite la configuration.
- Modèle d'identité
- Cycle de vie
- Modèle de rôles
- Workflows
- Mappings
- Architecture
- Gouvernance
- 3
Build
Construire en privilégiant le standard.
- Configuration
- Connecteurs
- Règles
- Workflows
- Reporting
- 4
Simulate
Mesurer l'impact avant d'écrire.
- Synchronisation
- Calcul
- Analyse d'impact
- Mode bloqué lorsque pertinent
- 5
Validate
Prouver que le système fait ce qui a été décidé.
- Tests unitaires
- Intégration
- Recette
- Qualité des données
- Non-régression
- Critères d'acceptation
- 6
Deploy
Basculer sans perdre le service.
- Bascule
- Mise en production
- Hypercare
- Documentation
- 7
Operate
Tenir la plateforme dans la durée.
- Support
- Incidents
- Maintenance
- Montées de version
- Connecteurs
- Campagnes
- 8
Improve
Étendre la couverture et la qualité.
- Nouvelles applications
- Nouvelles populations
- Role mining
- Qualité des données
- Automatisation
- Optimisation
Les étapes se recouvrent : un périmètre peut être en RUN pendant qu'un autre est encore en simulation.
Ce que le client reçoit
Un projet IGA ne se livre pas en jours-homme. Il se livre en artefacts qui doivent rester compréhensibles une fois l'équipe projet partie.
Conception
- Dossier d'architecture
- Modèle d'identité
- Modèle de rôles
- Règles de gestion
- Matrices de mapping
- Spécifications de connecteurs
- Description des workflows
Construction et validation
- Configurations
- Scripts et packages lorsque nécessaire
- Stratégie de tests
- Cahier de recette
- Résultats de tests
- Rapport de qualité des données
Exploitation
- Documentation d'installation
- Documentation d'administration
- Documentation d'exploitation
- Procédures de support
- Procédures de mise en production
- Kit de formation
- Backlog et reporting de RUN
L'équipe autour du projet
Un projet IGA ne repose pas sur un « consultant produit ». Il repose sur des rôles complémentaires, et sur une coordination qui dépasse largement l'équipe IAM.
Les rôles mobilisés
- Chef de projet
- Architecte IAM
- Expert Netwrix Identity Manager
- Consultant fonctionnel
- Intégrateur
- Expert connecteurs
- Support N2 / N3
- Formateur
Ce qu'il faut coordonner
- Métier
- RH
- Sécurité
- Architecture
- Infrastructure
- Applications
- Support
- Conformité
La plupart des retards que nous observons ne viennent pas de la plateforme, mais de décisions métier qui n'ont pas de propriétaire identifié.
Le client ne doit pas rester dépendant
Le transfert de compétences fait partie du projet, pas d'une phase optionnelle en fin de parcours. Nous formons au fil de la construction, sur la configuration réelle du client plutôt que sur un environnement de démonstration.
L'objectif est que l'équipe interne soit autonome sur les opérations normales, et que nous restions mobilisables pour les évolutions complexes et le RUN si l'organisation le souhaite.
- Formation des administrateurs de la plateforme
- Prise en main pour les équipes support
- Accompagnement des responsables applicatifs sur les validations et les campagnes
- Ateliers de conception plutôt que présentations
- Documentation écrite pendant le projet, pas après
Le projet ne s'arrête pas au go-live
Un système IAM se dégrade s'il n'évolue pas avec le SI, les métiers, les RH, les rôles, les applications et les organisations. Le RUN ne consiste donc pas à « maintenir le serveur vert » : il contribue à maintenir la qualité de la gouvernance.
Nous exploitons des plateformes Netwrix Identity Manager en SaaS comme en on-premises, avec des engagements de service et une trajectoire d'amélioration continue.
- Support fonctionnel et technique, N2 / N3
- Incidents et maintenance corrective
- Évolutions et montées de version
- Maintenance des connecteurs
- Supervision des traitements et des écarts
- Exécution et amélioration des campagnes de certification
- Backlog, reporting, revues de service
Trois contextes réels, anonymisés
Secteurs et ordres de grandeur uniquement. Ces trois situations couvrent le build, la migration et la reprise.
Services financiers / banque
≈ 700 identités
- Architecture et trois environnements SaaS
- Données RH, Active Directory, Entra ID
- SharePoint, Exchange, EasyVista
- Workflows et optimisation du modèle de rôles
- Préparation de l'intégration SAP
- Formation des équipes
Construction d'un socle SaaS avec un modèle de rôles tenu et des intégrations réelles.
Secteur public territorial
≈ 2 000 identités
- Synchronisation RH et Active Directory
- Joiner / Mover / Leaver
- Exchange, WebMethods
- Refonte de connecteurs
- Automatisation des boîtes aux lettres
- Maintenance, montées de version, support
- Environ 40 évolutions livrées dans la durée
Migration vers l'on-premises sans rupture de service, puis maintenance engagée sur la durée.
Éditeur de logiciels / services RH
≈ 15 000 identités
- Analyse et stabilisation d'une plateforme existante
- Active Directory, Entra ID, interfaces RH, ITSM
- Workflows et autorisations
- Évolutions RH, incidents, support, maintenance
- Préparation du role mining
- Intégration de nouvelles applications
Reprise d'une plateforme en production, stabilisation puis amélioration continue.
Nous ne nommons aucun client sur cette page. Les références publiées le sont avec leur accord.
Une preuve externe, secondaire par rapport au delivery
Ariovis a reçu le Partnership Excellence Award Netwrix 2026. Cette reconnaissance dit quelque chose de la relation avec l'éditeur ; elle ne remplace pas ce que les équipes livrent sur les plateformes en production.
Vous n'avez peut-être pas besoin d'Identity Manager
Nous restons capables de conseiller de manière agnostique. Une plateforme IGA complète n'est pas la bonne première étape dans tous les contextes.
Les signaux
- Les processus d'arrivée, de mobilité et de départ ne sont pas définis
- Les sources RH sont incohérentes ou incomplètes
- Aucune application n'a de propriétaire identifié
- Le modèle de rôles n'existe pas, même sur le papier
- Le périmètre n'est pas priorisé
- L'organisation n'a pas les ressources pour exploiter le dispositif ensuite
De meilleures premières étapes
- Un cadrage
- Un audit
- Une cartographie des applications et des sources
- Une feuille de route
- Un socle pilote sur un périmètre réduit
Dans ces situations, installer une plateforme ne réglera rien : elle rendra visible, plus vite, un désordre qui n'a pas encore été arbitré.
Vous n'êtes pas prêt à lancer un programme IGA complet ? Commencez par prouver la valeur.
Le mini produit ROI IAM est une offre Ariovis, indépendante de tout éditeur. Il chiffre le retour sur investissement d'un programme IAM selon trois scénarios et vous restitue l'étude en PDF.
- Commencer sur un périmètre ciblé
- Objectiver les bénéfices attendus
- Structurer les priorités
- Construire une trajectoire, puis décider d'industrialiser ou non
Ce n'est ni une version allégée de Netwrix Identity Manager, ni un produit Netwrix, ni un remplacement d'une IGA.
Questions fréquentes
Qu'est-ce que Netwrix Identity Manager ?
C'est une plateforme d'Identity Governance & Administration (IGA), anciennement connue sous le nom d'Usercube. Elle sert à consolider un référentiel d'identités, automatiser les cycles de vie, gérer un modèle de rôles, provisionner les systèmes cibles, réconcilier l'état réel, détecter les accès excessifs et mener des campagnes de certification.
Quelle est la différence entre IAM et IGA ?
L'IAM est l'ensemble du domaine : identités, authentification, accès, privilèges, autorisation. L'IGA en est la partie gouvernance et administration : qui doit avoir quoi, pourquoi, pour combien de temps, et comment le prouver. Une IGA ne remplace ni l'Access Management, ni le PAM, ni l'autorisation runtime.
Netwrix Identity Manager fonctionne-t-il en SaaS et en on-premises ?
Oui, l'éditeur documente les deux architectures. Le choix dépend des contraintes d'hébergement, de souveraineté, d'interconnexion et de capacité d'exploitation. Nous intervenons sur les deux modèles.
Peut-on migrer du SaaS vers l'on-premises ?
L'éditeur indique aujourd'hui la possibilité de passer d'un modèle à l'autre sans réimplémentation complète. Dans la pratique, une migration reste un projet : analyse des flux, revue des connecteurs et des spécifiques, tests, bascule et continuité de service. Nous avons conduit ce type de migration.
Quels systèmes peut-on connecter ?
Nos environnements croisent des SIRH, Active Directory, Entra ID, LDAP, Exchange, SharePoint, des ITSM comme EasyVista, SAP, WebMethods, des API REST, du SCIM, des bases de données, des applications internes, du SaaS et des systèmes historiques. Tous ne disposent pas d'une intégration native : certaines cibles se traitent par API, par script, par traitement générique ou restent volontairement manuelles via l'ITSM.
Comment fonctionne le Joiner / Mover / Leaver ?
Un événement de référence, généralement issu du SIRH, déclenche le calcul des décisions : création ou mise à jour de l'identité, comptes, rôles, groupes, droits, notifications et éventuelles actions manuelles. La difficulté principale est la mobilité, où les anciens droits doivent disparaître au moment où les nouveaux apparaissent.
Qu'est-ce qu'un modèle de rôles dans une IGA ?
C'est la traduction structurée de l'organisation en droits : des rôles métier issus des postes et des entités, des rôles techniques par application, et des exceptions assumées. Un bon modèle est compréhensible et maintenable ; le nombre de rôles n'est pas un indicateur de qualité.
Quelle différence entre provisioning et réconciliation ?
Le provisioning applique une décision dans un système cible. La réconciliation relit ce que ce système contient réellement et le compare à l'état attendu. Le provisioning raconte ce qui a été demandé ; la réconciliation raconte ce qui existe.
À quoi servent les campagnes de certification ?
À faire réexaminer périodiquement les accès par les personnes responsables, retirer ce qui n'est plus justifié et produire une preuve. Leur valeur dépend entièrement de la qualité de l'information présentée au reviewer.
Netwrix Identity Manager gère-t-il les identités non humaines ?
L'éditeur documente la couverture des identités humaines et non humaines, dont les comptes de service. Le périmètre exact dépend du modèle d'identité défini pendant le projet et des systèmes réellement raccordés.
Ariovis peut-il reprendre une plateforme existante ?
Oui. Une part de notre activité consiste à reprendre des plateformes déjà en production, parfois peu documentées ou instables : analyse de l'existant, remise à niveau de la documentation, traitement des connecteurs fragiles, reconstruction d'un backlog, stabilisation puis amélioration.
Ariovis assure-t-il le RUN après le projet ?
Oui, si l'organisation le souhaite : support N2/N3, incidents, maintenance, montées de version, connecteurs, supervision, campagnes, backlog et revues de service. Nous formons aussi les équipes internes pour qu'elles restent autonomes sur les opérations courantes.
Faut-il forcément commencer par Netwrix Identity Manager ?
Non. Si les processus, les sources et la propriété des applications ne sont pas établis, une plateforme IGA ne fera qu'accélérer le désordre. Un cadrage, une cartographie ou le mini produit ROI IAM constituent souvent une meilleure première étape.
Parlons de votre plateforme, pas de la nôtre
Nouveau socle, migration, ou reprise d'un environnement existant : la première conversation utile porte sur vos processus, vos sources et vos irritants.