Et si nous arrêtions de fabriquer des rôles ?
Sur la plupart des projets IGA que nous conduisons depuis la période post-Covid, la question n'est plus de savoir combien de rôles il faut construire. C'est de savoir ce que l'organisation produit déjà, et où l'attention humaine mérite vraiment d'être portée.
Un projet qui commence par un catalogue à écrire
Un client nous appelle un matin pour lancer un projet IGA. La demande est claire, presque programmatique. « Nous devons définir tous nos rôles métiers. » L'organisation est vaste : plusieurs dizaines de milliers d'identités, plusieurs centaines d'applications, plusieurs Active Directory, un Entra ID en consolidation, plusieurs populations, plusieurs milliers d'habilitations distribuées. Le sponsor est convaincu que la première étape consiste à écrire le catalogue exhaustif des rôles qui décriront chaque situation possible.
Nous commençons les ateliers avec les directions métiers. La conversation démarre sur quelques rôles simples. Puis chaque discussion produit ses propres cas particuliers. Un rôle devient deux. Deux deviennent cinq. Cinq deviennent vingt. Chaque exception, portée par une personne qui la connaît de l'intérieur, donne naissance à un nouveau rôle. Le catalogue croît plus vite que les décisions qu'il devrait porter.
Au bout de quelques semaines, un phénomène apparaît. Le modèle en construction devient plus complexe que l'organisation qu'il cherche à représenter. Les responsables métiers ne s'y retrouvent plus. Les architectes IAM commencent à douter. Personne n'ose supprimer un rôle, parce que chaque rôle correspond à un cas réel raconté par une personne réelle. Personne n'ose non plus en ajouter, parce que le catalogue devient ingérable.
Nous décidons alors de changer de question. Nous ne demandons plus « quels rôles devons-nous créer ». Nous demandons « quelles personnes travaillent déjà de manière comparable ». À partir de ce moment, la nature des ateliers change complètement. Les métiers cessent de projeter un modèle idéal. Ils commencent à regarder ce qui existe.
Un rôle est une conséquence, pas un point de départ
Un rôle n'est pas une entité qui préexiste à l'organisation. C'est une représentation possible d'un comportement observé. Il devient utile lorsqu'il condense fidèlement ce que font déjà, ensemble, plusieurs dizaines ou plusieurs centaines de personnes. Il devient encombrant lorsqu'il tente de codifier chaque exception que l'expérience quotidienne produit naturellement.
Une organisation fabrique en permanence des groupes de pairs. Ces groupes émergent des rattachements hiérarchiques, des départements, des fonctions, des établissements, des sociétés, des populations, des responsabilités confiées, des cycles de vie contractuels et, en dernier lieu, des habilitations effectivement attribuées. Ce sont des régularités. Elles existent avant que le projet IAM ne les nomme, et elles subsisteront après lui.
Notre travail ne consiste plus à décréter ces régularités depuis un tableau blanc. Il consiste à les faire apparaître dans les données, à les nommer avec les métiers qui les vivent, et à décider — cas par cas — laquelle mérite d'être formalisée sous forme de rôle et laquelle peut rester simplement observée. Le rôle devient alors une conséquence de l'analyse. Il n'en est plus le point de départ.
Quatre scènes qui racontent la même chose
Nous avons choisi quatre situations récentes, tirées de projets menés dans des secteurs différents. Chacune paraît locale. Ensemble, elles décrivent la même mécanique.
- 01
Une entreprise industrielle, plusieurs centaines de techniciens
Sur un groupe industriel, plusieurs centaines de techniciens sont répartis entre différents sites de production. Aucun rôle métier n'a été officiellement défini pour eux. Pourtant, lorsque nous rapprochons les données, leurs habilitations sont remarquablement cohérentes. Les mêmes applications de maintenance, les mêmes accès aux systèmes de supervision, les mêmes droits d'impression sur les postes en atelier. L'organisation produit déjà un rôle de fait. Il suffit de le voir.
- 02
Dans une banque, un analyste presque comme les autres
Sur un périmètre bancaire, plusieurs analystes présentent exactement les mêmes caractéristiques : même manager, même département, même établissement, même fonction, même ancienneté, mêmes applications. Une seule personne dans le groupe possède quelques accès supplémentaires. La discussion avec le responsable ne porte finalement pas sur les centaines d'habilitations communes. Elle porte uniquement sur cette différence. C'est une conversation courte, précise, qui aboutit à une décision claire — là où une revue exhaustive aurait produit une validation mécanique.
- 03
Dans une administration, deux agents au même poste
Dans une administration publique, deux agents occupent officiellement le même poste. Leurs habilitations diffèrent pourtant fortement. En analysant leur contexte, nous découvrons qu'ils interviennent pour deux autorités différentes, avec deux périmètres réglementaires distincts. La différence devient immédiatement compréhensible. Elle ne remet pas en cause l'intitulé du poste ; elle enrichit la manière de le décrire.
- 04
Une campagne de recertification qui reprend son sens
Lors d'une campagne de recertification, un manager reçoit plusieurs centaines d'habilitations à valider. En regroupant les identités par profils comparables, seules quelques situations sortent réellement du comportement attendu. La campagne cesse d'être un exercice administratif où l'on clique sur « approuver » jusqu'à épuisement. Elle devient un véritable outil d'aide à la décision, centré sur une poignée de cas où l'avis du manager change réellement quelque chose.
Aucune de ces situations n'a été résolue par la création d'un nouveau rôle. Chacune a été résolue en changeant la question posée à l'organisation.
Comment Netwrix Identity Manager sert cette approche
Nous utilisons régulièrement Netwrix Identity Manager, anciennement Usercube, sur ce type d'environnements. Ce qui nous intéresse dans la plateforme n'est pas d'abord son moteur de provisioning. C'est sa capacité à faire émerger les régularités que l'organisation produit déjà, et à concentrer l'attention humaine sur ce qui s'en écarte.
- Moteur de corrélation
- Le moteur de corrélation rapproche les identités qui partagent les mêmes caractéristiques structurantes — manager, département, fonction, établissement, société, cycle de vie. Il fait apparaître les groupes de pairs sans qu'un architecte ait à les décréter. C'est ce socle qui permet, ensuite, de raisonner en écart plutôt qu'en liste.
- Règles métier
- Les règles métier expliquent pourquoi certaines différences entre pairs sont légitimes. Un intérimaire peut ne pas avoir accès à une application que ses collègues salariés utilisent quotidiennement. Un agent affecté à une autorité particulière peut recevoir un droit supplémentaire. Ces règles ne sont pas des exceptions ; elles décrivent la mécanique réelle de l'organisation.
- Business Roles
- Les Business Roles ne sont pas une obligation systématique. Nous les créons lorsqu'un groupe de pairs mérite d'être nommé, gouverné, audité comme un objet à part entière. Nous ne les créons pas pour compléter un catalogue théorique. Un modèle de dix rôles bien formulés vaut mieux qu'un catalogue de cinq cents rôles que plus personne n'ose modifier.
- Technical Roles
- Les Technical Roles traduisent les Business Roles vers les applications. Cette traduction reste une décision humaine, validée par le responsable de l'application. Elle n'est jamais déduite automatiquement d'un cluster technique dont personne n'a assumé la définition métier.
- Campagnes de recertification
- Les campagnes de recertification s'appuient sur les régularités déjà identifiées. Un manager ne reçoit pas une liste plate d'habilitations. Il voit d'abord ce qui est cohérent avec les pairs de chaque identité, puis ce qui s'en écarte. Son attention se porte naturellement sur les écarts. La qualité de la validation augmente ; la fatigue diminue.
- Tableaux de bord
- Les tableaux de bord mettent en évidence les profils atypiques : une identité qui reçoit beaucoup plus d'accès que ses pairs, un rôle appliqué à un seul individu, une habilitation isolée persistante après un changement d'affectation. Ces signaux orientent le comité de gouvernance vers les décisions qui comptent, plutôt que vers un empilement d'indicateurs de volume.
L'attention humaine mérite mieux que les régularités
Une plateforme IGA mature ne demande pas aux managers de confirmer ce qui est déjà cohérent. Elle les aide à comprendre ce qui ne l'est pas. Nous constatons, projet après projet, que cette bascule change profondément la qualité des décisions rendues par les métiers.
La question posée aux managers cesse d'être « validez-vous ces trois cents habilitations ». Elle devient « pouvez-vous expliquer pourquoi cette personne se distingue de ses pairs ». La première n'appelle qu'une réponse mécanique. La seconde appelle un jugement. C'est ce jugement, réservé aux situations qui le méritent, qui fait la valeur d'une gouvernance des identités.
Cette approche n'est pas révolutionnaire. Elle ne prétend pas remplacer les Business Roles. Elle change simplement la place que nous leur donnons dans le projet. Le rôle vient nommer ce qui apparaît. Il ne vient plus imposer ce qui devrait être.
Comprendre l'organisation avant de la modéliser
Les projets IAM les plus efficaces que nous ayons menés ne sont pas ceux qui ont produit le plus grand nombre de rôles. Ce sont ceux qui permettent aux métiers de comprendre rapidement pourquoi une identité est cohérente avec ses pairs — ou pourquoi elle constitue une exception qui mérite une décision explicite.
Chez Ariovis, nous considérons que cette approche est devenue le standard des projets de gouvernance des identités menés depuis la période post-Covid. Les organisations bougent trop vite pour qu'un catalogue exhaustif tenu à la main reste réaliste. Les capacités de corrélation, de règles métier, de modélisation et de campagnes de recertification de Netwrix Identity Manager nous servent alors non pas à imposer un modèle théorique, mais à révéler les régularités que l'organisation produit déjà — et à laisser aux managers le temps de s'occuper des cas qui, eux, méritent vraiment leur attention.