Une identité n'est presque jamais décrite par une seule source
Sur les grands systèmes d'information que nous accompagnons, aucun projet n'a jamais commencé avec un référentiel unique capable de décrire parfaitement chaque personne. Les projets qui réussissent ne sont pas ceux qui trouvent cette source ; ce sont ceux qui acceptent qu'elle n'existe pas.
Une demande qui commence par un aveu
Un directeur des systèmes d'information nous reçoit un matin, dossier posé devant lui, et pose la question qui revient dans presque toutes nos premières réunions. « Nous voulons lancer un projet IGA, mais nos données ne sont pas suffisamment fiables. Il faut d'abord que nous fassions le ménage. » L'organisation compte plusieurs dizaines de milliers d'identités, plusieurs centaines d'applications, plusieurs Active Directory, un Entra ID en pleine consolidation et trois SI RH qui coexistent depuis une fusion.
La conviction du sponsor est nette. Tant que les données ne sont pas parfaites, le projet ne peut pas commencer. Ce raisonnement, nous l'entendons depuis quinze ans. Il paraît de bon sens. Il est pourtant la première chose que nous cherchons à défaire.
Nous ne commençons jamais un projet de gouvernance des identités par un chantier de nettoyage massif. Nous commençons par comprendre comment l'entreprise s'est organisée pour décrire ses identités. Quelles populations elle distingue, dans quels référentiels elle les inscrit, quelles règles implicites structurent leur cycle de vie. Cette étape s'appelle rarement autrement que « ateliers », et pourtant c'est là que se joue la réussite du programme.
Ce que nous découvrons, systématiquement, c'est que l'organisation dispose déjà de tout ce qu'il faut pour se gouverner. Simplement, cette connaissance est répartie entre plusieurs équipes, plusieurs systèmes, plusieurs générations d'outils. Elle n'a jamais été mise à plat.
L'identité de l'entreprise est naturellement distribuée
Dans les grandes organisations françaises et européennes, les différentes populations ne sont pas gérées dans un référentiel unique. Ce n'est pas un défaut d'architecture. C'est une conséquence de l'histoire de l'entreprise, de son organisation et de ses obligations. Le SI RH pilote les salariés parce que la paie et le contrat de travail imposent une source de confiance dédiée. Les Achats, ou un outil de gestion des fournisseurs, pilotent souvent les prestataires. Les partenaires disposent de leurs propres référentiels, parfois hébergés chez eux. Les intérimaires viennent d'une agence. Les comptes techniques ne proviennent d'aucune source RH. Les comptes de service naissent dans les projets, et parfois ne meurent plus.
Certaines populations sont volontairement séparées, pour distinguer clairement les collaborateurs internes des intervenants externes. Cette séparation répond à des contraintes de contractualisation, de gouvernance et d'audit. Nous n'entrons jamais dans l'analyse juridique — ce n'est pas notre métier — mais nous constatons que cette séparation est une réalité fréquente, et souvent choisie.
L'identité de l'entreprise est donc naturellement distribuée. Chercher à la rassembler dans un unique référentiel « source de vérité » revient à demander à l'organisation de se réécrire elle-même pour satisfaire un modèle théorique. Ce n'est ni réaliste ni souhaitable. Un projet IGA doit accepter que la description d'une personne se compose de plusieurs fragments, chacun porté par un système différent, chacun légitime dans son périmètre.
Quatre situations, la même mécanique
Quelques scènes rencontrées récemment dans plusieurs missions, sous des formes voisines. Chacune, prise seule, ressemble à un cas particulier. Prises ensemble, elles décrivent une constante.
- 01
Une personne, deux existences officielles
Un salarié rejoint une filiale à la suite d'une réorganisation. Le SI RH central le déclare partant ; le SI RH de la filiale le déclare arrivant. Pendant plusieurs semaines, cette personne existe deux fois, avec deux matricules, deux managers, deux dates d'entrée. Aucun des deux systèmes ne se trompe. Chacun raconte une partie de la réalité contractuelle. Le moteur d'identité doit être capable de représenter cette double existence sans en supprimer une pour faire propre.
- 02
Une transition qui dure
Une responsable change de fonction. Elle conserve pendant plusieurs mois certaines habilitations de son ancien poste, le temps d'assurer une transition, de terminer un dossier réglementaire, de former son successeur. Sur le papier, elle n'exerce plus l'ancien rôle. En pratique, elle en garde légitimement les responsabilités. Une gouvernance qui applique brutalement le changement d'affectation crée un incident opérationnel. Une gouvernance qui l'ignore crée un écart de conformité. Aucun des deux n'est acceptable.
- 03
Un prestataire connu de plusieurs sources
Un consultant intervient pour deux directions différentes, sous deux contrats gérés par deux acheteurs différents. Il apparaît deux fois dans l'outil de gestion des fournisseurs, deux fois dans les habilitations, avec deux adresses de messagerie créées à quelques semaines d'écart. C'est bien la même personne. Aucun système ne le sait, parce qu'aucun système n'a été conçu pour croiser deux contrats commerciaux et une identité humaine.
- 04
Un compte de service qui ne relève de personne
Une application métier utilise depuis dix ans un compte technique dont le propriétaire officiel a quitté l'entreprise. Le compte fonctionne. Personne n'y touche. Il n'apparaît dans aucun référentiel RH, ce qui est normal, mais il n'apparaît pas non plus dans un référentiel d'identités non-humaines, ce qui l'est moins. Il existe simplement dans l'annuaire, comme un fait acquis.
Aucune de ces situations n'est une erreur de saisie. Toutes correspondent à un fonctionnement normal de l'organisation. Un projet IGA qui refuse d'en tenir compte finit par se battre contre son propre client.
Comment Netwrix Identity Manager modélise cette réalité
Nous utilisons régulièrement Netwrix Identity Manager, anciennement Usercube, sur ce type d'environnements. Ce qui nous intéresse dans cette plateforme n'est pas d'abord son moteur de provisioning — beaucoup d'outils savent provisionner. C'est sa capacité à représenter une identité comme une agrégation de fragments issus de plusieurs sources, sans forcer l'organisation à choisir une source dominante.
- Identity Warehouse
- L'Identity Warehouse ne se contente pas de consolider les identités. Il conserve la provenance de chaque attribut. Nous savons à tout moment que le matricule vient du SI RH principal, l'adresse de messagerie de l'Active Directory, le manager fonctionnel d'un référentiel projet, la date de fin de contrat de l'outil fournisseurs. Cette traçabilité est ce qui rend possible la modélisation d'une identité distribuée.
- Moteur de corrélation
- Le moteur de corrélation rapproche plusieurs représentations d'une même personne — un salarié inscrit deux fois pendant une bascule, un prestataire connu de deux directions, un partenaire ayant deux contrats. Nous configurons ces règles avec les métiers, pas contre eux. Une correspondance qui n'est pas comprise par une direction RH ou par les Achats est une correspondance qui finira par être défaite en production.
- Policy Engine
- Le Policy Engine encode les règles de gestion que l'organisation a fini par accepter d'écrire. Il n'invente pas la gouvernance. Il la rend exécutable. C'est aussi le composant qui gère les périodes de recouvrement — une identité qui hérite temporairement de deux affectations, un manager qui reste responsable pendant une transition, une habilitation conservée le temps d'une passation.
- Business Roles
- Les Business Roles décrivent l'organisation métier telle qu'elle se pense elle-même : par direction, par fonction, par famille de métier. Ils ne sont pas déduits des groupes techniques ; ils sont formulés par les métiers puis confrontés aux données. C'est cette confrontation qui fait apparaître les écarts entre l'organisation officielle et l'organisation réelle.
- Technical Roles
- Les Technical Roles traduisent les Business Roles vers le langage des applications. Cette traduction reste une décision humaine, jamais un automatisme. Nous refusons de créer un Technical Role qu'un responsable applicatif n'a pas explicitement validé.
- Campagnes de recertification
- Les campagnes de recertification ne sont pas seulement un instrument de conformité. Ce sont un moyen d'améliorer progressivement la qualité des données, campagne après campagne. Chaque itération réduit les écarts entre les référentiels et affine la définition des rôles. La qualité des données devient un résultat du projet IAM, pas son prérequis.
- Tableaux de bord
- Les tableaux de bord mettent en évidence les écarts entre les référentiels et les écarts entre les référentiels et le terrain. Ils ne cherchent pas à masquer les incohérences ; ils les rendent lisibles. C'est ce qui permet à un comité de gouvernance de décider où porter l'effort en priorité.
La question que nous posons vraiment
Nous ne demandons presque jamais « où est votre source de vérité ». Nous demandons « quelles sources décrivent chacune une partie de la réalité, et quelles règles permettent de les recomposer ». Cette formulation change la nature de tous les ateliers qui suivent.
Elle libère les équipes du sentiment qu'il faudrait d'abord tout réparer avant de commencer. Elle reconnaît que le SI RH a raison sur ce qu'il gère, que les Achats ont raison sur ce qu'ils gèrent, que l'annuaire technique a raison sur ce qu'il gère, et que la difficulté n'est pas de trancher entre eux mais d'écrire les règles qui les relient.
C'est cette écriture des règles — parfois une phrase, parfois un tableau, parfois un schéma — qui devient la vraie livraison des premiers ateliers. Sans elle, aucune plateforme, aussi puissante soit-elle, ne produit une gouvernance durable. Avec elle, une plateforme comme Netwrix Identity Manager trouve son rôle exact : un moteur qui exécute une modélisation partagée, pas un outil qui la remplace.
Modéliser des sources imparfaites, pas chercher la source parfaite
La réussite d'un projet IAM ne dépend pas de l'existence d'une source parfaite. Elle dépend de la capacité de l'organisation à comprendre les règles de gestion qui relient plusieurs sources imparfaites. Nous n'avons jamais rencontré, en quinze ans, une entreprise disposant d'un référentiel unique décrivant fidèlement chacune de ses identités. Nous avons rencontré, en revanche, beaucoup d'organisations qui ont fini par admettre que cette source n'existait pas — et dont le projet a alors pu commencer.
C'est précisément cette philosophie qui explique pourquoi nous utilisons Netwrix Identity Manager comme un moteur de modélisation de l'organisation avant d'en faire un moteur d'automatisation. La plateforme sert d'abord à représenter la manière dont l'entreprise se pense, se contracte et se responsabilise. L'automatisation vient ensuite, et elle vient plus vite qu'on ne le croit lorsque le travail de modélisation a été fait sérieusement.