Le modèle d'habilitations est un modèle métier : pourquoi les droits d'accès décrivent l'organisation d'il y a dix ans

La campagne de revue des habilitations revient chaque année à la même période. Un responsable d’équipe reçoit un fichier : plusieurs centaines de lignes, une par droit, désignées par des codes applicatifs — GESCLI_CONS_N2, REF_ADM, EXP_COMPTA_RW. Il lui est demandé de confirmer, pour chacun de ses collaborateurs, que l’accès reste justifié. Il a deux semaines, et un métier à faire tourner par ailleurs.

Il valide tout. Ce n’est pas de la négligence : c’est la seule réponse disponible. On lui demande de se prononcer sur des objets techniques dont il ne connaît ni le périmètre exact ni ce qu’ils permettent réellement de faire. Retirer un droit à tort bloquera quelqu’un demain matin, et se remarquera dans l’heure. Le conserver ne produira aucune conséquence visible avant des années — et probablement jamais devant lui. Le rapport d’audit enregistre une campagne close à 100 %. Le mécanisme qui a produit ces centaines de lignes, lui, n’a pas été touché.

Cette scène est habituellement lue comme un problème d’exécution : mauvais outil, mauvaise ergonomie, managers peu impliqués. Elle est en réalité le symptôme d’un manque en amont. Un modèle d’habilitations est la traduction technique d’un modèle d’organisation. Quand ce modèle n’est écrit nulle part, chaque application invente le sien, et la seule description de « qui fait quoi » dont dispose l’entreprise devient la somme sédimentée de ses droits d’accès — c’est-à-dire une image fidèle de l’organisation telle qu’elle était il y a dix ans, corrigée par les urgences de la semaine dernière.

Le cliquet

Il faut commencer par l’asymétrie, parce qu’elle explique pourquoi le problème résiste aux bonnes volontés.

Le départ d’un collaborateur est plutôt bien traité. Il est daté, visible, porté par un processus qui existe : on rend le badge, on désactive le compte, quelqu’un signe. La mobilité interne, elle, n’a aucune de ces propriétés. La personne reste, son compte reste, son identité ne change pas — et rien, dans la chaîne d’événements, ne porte l’instruction « retirer ».

L’ajout, à l’inverse, est parfaitement outillé. Il a un demandeur — le nouveau responsable —, une urgence — la personne ne peut pas travailler —, un canal — le ticket —, et un délai de traitement suivi. Le retrait n’a rien de tout cela : personne ne le réclame, personne n’en tire un bénéfice personnel, et il porte un risque asymétrique. Ne rien faire ne se voit pas ; se tromper se voit immédiatement.

Chaque décision individuelle est donc rationnelle, et c’est leur somme qui produit le résultat. Les droits ne s’accumulent que dans un sens.

La conséquence est contre-intuitive, et mérite d’être énoncée telle quelle en comité : le profil le plus largement doté n’est ni le nouvel arrivant, ni le prestataire, mais le collaborateur de longue date qui a occupé quatre postes. L’exposition croît avec l’ancienneté, la polyvalence et la loyauté — exactement l’inverse de ce que la politique de sécurité prétend organiser. Et comme cette accumulation est répartie sur des milliers de personnes, elle n’apparaît sur aucun tableau de bord ; elle n’existe que dans le graphe complet, que personne ne regarde.

La revue annuelle ne corrige pas le mécanisme

La réponse habituelle à ce constat est la campagne de recertification. Elle échoue de façon reproductible, pour trois raisons distinctes qu’il vaut mieux séparer.

Elle demande une décision métier à partir d’objets techniques. Un responsable raisonne en situations : « cette personne instruit des dossiers, elle ne les valide pas ». Le fichier qu’on lui soumet parle profils, groupes et codes. Entre les deux, il manque une traduction — et l’absence de cette traduction est précisément le problème de fond, pas une gêne d’affichage.

Elle rejoue l’asymétrie qu’elle prétend corriger. Valider est gratuit et instantané ; refuser demande de vérifier, d’assumer, et éventuellement de débloquer quelqu’un en urgence trois jours plus tard. À contrainte de temps égale, la campagne sélectionne mécaniquement la validation en bloc.

Elle porte sur le stock alors que le défaut est dans le flux. C’est un contrôle détectif appliqué à un défaut de conception. Il peut faire apparaître un cas isolé ; il ne peut pas réduire une accumulation qui se reconstitue toute l’année à la vitesse des mobilités.

Rien de tout cela ne rend la revue inutile : elle répond à une obligation réelle et elle attrape des anomalies que rien d’autre n’attrape. Ce qui est faux, c’est de la considérer comme l’instrument de réduction du risque. C’est ce malentendu qui laisse le problème intact année après année, avec la satisfaction d’un indicateur au vert.

Trois inflexions rendent d’ailleurs une revue nettement plus utile, sans rien changer à sa périodicité. La première : présenter des rôles métier plutôt que des codes, quitte à ce que le périmètre exposé soit moins précis — un responsable qui comprend ce qu’il valide décide, un responsable qui ne comprend pas approuve. La deuxième : présenter les écarts plutôt que le stock — ce qui a changé depuis la dernière campagne, et ce qui n’est plus cohérent avec la situation actuelle de la personne. La troisième : confronter le droit à son usage. Un droit qui n’a pas été exercé une seule fois en douze mois n’a pas besoin d’être validé ; il a besoin d’être retiré. Et si le retrait est réversible en quelques minutes, cette décision cesse d’être risquée.

Trois choses différentes appelées « droit »

Sous le mot « habilitation » cohabitent trois objets dont la durée de vie naturelle n’a rien de commun.

Le rôle est attaché à un poste. Il est durable par nature, et sa fin est parfaitement définie : elle survient quand la personne quitte le poste. C’est le seul des trois qui puisse légitimement s’installer dans le temps.

La délégation est attachée à une circonstance : une absence, un intérim, un mandat temporaire. Sa fin est connue au moment même où elle est accordée — souvent à la date près.

L’élévation exceptionnelle est attachée à une opération : un incident, une migration, une reprise manuelle. Sa fin est encore plus nette : la clôture de l’opération.

Le problème n’est pas qu’on les confonde intellectuellement — la plupart des équipes les distinguent très bien à l’oral. C’est qu’elles passent toutes les trois par le même mécanisme d’octroi, et que ce mécanisme ne sait pas exprimer une durée. Il ne connaît qu’un verbe : accorder. Alors il accorde tout pour toujours.

La forme la plus coûteuse de cette confusion est le compte d’administration permanent. L’élévation, qui devrait être un état transitoire justifié par une opération, devient un attribut de la personne — souvent la même poignée de personnes, souvent celles qui sont indispensables partout, et dont le compte finit par ouvrir tout le système d’information sans qu’aucune décision n’ait jamais porté sur ce périmètre-là.

Où vit l’autorité

Vient alors la question proprement architecturale, qui n’est ni « quel outil » ni « quel référentiel », mais : qu’est-ce qui, dans le système d’information, fait autorité sur ce qu’une personne est aujourd’hui — son entité, son poste, son périmètre — et où cette information est-elle traduite en droits ?

Trois réponses coexistent dans la plupart des organisations, et elles ne se valent pas.

Dans chaque application. C’est la situation par défaut, y compris lorsqu’un annuaire central existe. Chaque application dispose de son écran de gestion des utilisateurs et de sa propre notion du métier : ce qu’elle appelle « gestionnaire » ne recouvre pas ce que la voisine appelle du même nom. Aucun événement ne se propage, parce qu’il n’y a rien à propager vers quoi que ce soit.

Dans un annuaire technique de groupes. C’est un progrès d’exécution, pas de sémantique. Un groupe nommé GRP_APP7_PROFIL3 ne dit rien d’une situation métier : on a centralisé le stockage des droits, pas la décision qui les fonde. L’organisation dispose alors d’un inventaire exact de droits qu’elle ne sait toujours pas interpréter.

Dans un modèle explicite. La situation de la personne — contrat, entité, poste, périmètre — alimente un rôle métier, et ce rôle est ce que les applications consomment. Le chaînon manquant, presque toujours, est celui du milieu.

Ce modèle a son propre mode d’échec, et il est fréquent : l’explosion des rôles. À force de vouloir couvrir chaque cas particulier, on crée un rôle par personne, et l’on reproduit l’attribution directe sous un vocabulaire plus flatteur. Une règle simple suffit à s’en prémunir : un rôle qui ne compte qu’un seul titulaire n’est pas un rôle, c’est une exception à laquelle on a donné un nom. Le modèle doit rester volontairement grossier — il couvre l’essentiel des situations, et l’écart résiduel se traite par des droits temporaires, pas par un rôle de plus.

Une distinction évite l’essentiel de cette dérive : séparer ce qu’une personne peut faire de ce sur quoi elle peut le faire. Le rôle exprime la première ; l’agence, le portefeuille, l’entité juridique ou le pays expriment la seconde. Confondre les deux multiplie mécaniquement le nombre de rôles par le nombre de périmètres, et c’est ainsi qu’un modèle de vingt rôles devient un catalogue de six cents. Le périmètre est une donnée portée par la personne, pas un rôle supplémentaire.

Reste un point rarement instruit : qui a le droit de définir un rôle métier ? Les profils livrés en standard avec un progiciel constituent un modèle d’organisation — celui du produit, hérité de ses autres déploiements. Les adopter tels quels, sans les confronter à la séparation des tâches réellement voulue par l’entreprise, revient à laisser un tiers décrire l’organisation. C’est un arbitrage parfaitement acceptable lorsqu’il est conscient ; il l’est rarement.

Ce qui rend un droit révocable

Un droit devient révocable au moment où il est accordé, pas au moment où l’on cherche à le retirer. La condition de fin doit donc être écrite avec l’octroi, sous l’une de ces trois formes seulement.

L’expiration : une date, au-delà de laquelle le droit disparaît sans qu’aucune décision ne soit nécessaire. C’est la forme naturelle des délégations et des élévations.

Le rattachement : le droit n’est pas accordé, il est dérivé d’une situation, et il disparaît avec elle. C’est la forme naturelle des rôles — et la seule qui rende une mobilité automatiquement propre.

La révision : à défaut des deux précédentes, une date à laquelle la question sera réexaminée, avec un porteur nommé.

Un droit qui ne relève d’aucune des trois est un engagement perpétuel que personne n’a validé, et que tout le monde paiera — en surface exposée, en charge de revue, et en incapacité à répondre à la question « qui peut faire ceci ? » le jour où elle sera posée sérieusement.

Deux catégories échappent presque toujours à ce cadre, et ce sont les plus sensibles.

Les comptes non humains. Intégrations, robots, comptes de service, connecteurs. Ils sont souvent les plus privilégiés du système d’information, et ils n’ont ni mobilité, ni départ, ni responsable hiérarchique : aucun événement du cycle de vie des personnes ne déclenche leur révision. Ils sont fréquemment partagés entre plusieurs usages, ce qui rend impossible de savoir ce que l’on casse en les restreignant — et suffit à interdire toute réduction. Le minimum praticable tient en trois exigences : un propriétaire nommé qui soit une personne et non une équipe, un usage documenté, et l’interdiction d’un compte partagé entre deux intégrations. Cette dernière règle n’a l’air de rien ; c’est elle qui rend le droit divisible plus tard.

Les privilèges d’administration. La distinction utile n’est pas entre administrateurs et utilisateurs, mais entre le droit d’élever ses privilèges et l’état élevé. Une élévation demandée, motivée, bornée dans le temps et tracée coûte peu à mettre en place et fait disparaître la catégorie la plus dangereuse du parc : le compte puissant, dormant, dont plus personne ne se souvient.

Enfin, la séparation des tâches — qui saisit ne valide pas, qui commande ne réceptionne pas — est une exigence métier, pas une contrainte d’outil. Exprimée en profils applicatifs, elle est perdue au premier changement de progiciel. Exprimée en rôles métier, elle survit aux applications qui l’implémentent, et elle peut être vérifiée à travers elles.

Ce que l’architecture doit tenir

Le rôle de l’architecture n’est pas d’administrer les droits. Il est de faire exister le modèle sans lequel personne ne peut décider.

Cela suppose de traiter le modèle de rôles comme un artefact d’architecture d’entreprise à part entière — dérivé des capacités métier et des processus, maintenu dans la durée par l’organisation, et non produit une fois par un projet qui se termine. Cela suppose aussi d’exiger de toute nouvelle application qu’elle consomme ce modèle plutôt que d’en instituer un de plus : exigence qui doit être pondérée dans les critères de choix, faute de quoi elle n’existe pas. Cela suppose enfin de déplacer la révision du calendrier vers l’événement : la mobilité, la fin de mission, la clôture d’incident sont les seuls moments où le retrait est à la fois légitime et gratuit. Une campagne annuelle arrive toujours trop tard pour être autre chose qu’un constat.

Les indicateurs suivent la même logique, et aucun d’eux n’exige un outil particulier pour être produit. Combien de droits comportent une condition de fin, sous l’une des trois formes ? Combien de personnes détiennent encore des droits attachés à un poste qu’elles n’occupent plus ? Combien de comptes techniques ont un propriétaire nommé, et combien sont partagés entre plusieurs usages ? Quel est le rapport entre le nombre de rôles définis et le nombre de postes réels — un rapport proche de un signale un modèle qui n’en est pas un ? Et le plus honnête, celui qui résume tous les autres : combien de droits ont été retirés cette année, comparé à combien ont été accordés ?

Ce qui ne relève pas de l’architecture mérite d’être dit aussi nettement : le choix de l’outil de gestion des identités. Un outil déployé sur un modèle inexistant automatise l’accumulation ; il la rend simplement plus rapide, mieux tracée et plus difficile à défaire.

Le document que personne n’a écrit

Il existe dans toute organisation un document qui décrit exactement qui a le droit de faire quoi. Il n’a pas d’auteur, il n’a jamais été validé, il enregistre fidèlement toutes les urgences des quinze dernières années, et personne ne l’a jamais lu : c’est la table des habilitations.

Tant qu’il reste le seul, l’organisation continue de se décrire par sédimentation, et ce sont les décisions les plus anciennes et les plus mal instruites qui font foi. Écrire le modèle ne coûte presque rien tant que les droits n’ont pas encore été distribués — c’est une question de conception, quelques dizaines de rôles et une règle de fin. Le reconstituer à partir de ce qui a déjà été accordé est un programme, et c’est le prix ordinaire d’une décision d’architecture prise avec dix ans de retard.