Pourquoi un projet IAM échoue avant même l'installation de l'outil
Sur des systèmes d'information construits pendant des décennies, ce n'est presque jamais la plateforme qui manque. Ce sont les règles du jeu que personne n'a encore écrites.
Un projet qui commence par les bonnes questions
Un grand établissement nous a contactés récemment pour lancer un projet IGA. Environ 20 000 collaborateurs, plusieurs centaines d'applications, plusieurs Active Directory, plusieurs sources RH, plusieurs équipes IT et plusieurs équipes métiers. Le sponsor était convaincu que l'enjeu principal consistait à installer rapidement Netwrix Identity Manager pour reprendre le contrôle des habilitations.
Lors des premiers ateliers, nous n'avons pourtant jamais ouvert l'outil. Nous avons posé un autre type de questions, volontairement plus élémentaires.
Qu'est-ce qu'une identité ? Qu'est-ce qu'un manager ? Quand une identité naît-elle réellement ? Quand disparaît-elle ? Qui décide des habilitations ? Qui en est responsable ? Quelle donnée fait foi ?
Les réponses divergent en quelques minutes. Les RH ne répondent pas comme la DSI. La sécurité ne répond pas comme les métiers. Chaque application possède sa propre logique d'habilitation. Chaque Active Directory a ses propres conventions de nommage et ses propres groupes. Chaque équipe utilise son propre vocabulaire pour désigner les mêmes objets.
Le problème n'est pas technologique. Le problème est que personne, dans l'organisation, n'a jamais eu à écrire noir sur blanc les règles du jeu.
Le produit n'est pas le point de départ
Beaucoup d'organisations cherchent leur réponse dans le produit. Elles nous demandent quels modules activer, quels connecteurs développer en priorité, quels workflows outiller. Ce sont des questions légitimes, mais posées trop tôt.
Nous prenons le problème dans l'autre sens. La plateforme devient un moyen d'explorer le système d'information. Les données rapatriées servent à retrouver les règles de gestion déjà présentes dans l'entreprise, souvent portées par quelques personnes et rarement documentées.
Notre travail consiste à transformer ces pratiques implicites en règles explicites. Un outil de gouvernance des identités ne crée pas la gouvernance. Il la révèle, puis il permet de l'automatiser.
Quatre observations de terrain
Voici quelques situations rencontrées récemment, choisies parce qu'elles reviennent sous des formes voisines chez la plupart des grandes organisations.
- 01
Deux profils pour un même rôle
Deux applications gérant le même domaine métier attribuent deux profils différents à des utilisateurs qui, dans leur esprit, exercent exactement le même rôle. En pratique, les droits techniques ne se recouvrent pas. Personne ne s'en était rendu compte parce que personne n'avait mis les deux modèles côte à côte.
- 02
Trois Active Directory, trois logiques
Trois annuaires distribuent les droits d'administration selon des logiques différentes. L'un s'appuie sur des groupes nommés par équipe, un autre sur des groupes par application, le troisième mélange les deux. Ce sont des pratiques historiques que plus personne ne sait justifier.
- 03
Des validations sans lecture
Des managers valident des demandes d'accès sans savoir précisément ce que représentent les profils qu'ils approuvent. Le libellé du profil parle le langage du métier ; les droits techniques qui se cachent derrière parlent le langage des systèmes.
- 04
Deux organigrammes qui coexistent
Le référentiel RH désigne un responsable hiérarchique qui n'est pas celui utilisé dans plusieurs applications. Les workflows applicatifs se sont construits au fil du temps, chaque équipe s'est constitué son propre organigramme fonctionnel, et personne ne l'a rapproché de la source autoritative.
Aucune de ces situations ne se résout en activant une fonctionnalité. Toutes se résolvent en mettant les faits sur la table.
Ce que Netwrix Identity Manager permet, dans le bon ordre
Netwrix Identity Manager est une plateforme que nous utilisons régulièrement, en particulier chez les clients dont la trajectoire l'appelle. Nous en connaissons bien les composants. Voici comment nous nous en servons — non pour dérouler une démonstration produit, mais pour illustrer l'ordre dans lequel chaque brique prend sa place.
- Identity Warehouse
- Nous ne l'utilisons pas d'abord comme un moteur de provisioning. Nous nous en servons comme d'un miroir. En rapprochant plusieurs référentiels RH, plusieurs Active Directory et quelques applications critiques, il fait apparaître les écarts. Ce sont ces écarts qui alimentent nos ateliers, pas des slides.
- Role Management
- Nous ne créons pas les rôles dans l'outil. Nous les découvrons dans les données. Lorsqu'un pattern d'habilitations partagé par un groupe cohérent d'identités apparaît, il devient candidat à la formalisation. Il se transforme alors en business role, testable et révisable.
- Workflow Engine
- Les workflows d'accès existent déjà, sous forme d'échanges par messagerie, de tickets et de conversations. Le moteur ne les invente pas, il les rend traçables et reproductibles. Nous refusons de coder dans l'outil ce qui n'a jamais été décrit hors de l'outil.
- Policy Engine
- Une politique métier — segregation of duties, contrainte d'éligibilité, condition d'attribution — doit être formulée, débattue et assumée par ceux qui en portent la responsabilité. Nous ne codifions dans le moteur que ce que l'organisation a d'abord accepté.
- Access Requests
- Une demande d'accès n'a de valeur que si les rôles, les responsabilités et les niveaux d'approbation ont été compris en amont. Sinon, le portail se contente d'industrialiser l'ambiguïté.
- Recertification
- Une campagne de recertification valide une gouvernance déjà construite. Elle ne permet pas de la découvrir. Lancée trop tôt, elle épuise les managers et produit une conformité en apparence, sans améliorer la qualité réelle des accès.
- Reporting
- Une fois la gouvernance en place, les tableaux de bord mesurent sa qualité : taux de couverture, comptes orphelins, écarts entre la source RH et les systèmes cibles, complétude des campagnes. Ce n'est pas la première étape, c'est l'étape qui donne du sens à toutes celles qui précèdent.
Ce qu'il faut retenir
Le logiciel est indispensable. Sur les périmètres que nous traitons — plusieurs dizaines de milliers d'identités, plusieurs centaines d'applications, plusieurs annuaires, plusieurs sources RH — aucune gouvernance sérieuse ne tient sans plateforme.
Mais l'outil n'est jamais le point de départ. Notre première mission consiste à comprendre les règles de fonctionnement de l'organisation. Quand ce travail a été fait, la plateforme devient un véritable accélérateur. Sans lui, même le meilleur produit ne produit qu'une gouvernance apparente.
Modéliser avant d'automatiser
Avant de raccorder les applications, d'automatiser les workflows et de lancer les premières campagnes de recertification, nous cherchons d'abord à comprendre les règles qui structurent déjà l'organisation. Elles existent toujours. Elles sont simplement dispersées entre plusieurs équipes, plusieurs systèmes et plusieurs générations de décisions.
C'est ce travail de modélisation, patient et souvent peu spectaculaire, qui donne ensuite du levier à Netwrix Identity Manager et aux autres briques de l'écosystème IAM. Un projet IAM ne commence pas au moment où l'on installe l'outil. Il commence au moment où l'on accepte de regarder honnêtement comment l'organisation fonctionne.