Le jour où un client vous demande le SSO : la feature qui décide quels grands comptes vous pourrez signer

Un de vos plus gros prospects est enthousiaste. Le produit répond au besoin, le pilote s’est bien passé, la négociation avance. Puis, dans le questionnaire de sécurité de leur DSI, une ligne : « Authentification SSO via SAML obligatoire ». Vous répondez « oui, c’est sur la roadmap » — et vous venez, sans le savoir, de vous engager sur plusieurs semaines de travail qui vont toucher le cœur de votre produit.

Le SSO (Single Sign-On) est l’exemple parfait d’une feature que les fondateurs sous-estiment systématiquement. Vue de l’extérieur, c’est « un bouton de connexion Google/Microsoft ». Vue de l’intérieur, c’est une décision qui engage votre modèle d’identité, votre facturation, et la liste des clients que vous pourrez signer dans les dix-huit prochains mois.

Pourquoi le SSO n’est jamais « juste un bouton »

Il faut d’abord distinguer deux choses que tout le monde confond. Le « Se connecter avec Google » que vous ajoutez en une journée avec une lib OAuth, c’est du social login : pratique pour un produit grand public ou pour du B2B self-service. Cela n’a presque rien à voir avec ce que demande un grand compte.

Ce que veut la DSI d’une entreprise de 800 salariés, c’est du SSO entreprise : ses collaborateurs se connectent à votre produit via son fournisseur d’identité (Okta, Microsoft Entra ID, Google Workspace, Ping…), avec ses règles, sa MFA, sa politique de mot de passe. L’entreprise veut garder la main : quand un salarié part, la désactivation de son compte chez l’IdP doit lui couper l’accès à votre produit. C’est une exigence de sécurité et de conformité, pas de confort.

Techniquement, cela passe par deux protocoles : SAML 2.0, le standard historique encore dominant côté grands comptes, et OIDC (OpenID Connect), plus moderne et plus simple à implémenter. Beaucoup d’IdP proposent les deux. Le piège, c’est que SAML est verbeux, mal documenté par endroits, et truffé de cas particuliers propres à chaque IdP. Ce n’est pas un week-end de dev. C’est un vrai chantier avec une longue traîne de bugs d’intégration client par client.

Le vrai coût est dans votre modèle d’identité

Voici ce que la plupart des startups découvrent trop tard : le SSO ne s’ajoute pas à côté de votre système d’authentification, il le réorganise.

Prenez une startup SaaS classique. Au départ, un utilisateur = un email + un mot de passe, avec une notion de « compte » ou « organisation » un peu floue. Chacun s’inscrit librement. Ça marche très bien jusqu’au premier client entreprise. Parce que le SSO impose une bascule mentale : ce n’est plus l’utilisateur qui décide comment il se connecte, c’est son organisation. Vous devez donc pouvoir dire « tous les utilisateurs dont l’email finit par @grandcompte.fr doivent obligatoirement passer par le SSO de ce client, et ne peuvent pas créer un mot de passe classique ». C’est ce qu’on appelle le SSO enforcement, et c’est souvent une exigence contractuelle : le client ne veut aucune porte dérobée par mot de passe.

Cela suppose que votre modèle de données rattache clairement les utilisateurs à des organisations, que vous sachiez router une connexion vers le bon IdP selon le domaine email, et que vous gériez proprement les cas hybrides (l’admin interne qui a besoin d’un accès de secours si le SSO tombe). Si votre notion d’« organisation » a été bricolée en cours de route — ce qui est le cas dans neuf startups sur dix — c’est là que le chantier explose. Vous ne codez pas une feature, vous refactorez votre gestion des comptes.

N’oubliez pas le provisioning

Le SSO répond à la question « comment les gens se connectent ». Il ne répond pas à « qui a le droit d’avoir un compte » ni « que se passe-t-il quand quelqu’un quitte l’entreprise ». Pour ça, les grands comptes demandent souvent SCIM (provisioning automatique) : quand un salarié est créé dans leur annuaire, un compte est automatiquement créé chez vous ; quand il part, il est automatiquement désactivé.

SCIM est un chantier distinct du SSO, avec sa propre complexité (synchronisation, gestion des groupes, mapping des rôles). Vous pouvez signer un premier gros client avec du SSO seul et du provisioning manuel — mais sachez que SCIM reviendra dans les demandes dès que vous montez en gamme. Traitez-les comme deux étapes, pas comme un bloc.

Le « SSO tax » : une décision de pricing, pas de dev

Il existe une controverse bien connue dans le SaaS B2B, popularisée par le site sso.tax : beaucoup d’éditeurs réservent le SSO à leurs plans les plus chers, parfois avec un saut de prix de x3 ou x4. L’argument des défenseurs : « c’est une feature entreprise, ceux qui la demandent ont les moyens ». L’argument des critiques : « le SSO est une brique de sécurité de base, le facturer à prix d’or, c’est punir les entreprises qui veulent bien faire ».

Les deux camps ont raison, et c’est précisément pour ça que c’est une décision, pas une évidence. Positionner le SSO trop bas dans votre grille, c’est vous priver d’un levier de valeur évident pour les grands comptes — ceux-là mêmes qui ont le budget et pour qui c’est un critère d’achat, pas un confort. Le placer trop haut, ou le rendre inaccessible aux PME sensibles à la sécurité, c’est risquer de perdre des deals sur un point qui ne devrait pas être bloquant.

La ligne raisonnable pour une startup : réservez le SSO à vos plans « Business » ou « Enterprise », mais ne le transformez pas en muraille tarifaire absurde. Et surtout, budgétez son coût de maintenance dans votre pricing. Chaque client SSO va générer de la configuration sur-mesure, des allers-retours avec sa DSI, et un support technique récurrent. Si vous le vendez au prix d’un plan standard, vous financez à perte une feature à forte charge opérationnelle. Le SSO n’est pas gratuit à produire ni à opérer.

Ce qu’il faut vraiment faire

Le premier réflexe est le plus contre-intuitif : ne construisez pas le SSO avant qu’un client le demande contractuellement. Le faire « pour être prêts » est de la sur-ingénierie classique — vous allez deviner les mauvais cas d’usage et re-coder de toute façon quand le vrai besoin arrivera. En revanche, anticipez le modèle d’identité, ce qui ne coûte presque rien : dès le départ, ayez une notion propre d’« organisation » qui possède ses utilisateurs. C’est la seule dette qui rend le SSO douloureux plus tard.

Deuxièmement, quand la demande arrive, ne codez pas SAML vous-même. Le rapport coût/bénéfice penche massivement vers l’achat : des solutions comme WorkOS, Auth0/Okta, Stytch ou Frontegg encapsulent la complexité multi-IdP et vous font gagner des semaines. Vous branchez une API au lieu de déboguer les subtilités SAML d’Okta puis celles d’Entra ID puis celles de Ping. Pour une startup avec une équipe tech restreinte, le build maison de SSO est presque toujours une fausse économie.

Troisièmement, cadrez commercialement. Si un prospect exige le SSO, c’est un signal fort d’intention d’achat — mais engagez-le en retour : un calendrier, un plan tarifaire adapté, et idéalement un client de référence qui co-finance le développement. Ne développez jamais une intégration entreprise « au cas où » sur la promesse verbale d’un pilote gratuit.

Enfin, tracez la frontière avec SCIM. Livrez le SSO d’abord, gérez le provisioning à la main pour vos premiers clients, et n’industrialisez SCIM que lorsque le volume de comptes le justifie.

En résumé

Le SSO condense tout ce qui rend l’accompagnement des startups intéressant : une brique technique qui a l’air anodine, mais qui touche à la fois votre architecture d’identité, votre positionnement pricing, et la nature des clients que vous pouvez servir. Le traiter comme une case à cocher, c’est se condamner à le subir. L’anticiper au bon niveau — modèle d’identité propre en amont, achat plutôt que build, pricing assumé — c’est en faire un accélérateur de deals au lieu d’un frein.

La vraie question n’est donc pas « avons-nous le SSO ? », mais : votre modèle de comptes est-il prêt à considérer l’organisation, et non l’utilisateur, comme l’unité qui possède l’accès ? Si la réponse est non, c’est le premier chantier — bien avant SAML.