L’IAM doit être utile avant d’être complet

Le problème IAM existe souvent avant le projet IAM

Pendant longtemps, ces opérations peuvent fonctionner correctement. Les RH préviennent l’IT, le support ouvre quelques comptes, un manager complète la demande et chacun connaît suffisamment bien l’organisation pour rattraper les exceptions. Un ticket, un fichier Excel ou quelques scripts ne sont pas en eux-mêmes des signes d’immaturité.

La difficulté apparaît quand ce fonctionnement devient le système de gestion des identités. Avec davantage de salariés, de sites, d’applications et de mouvements internes, chaque événement RH déclenche une succession d’actions dont la bonne exécution dépend de plusieurs personnes. Il devient difficile de savoir ce qui devait être fait, ce qui l’a réellement été et ce qui a été oublié.

C’est à ce moment qu’un sujet IAM apparaît, même si personne ne l’appelle encore ainsi. Le besoin n’est pas nécessairement de gouverner immédiatement tous les droits de l’entreprise, mais de rendre le cycle de vie des identités plus fiable.

Le point d’arrivée n’a pas à devenir le point de départ

L’IAM est souvent présenté par ses fonctions les plus avancées : rôles, recertifications, séparation des tâches, gouvernance des habilitations ou analyses de risque. Ces fonctions sont indispensables dans certains environnements et peuvent devenir nécessaires à mesure que l’organisation gagne en complexité.

Elles ne constituent pas pour autant le seul point de départ possible. Pour une entreprise qui traite encore manuellement une grande partie des arrivées et des départs, le premier progrès peut être plus simple : utiliser la RH comme source de référence, automatiser quelques opérations dans Active Directory ou Entra ID, standardiser les accès de base et fiabiliser les révocations.

Vouloir modéliser trop tôt l’ensemble des rôles, des exceptions et des responsabilités peut au contraire figer une organisation qui évolue encore. Il est souvent plus solide d’automatiser ce qui est déjà bien compris, puis d’enrichir progressivement la gouvernance à partir des situations réellement observées.

Commencer par peu de choses, mais les faire réellement

Commencer petit ne signifie pas installer une version dégradée d’un IAM plus ambitieux. Un bon premier périmètre est limité parce qu’il concentre l’effort sur des événements fréquents, répétitifs ou risqués.

Prenons l’arrivée d’un collaborateur. Il n’est pas nécessaire de déterminer automatiquement dès le premier jour l’ensemble des droits dont cette personne pourrait avoir besoin pendant toute sa carrière. On peut déjà récupérer une identité fiable depuis la RH, créer le compte au bon moment, appliquer quelques accès standards et laisser au manager les décisions qui ne peuvent pas encore être déduites de manière fiable.

La même logique s’applique aux départs. S’assurer qu’une date de fin RH provoque systématiquement les actions prévues constitue déjà un contrôle beaucoup plus robuste qu’une procédure dépendant d’un e-mail et de la mémoire d’un technicien. Les exceptions qui subsistent ne sont pas forcément un échec : elles permettent aussi de comprendre ce qui mérite réellement d’être standardisé ensuite.

Mesurer avant d’étendre

Un premier IAM devrait produire les arguments permettant de décider de la suite. Avant d’automatiser un flux, on peut compter les tickets concernés, le temps passé à les traiter, les relances, les délais et les erreurs. Les mêmes indicateurs peuvent être observés après le déploiement.

Cette approche évite de justifier l’IAM uniquement par un risque de sécurité difficile à quantifier. Elle évite aussi les business cases dans lesquels tous les bénéfices apparaissent à la fin d’un vaste programme.

Le HelpDesk est souvent l’un des premiers endroits où la valeur devient visible. Une création automatisée supprime une opération manuelle ; un départ déclenché depuis la RH réduit à la fois la charge du support et le risque de compte oublié. L’entreprise peut alors parler de son IAM en temps gagné, en délai de traitement, en fiabilité et en capacité à absorber sa croissance.

Automatiser ne sert pas uniquement à gagner du temps

Les mêmes mécanismes améliorent également le contrôle des accès. Lorsqu’un départ dépend d’un message envoyé au support, il est difficile de démontrer que toutes les actions attendues ont été réalisées. Avec un processus défini, on peut identifier ce qui devait arriver, constater les erreurs et conserver une trace exploitable.

Cette capacité devient particulièrement importante lorsqu’un client, un auditeur, un assureur ou une réglementation demande comment les accès sont gérés. Un IAM ne rend évidemment pas une entreprise conforme à NIS2 ou à une autre réglementation à lui seul, mais il peut rendre beaucoup plus démontrable une partie de son dispositif de maîtrise des accès.

La maturité ne se résume donc pas au nombre de fonctions disponibles. Une organisation capable d’expliquer clairement comment les identités sont créées, modifiées et supprimées possède déjà quelque chose de plus solide qu’une politique ambitieuse reposant encore sur des opérations informelles.

La conformité ne justifie pas automatiquement un projet gigantesque

Les exigences réglementaires et les questionnaires de grands clients donnent parfois l’impression qu’il faut immédiatement traiter toute la gouvernance des identités. En pratique, il faut d’abord traduire ces exigences en contrôles précis : gérer correctement le cycle de vie des comptes, limiter les accès inutiles, renforcer les droits sensibles et conserver les preuves nécessaires.

Certaines organisations devront aller beaucoup plus loin. Leur niveau de risque, leur taille, leur secteur ou leurs contraintes réglementaires peuvent imposer une gouvernance sophistiquée. Mais chercher à tout modéliser dès le départ n’apporte pas nécessairement plus de maîtrise, surtout lorsque les processus, les rôles ou les exceptions ne sont pas encore stabilisés.

Le bon niveau d’IAM dépend de ce qu’il faut réellement maîtriser aujourd’hui, avec suffisamment de structure pour pouvoir aller plus loin demain.

Ce que nous appelons un premier IAM

Un premier IAM ne se définit pas, selon nous, par une petite liste de fonctionnalités. Il se reconnaît au passage d’un fonctionnement largement artisanal à un cycle de vie plus maîtrisé.

L’organisation sait quelle source fait référence pour l’identité, ce qui doit se produire lors d’une arrivée, d’une mobilité ou d’un départ, quels accès peuvent être standardisés et quelles décisions restent humaines. Elle peut également identifier les exceptions et retrouver les opérations réalisées.

Ce socle n’empêche aucune ambition future. Il prépare au contraire les étapes suivantes avec des données plus fiables, des responsabilités mieux comprises et des résultats déjà observables. Les rôles, les recertifications ou une gouvernance beaucoup plus large peuvent ensuite être introduits lorsque le contexte les justifie.

Chez Mon premier IAM, nous ne défendons donc ni le plus petit projet possible, ni la simplicité pour la simplicité. Nous défendons le bon niveau d’IAM pour reprendre le contrôle maintenant, mesurer ce qu’il apporte et décider ensuite jusqu’où il mérite d’aller.