Identity, SSO et sécurité : ce qui était souhaitable est devenu éliminatoire

Image générée avec Nano Banana

Pour les équipes qui livrent des plateformes digitales pour des clients grands comptes, un changement de fond est en cours — et il arrive plus vite qu’elles ne le pensent.

L’onde de choc ISO 27001

Il y a un phénomène que j’ai observé directement en tant que prestataire : quand un client grand compte engage une démarche de certification ISO 27001, ce n’est pas seulement son organisation interne qui est auditée. Ce sont aussi ses prestataires.

J’ai participé au renforcement de nos pratiques de sécurité pour passer un audit organisationnel poussé, imposé par un client dont la démarche de certification créait des exigences en cascade sur l’ensemble de sa chaîne de valeur. Pas de négociation possible. Pas de dérogation. Vous êtes conformes, ou vous n’êtes plus dans l’équation.

C’est la mécanique que beaucoup d’équipes n’ont pas encore intégrée.

L’ISO 27001 n’est pas qu’une certification interne. C’est un signal envoyé au marché : “nous prenons la sécurité au sérieux, et nous attendons la même chose de ceux avec qui nous travaillons.” Les grands comptes certifiés construisent progressivement des écosystèmes de confiance — et ils vont, à terme, n’y admettre que les partenaires qui satisfont à leurs exigences.

Ce qui était une bonne pratique recommandée en 2024 est devenu une exigence contractuelle en 2026. Et ce mouvement ne va pas s’inverser.

Pourquoi l’identity est au cœur du sujet

Parmi toutes les dimensions de la sécurité qu’une certification ISO 27001 adresse — politique de gestion des accès, traçabilité, cloisonnement des données, gestion des incidents — l’identity management occupe une place centrale. Et pour une raison simple : l’identity est le nouveau périmètre de sécurité.

Dans un monde où les applications sont dans le cloud, les utilisateurs en remote, et les données distribuées sur plusieurs plateformes SaaS, le réseau ne constitue plus une frontière défendable. Ce qui reste, c’est l’identité. Qui est cet utilisateur ? A-t-il le droit d’accéder à cette ressource ? Son accès peut-il être révoqué instantanément si nécessaire ?

Ces questions, une webapp sans SSO ne peut pas y répondre correctement.

Sans authentification centralisée, chaque application gère ses propres comptes, ses propres mots de passe, ses propres sessions. Quand un collaborateur quitte l’entreprise, son accès doit être révoqué manuellement sur chaque plateforme — et il ne l’est pas toujours. Quand un compte est compromis, il n’y a pas de point de contrôle unique pour couper l’accès. Quand un auditeur demande la liste des personnes ayant accédé à telle ressource sur les six derniers mois, il n’y a pas d’audit trail exploitable.

C’est exactement ce qu’une certification ISO 27001 vient auditer. Et c’est exactement ce qu’un grand compte certifié va exiger de ses prestataires.

L’argument qui débloque les décisions

Pour convaincre des décideurs sur ce sujet, le bon choix n’est pas de commencer par les arguments techniques — pas par les protocoles, pas par les architectures, pas par les standards. Mais par l’argument qui fait bouger les organisations : le risque de perdre du business.

Les risques liés à une mauvaise gestion de la sécurité sont multiples — financiers, réputationnels, légaux, judiciaires. Mais dans une salle de direction, c’est le risque financier qui déverrouille l’attention. Personne ne veut perdre un contrat grand compte parce que sa plateforme ne peut pas s’intégrer au système d’identity du client. Personne ne veut être exclu d’un appel d’offres parce que la question “votre plateforme supporte-t-elle le SSO avec notre Azure AD ?” reçoit comme réponse un silence embarrassé.

Et c’est exactement ce qui va se passer. Pas dans dix ans. Dans les prochains mois, pour les équipes qui n’ont pas encore agi.

Les grands comptes certifiés ISO 27001 vont progressivement poser le SSO comme prérequis — au même titre qu’ils posent aujourd’hui des exigences sur la localisation des données ou la politique de sauvegarde. Ce n’est pas une tendance. C’est une transition déjà en cours.

Ce que “faire le nécessaire” veut dire concrètement

La bonne nouvelle, c’est que les fondations existent. Les protocoles sont matures, les outils sont disponibles, et les patterns d’architecture sont éprouvés.

OIDC et SAML2 — les deux protocoles à connaître

OpenID Connect (OIDC) et SAML2 sont les deux protocoles qui structurent l’écosystème SSO. Ils ne sont pas concurrents — ils sont complémentaires. OIDC est le protocole moderne, pensé pour les applications web et mobile, léger, basé sur OAuth2. SAML2 est le protocole historique de l’enterprise, encore dominant dans les grandes organisations et indispensable pour s’intégrer aux IdP d’entreprise comme Azure AD ou Google Workspace.

Une plateforme qui prétend supporter le SSO doit être capable de parler les deux langues.

La réalité des IdP grands comptes

Dans la quasi-totalité des grands comptes, l’infrastructure d’identity est déjà en place. Azure Active Directory chez les organisations Microsoft, Google Workspace chez les organisations Google-first, parfois Okta ou PingFederate dans les environnements plus hétérogènes. Ces organisations n’ont aucune intention de créer des comptes supplémentaires dans vos plateformes — elles veulent fédérer leurs identités existantes.

Concrètement, cela signifie que votre plateforme doit être capable de déléguer l’authentification à leur IdP, de recevoir les assertions d’identity en retour, et de mapper les rôles et permissions en conséquence. Ce n’est pas trivial — mais c’est faisable, et c’est non négociable.

Ce que l’absence de SSO coûte réellement

Au-delà de la conformité, l’absence de SSO a un coût opérationnel direct que les décideurs sous-estiment :

• Gestion des accès en silo — chaque application a sa propre base d’utilisateurs, ses propres règles de mot de passe, ses propres processus d’onboarding et d’offboarding
• Surface d’attaque élargie — chaque compte supplémentaire est un vecteur d’attaque potentiel, chaque mot de passe stocké est un risque
• Absence d’audit trail centralisé — impossible de répondre proprement à “qui a accédé à quoi et quand” sans consolider des logs disparates
• Révocation non fiable — quand un collaborateur quitte, combien de plateformes oublie-t-on de mettre à jour ?

Ces coûts sont invisibles jusqu’au moment où ils deviennent des incidents.

Les décisions d’architecture qu’on ne peut plus éviter

Intégrer le SSO dans une plateforme n’est pas une décision qu’on prend à la fin du projet. C’est une décision d’architecture qui impacte la façon dont on gère les sessions, les permissions, les rôles, et les données utilisateur dès la conception.

Quelques questions à poser dès le cadrage :

Qui est l’IdP de référence ? Si le client a déjà Azure AD ou Google Workspace, la réponse est simple : vous vous fédérez à son IdP. Si la plateforme est multi-clients, il faut prévoir une couche d’abstraction — un IdP intermédiaire comme Keycloak — capable de fédérer plusieurs IdP clients derrière une interface unifiée.

Comment gérez-vous les rôles et permissions ? Le SSO gère l’authentification — “qui est cet utilisateur ?” — mais pas nécessairement l’autorisation — “qu’a-t-il le droit de faire ?“. Le mapping entre les groupes de l’IdP client et les rôles de votre application est un sujet à part entière, qui doit être conçu explicitement.

Comment gérez-vous la révocation ? Le SSO permet la révocation centralisée — si l’IdP révoque l’accès d’un utilisateur, toutes les applications fédérées doivent en être informées. Cela implique de gérer correctement les durées de vie des tokens et les mécanismes de logout global (SLO — Single Logout).

Comment gérez-vous les environnements multi-IdP ? Dans un contexte grand compte avec plusieurs entités, filiales ou partenaires, il est fréquent d’avoir plusieurs IdP à fédérer. C’est un cas de figure qui se prépare dès la conception — pas qu’on ajoute après coup.

Ce qui a changé en 2026

Je veux être précis sur ce que j’entends par “éliminatoire”.

Ce n’est pas que tous les clients grands comptes exigent aujourd’hui formellement le SSO dans leurs cahiers des charges. La transition est plus progressive — et c’est exactement ce qui la rend dangereuse. Les exigences montent par paliers : d’abord une question lors d’un audit, puis une clause dans un contrat de renouvellement, puis un prérequis dans un appel d’offres.

Les équipes qui attendent le signal explicite seront en retard. Parce que quand le signal explicite arrive — “votre plateforme doit supporter le SSO avec notre Azure AD pour que nous puissions renouveler le contrat” — il reste peu de temps pour faire les choses correctement.

L’identity management bien fait n’est pas une feature qu’on ajoute en trois sprints. C’est une décision d’architecture qui se répercute sur la gestion des sessions, la structure des permissions, la politique des tokens, les logs d’accès, et la façon dont on gère le cycle de vie des utilisateurs. On peut le faire vite et mal — et créer de nouveaux risques de sécurité. Ou on peut le faire correctement, ce qui prend du temps et nécessite une vraie décision de priorité.

Ce temps, les équipes qui n’ont pas encore commencé ne l’ont plus en abondance.

Ce que j’ai retenu

Livrer des plateformes pour des clients grands comptes, c’est opérer dans un environnement où la sécurité n’est pas un argument de vente — c’est une condition d’exercice.

Ce que j’ai retenu de ces expériences : l’adhésion ne suffit pas. Pour débloquer des moyens, il faut chiffrer le risque en termes que les décideurs comprennent. Pas en termes de CVE ou de vecteurs d’attaque — en termes de contrats perdus, de clients qui ne renouvellent pas, d’appels d’offres auxquels on ne peut plus répondre.

Le message que je porte depuis : la sécurité est passée de critère de qualité à critère d’accès au marché. Ce n’est plus “est-ce que notre plateforme est suffisamment sécurisée ?” C’est “est-ce que notre plateforme peut opérer dans l’écosystème de nos clients ?”

Pour les équipes qui n’ont pas encore répondu à cette question : c’est le bon moment. Pas parce qu’une attaque est imminente. Parce que le marché grand compte est en train de se refermer sur ceux qui n’ont pas fait leur mise à niveau — et il se referme silencieusement, un contrat à la fois.

Guillaume P. est Engineering Manager, spécialisé dans la livraison de plateformes digitales cloud-native pour des clients grands comptes. Il écrit sur la sécurité, l’identity management et l’architecture cloud.