Tu dois récupérer l'IAM en tant que RSSI, les identités c'est aussi de la cybersécurité !

Quand le COMEX valide, mais que personne ne s’approprie : comment cadrer l’IAM, obtenir des quick wins (SSO/JML)

Contexte

Cette année, le COMEX a enfin compris que l’IAM n’était pas un sujet technique de plus, mais un pilier de la cybersécurité. Pour moi, ça a été un mélange de soulagement et d’agacement. Soulagement, parce que le message passe enfin. Agacement, parce que cela fait des années que les identités posent problème, dans l’ombre, sans jamais être traitées à la hauteur des risques réels.

Les propositions de remédiation ont été bien accueillies par le COMEX et le CODIR DSI. Trop bien, presque. Présentations claires, plans structurés, priorités assumées : tout le monde acquiesce. À ce moment-là, on te regarde comme celui qui va “prendre l’IAM”. Et intérieurement, le piège apparaît clairement : validation ne veut pas dire appropriation.

Très vite, le constat s’impose : tu es le seul à vraiment comprendre l’IAM. Pas par ego, mais par réalité terrain. Les équipes voient des outils, des tickets, des workflows. De ton côté, tu vois les chaînes d’identité, les dépendances, les angles morts. Progressivement, l’IAM devient ton sujet. Celui que tout le monde te renvoie, parce que c’est plus simple que de s’en saisir collectivement.

Problème

La bande passante d’un RSSI est déjà saturée. Vulnérabilités, incidents, conformité, fournisseurs, audits, comités… tout arrive en même temps. Ajouter l’IAM à la pile, c’est nécessaire, mais coûteux. Car l’IAM n’est pas un petit chantier : c’est long, ingrat, et chronophage. Le prendre “en plus”, sans arbitrage clair, mène rapidement à l’épuisement.

L’IAM dépasse largement la cybersécurité. C’est un sujet transverse, profondément organisationnel. Il touche les métiers, l’IT, les RH, parfois la finance. Chaque décision impacte des usages, des habitudes, des équilibres internes. Très vite, tout remonte vers le RSSI : arbitrages, conflits, exceptions. On part d’un sujet d’identités, on se retrouve à gérer des frictions structurelles.

Et la question finit par surgir, frontalement : jusqu’où aller ? Où s’arrêter ? À partir de quand ce n’est plus le rôle du RSSI ? L’IAM peut absorber des mois entiers si aucune limite n’est posée. Plus on avance, plus on en demande. Sans cadre clair, la remédiation IAM devient un puits sans fond, et le RSSI glisse vers un rôle de “responsable IAM par défaut”, au détriment de sa posture stratégique.

Étapes

1. Accepter d’initier, pas d’exécuter
   La première étape consiste à poser une règle simple : le RSSI initie et cadre, mais n’exécute pas à la place des autres. Les actions opérationnelles doivent être portées par les équipes métiers et IT concernées. Ce n’est ni une fuite ni un désengagement, c’est une condition de survie. Sans cette ligne rouge, le RSSI devient rapidement le point de blocage de toute l’organisation.

2. Cartographier l’IAM réel, pas celui des slides
   Il faut ensuite mettre les choses à plat. Cartographier l’IAM tel qu’il existe réellement : briques en place, manques, contournements, héritages historiques. Cet exercice est souvent inconfortable, car il met en lumière des incohérences accumulées dans le temps. Mais sans cette cartographie honnête, toute discussion sur la remédiation repose sur une illusion.

3. Lister les applications sous SSO et hors SSO, avec leur criticité
   L’inventaire des applications révèle souvent la vraie dette. Applications critiques hors SSO, mots de passe partagés, comptes génériques, accès jamais revus. Classer ces applications par criticité devient indispensable, mais aussi politiquement sensible. Chaque application non intégrée raconte une histoire de compromis passés. Et plus la liste s’allonge, plus il devient clair que l’IAM est un héritage organisationnel mal digéré.

4. Formaliser une fiche de mise sous SSO avec M365 / Azure AD
   À ce stade, il faut passer au concret. Avec le responsable M365 qui gère Azure AD, une fiche simple de mise sous SSO est formalisée : prérequis, impacts, responsabilités, délais réalistes. Cet outil évite les débats sans fin et sert de filtre objectif. Chaque application candidate au SSO passe par ce cadre. Cela ne règle pas tout, mais cela remet de la discipline.

5. Sensibiliser sans moraliser
   La sensibilisation n’a pas vocation à donner des leçons. L’objectif est de reconnecter les équipes métiers et IT à la réalité opérationnelle. Le SSO est présenté comme un levier : moins d’incidents, moins de friction, moins de charge inutile. En parlant d’usages et d’impacts concrets, l’adhésion est plus naturelle. Et surtout, cela évite de transformer l’IAM en combat idéologique.

6. Suivre l’exécution dans la durée
   Sans suivi, le SSO reste une bonne intention. Le rôle du RSSI est d’assurer la continuité : relances, arbitrages, clarification des blocages. Ce n’est pas spectaculaire, mais c’est déterminant. Chaque application mise sous SSO est une victoire silencieuse. Chaque report non traité recrée de la dette. L’IAM progresse rarement par grands plans, mais par une accumulation de pas tenus dans le temps.

7. Travailler les processus JML : Joiner, Mover, Leaver
   Enfin, il faut attaquer le cœur du problème : les processus JML, c’est-à-dire l’entrée, la mobilité et la sortie des collaborateurs. Comptes créés trop tôt, supprimés trop tard, droits jamais ajustés lors des mutations internes. Rien de spectaculaire, mais une accumulation de risques silencieux. Sans JML clair, la dette d’identités se reconstitue en permanence, quels que soient les efforts réalisés ailleurs.

Recommandations

1. Sur l’IAM, tout ne peut pas être porté par une seule fonction. Le sujet est tentant car il touche à de nombreux domaines connexes, mais le risque est réel de diluer le rôle du RSSI. L’enjeu consiste à poser un cadre clair, identifier les responsabilités et s’assurer que chaque équipe prenne sa part. Cette capacité à structurer et déléguer est essentielle pour rester efficace dans la durée.

2. Chercher des quick wins est souvent plus efficace que viser d’emblée la perfection. Le SSO, la MFA ou les revues d’accès périodiques apportent des bénéfices rapides et visibles. Ces victoires installent une dynamique positive et montrent que l’IAM peut produire de la valeur sans devenir un chantier interminable. Elles créent aussi la confiance nécessaire pour aborder ensuite des sujets plus profonds.

3. L’IAM gagne à être expliqué comme un socle. Sensibiliser les équipes métiers et IT consiste à montrer les impacts concrets : incidents évités, accès simplifiés, réduction des frictions. Lorsqu’il est compris comme un facilitateur de la cybersécurité globale, l’IAM s’inscrit plus naturellement dans les pratiques quotidiennes, au-delà des projets ponctuels.

Conclusion

L’IAM est un sujet central, mais aussi l’un des plus piégeux pour un RSSI. Parce qu’il touche à tout, il peut vite devenir envahissant et détourner de la vision stratégique attendue du rôle. La valeur du RSSI ne réside pas dans l’exécution de chaque remédiation IAM, mais dans sa capacité à cadrer, prioriser et faire travailler l’organisation ensemble. Aider, impulser, structurer : oui. Tout porter soi-même : non. Poser ces limites n’est pas un renoncement, c’est une condition pour rester efficace et crédible dans la durée.

👉 N’hésitez pas à nous contacter pour discuter de votre projet cybersécurité ou pour obtenir des informations supplémentaires sur Cyberlead.

Si l’article vous a plu, n’hésitez pas à le faire circuler dans votre réseau : un simple partage nous aide beaucoup.