IAM & IAG pour les architectes

Les architectes d’entreprise gagneraient à regarder l’IAM et l’IAG autrement que comme de simples sujets technologiques.

Si, dans la plupart des organisations, la gestion des droits reste cantonnée à des rôles ou à des profils, ce n’est certainement pas parce que c’est la meilleure approche, mais en raison de l’absence d’un modèle partagé du « qui fait quoi ». Faute d’un langage commun — compréhensible par tous les acteurs, y compris le métier — on est contraint de traduire des besoins opérationnels en artefacts techniques (rôles, profils) propres à chaque application.

Le référentiel d’architecture devrait être un actif décisif, parce qu’il décrit déjà les éléments structurants dont l’IAM et l’IAG manquent souvent : les applications, les populations d’utilisateurs, les objets de données et, surtout, les processus métier. Or, c’est précisément ce lien aux processus qui permet de dépasser une gouvernance centrée sur des droits techniques (groupes, rôles). Quand une règle d’accès s’aligne sur une étape de processus, un périmètre organisationnel et un objet métier, elle devient plus stable, plus compréhensible par le métier.

La connexion entre référentiel d’architecture et référentiel de règles d’accès serait d’ailleurs mutuellement bénéfique. Côté architecture, l’IAM/IAG apporte des informations trop rarement modélisées : modalités de provisioning des identités et des droits. Côté règles d’accès, l’architecture apporte des attributs de politique à forte valeur — niveaux de sensibilité des données, criticité applicative — qui permettraient de passer d’une gouvernance administrative à une gouvernance réellement pilotée par le risque.

Big ACL s’inscrit dans cette logique : un Policy Administration Point, où les règles sont exprimées en langage naturel pour faciliter la coopération entre sécurité, dev et métier.