L’authentification unique (SSO, pour Single Sign-On) permet aux collaborateurs de se connecter une seule fois auprès d’un fournisseur d’identité (IdP) central, puis d’ouvrir toutes les applications de travail autorisées sans mot de passe distinct pour chacune. Ce guide présente l’authentification unique pour les équipes de petites entreprises : ce qu’est le SSO, pourquoi il aide, quand il vaut l’effort, ce qu’il coûte et comment le déployer en cinq étapes.
Le SSO concentre aussi le risque. Si la connexion à l’IdP peut être victime de phishing, un seul identifiant volé ouvre toutes les applications connectées. La méthode de connexion compte donc autant que le produit que vous présélectionnez.
Hideez publie ce guide. L’entreprise est éditeur d’une solution d’authentification des collaborateurs sans mot de passe fondée sur FIDO2 : vous savez donc d’où nous parlons. Les conseils ci-dessous restent neutres entre les principales options et incluent un plan de pilote de 30 jours ainsi que les preuves à demander à chaque éditeur avant d’acheter.
Qu’est-ce que le SSO en petite entreprise ?
En pratique, une seule connexion auprès d’un fournisseur d’identité (IdP) central remplace un mot de passe distinct dans chaque application de travail autorisée. L’IdP vérifie qui est la personne, et chaque application se fie à sa réponse. Microsoft Entra ID et Okta sont deux exemples de fournisseurs d’identité. Le SSO est l’une des briques de la gestion des identités et des accès (IAM), la discipline qui décide qui peut accéder à quel système.
Comment fonctionne l’authentification unique ?
Lorsqu’une personne ouvre une application, celle-ci (le fournisseur de services) redirige le navigateur vers l’IdP. Après l’authentification SSO, l’IdP renvoie un jeton signé, appelé assertion en SAML, et l’application accorde l’accès. Les collaborateurs ne transmettent jamais leur mot de passe IdP à l’application elle-même, ce qui réduit le nombre d’endroits où un identifiant peut fuiter.
Deux protocoles portent cet échange. SAML s’appuie sur XML et domine dans les SaaS professionnels. OpenID Connect (OIDC) repose sur OAuth 2.0 et convient aux applications web et mobiles récentes. Une application ne peut participer que si elle prend en charge l’un des deux : votre liste d’applications détermine donc jusqu’où le SSO peut aller.
Le bouton grand public « Se connecter avec Google » suit le même principe, mais la version d’entreprise ajoute du contrôle. Vous choisissez les applications connectées, vous imposez le MFA à une seule connexion et vous désactivez un compte pour couper l’accès fédéré. C’est l’authentification centralisée : un seul endroit où l’identité est vérifiée, et un seul endroit où elle peut être révoquée.
Pourquoi les petites entreprises ont-elles besoin du SSO ?
Pour une petite entreprise, le SSO est rentable dans quatre domaines : un accès plus rapide, une meilleure sécurité, une gestion plus propre des arrivées et des départs, et moins de tickets liés aux mots de passe. Il comporte aussi des limites, traitées plus loin dans ce guide : la taxe SSO, les applications qui ne peuvent pas être fédérées et l’IdP comme point de défaillance unique.
Un accès simplifié aux applications métier
Prenez une équipe de 15 personnes avec 10 connexions distinctes. Sans SSO, cela représente 150 mots de passe à créer, à réutiliser, à oublier et à réinitialiser. Avec le SSO, chaque collaborateur se connecte une fois à l’IdP le matin et accède de là à Slack, HubSpot et QuickBooks, sans autre invite pour le reste de la session.
Le gain ne se limite pas à la vitesse. Moins de connexions signifie moins de post-it et de mots de passe enregistrés dans le navigateur, et le dirigeant obtient une seule liste des applications cloud et de leurs utilisateurs, à la place d’un tableur qui finit par ne plus être à jour.
L’authentification unique aide aussi les nouveaux outils à s’imposer. Quand une équipe teste une application compatible SAML ou OIDC, la connecter à l’IdP prend quelques minutes, et personne n’a à créer un énième mot de passe pour simplement l’évaluer. Les équipes à distance et mobiles disposent du même point d’entrée : l’accès ne dépend donc pas du réseau du bureau.
Une sécurité renforcée et moins de risques liés aux mots de passe
Les collaborateurs réutilisent moins de mots de passe, et vous imposez l’authentification multifacteur (MFA) une seule fois, à la connexion à l’IdP, au lieu de le faire application par application.
Le revers, c’est la concentration. Chaque application fédérée est désormais derrière une seule connexion : un mot de passe volé ou un code relayé au niveau de l’IdP les ouvre toutes. Sécurisez d’abord ce point d’entrée. Les SMS et les validations par notification push peuvent être victimes de phishing, alors que les méthodes résistantes au phishing, comme les passkeys FIDO2 et les clés de sécurité, sont conçues pour y résister. La comparaison figure dans la section sur les fonctions de sécurité.
Le MFA devient aussi plus facile à appliquer de façon homogène. Sans SSO, chaque application a son propre réglage MFA, et il est facile d’en laisser un désactivé. Avec un seul IdP, une politique unique détermine qui doit utiliser quelle méthode, et un seul journal affiche les échecs de connexion. C’est un contrôle d’accès concret pour une équipe sans personnel dédié à la sécurité.
Une intégration et un départ des collaborateurs plus simples
L’intégration d’un nouveau collaborateur se résume à une seule étape : créer l’identité, l’ajouter aux bons groupes, et les applications autorisées apparaissent. C’est au départ d’un collaborateur que le gain est le plus important. Désactiver une seule identité coupe l’accès fédéré à toutes les applications connectées, par exemple les connexions Microsoft 365, CRM et ticketing d’un collaborateur qui part, en une seule action.
Désactiver un utilisateur chez le fournisseur d’identité ne bloque que les connexions fédérées. Les comptes locaux, les jetons d’API et les boîtes aux lettres partagées des applications non fédérées subsistent : tenez donc une courte liste de contrôle de ces applications et nettoyez-les à la main le dernier jour.
Lancez la désactivation avant la fin de l’entretien de départ, pour qu’aucun ancien collaborateur ne garde de session active, et confiez les documents partagés à un responsable avant de fermer l’identité.
Moins d’administration informatique et de support lié aux mots de passe
Moins de mots de passe à oublier, c’est moins de demandes de réinitialisation, et la personne qui s’occupe de l’informatique à temps partiel récupère ces heures. Relevez votre volume actuel de réinitialisations avant le pilote pour pouvoir comparer ensuite, et n’empruntez pas de chiffres d’économies aux éditeurs : comptez vos propres tickets avant et pendant le pilote.
Le travail d’administration ne disparaît pas, il se déplace. Le temps jadis consacré aux réinitialisations passe aux revues d’accès, aux renouvellements de certificats et à l’ajout d’applications.
Le support lié aux mots de passe comprend aussi des tâches plus discrètes : les comptes verrouillés le lundi matin et la réinscription d’un nouveau téléphone. Une courte procédure écrite pour ces cas, confiée à l’administrateur suppléant, évite que les demandes courantes n’interrompent l’administrateur principal.
Le SSO est-il rentable en petite entreprise ?
La réponse dépend moins de l’effectif que de trois facteurs : le nombre d’applications utilisées, la complexité qu’a prise la gestion des accès, et ce qu’exigent votre sécurité et vos clients. Une entreprise de 10 personnes avec 25 outils cloud et des données clients peut y gagner davantage qu’une équipe de 60 personnes qui vit dans deux applications.
Quand une petite entreprise a-t-elle besoin du SSO ?
Le SSO mérite généralement d’être planifié lorsque plusieurs de ces conditions s’appliquent :
-
Un grand nombre de services métier. Dès que les équipes jonglent avec une douzaine d’applications cloud ou plus, les réinitialisations de mots de passe et les connexions oubliées deviennent un coût courant.
-
Des accès accordés et retirés fréquemment. Personnel saisonnier, prestataires, stagiaires et recrutements rapides impliquent des arrivées et des départs réguliers, où un seul interrupteur vaut mieux que dix fermetures manuelles.
-
Des données confidentielles. Fichiers clients, finance, dossiers RH ou informations de santé justifient un contrôle d’accès plus strict et des journaux indiquant qui s’est connecté à quoi.
-
Un besoin d’authentification centralisée. Si vous devez imposer le MFA partout, prouver qui avait accès à une date donnée ou répondre à un questionnaire de sécurité client, une connexion centrale est bien plus facile à défendre que de nombreuses connexions séparées.
Deux critères remplis ou plus suffisent pour qu’un pilote vaille le temps investi.
Quand le SSO peut-il être superflu ?
Le SSO peut dépasser vos besoins lorsque l’équipe n’utilise qu’une poignée d’applications, que les accès changent rarement et que rien dans votre informatique n’est complexe. Dans ce cas, un déploiement complet peut coûter plus en configuration et en temps d’administration qu’il ne rapporte, du moins pour l’instant.
Cela ne veut pas dire que l’équipe reste sans protection. Un socle de sécurité de base est possible sans SSO complet :
-
L’authentification multifacteur sur la messagerie, le stockage de fichiers et l’outil de finance, de préférence avec des passkeys ou des clés de sécurité.
-
Un gestionnaire de mots de passe pour que chaque compte ait un mot de passe unique et généré.
-
Une revue d’accès régulière, par exemple chaque trimestre, pour supprimer les comptes et les droits que personne n’utilise.
Considérez ce socle comme un point de départ, pas comme un verdict. Refaites le test de sélection quand vous ajoutez des applications, recrutez rapidement ou signez un client qui impose des exigences de sécurité. Beaucoup d’équipes commencent par ce socle, puis ajoutent le SSO pour les cinq ou six premières applications quand la liste s’allonge.
Combien coûte le SSO en petite entreprise ?
La licence n’est que l’une des six lignes de coût. Le coût total réunit les licences IdP, les montées en gamme des applications, les modules d’authentification, le matériel, le temps d’administration et un pilote : chiffrez donc les six avant de présélectionner quoi que ce soit. Construisez un tableau avec une ligne par poste :
-
Licence IdP : prix par utilisateur et par mois, multiplié par l’effectif. Vérifiez d’abord si une suite que vous payez déjà en inclut une. Microsoft 365 Business Premium comprend Microsoft Entra ID P1, comme l’explique la documentation de licences Microsoft Entra.
-
Montée en gamme pour SAML : de nombreux éditeurs SaaS réservent SAML ou OIDC à une offre supérieure, ce que l’on appelle la taxe SSO. Ouvrez la page de tarifs de chaque application clé, notez l’écart de prix par utilisateur et comparez-le avec la liste sso.tax.
-
Modules MFA et sans mot de passe : le MFA avancé et la gestion du cycle de vie sont souvent facturés à part.
-
Clés matérielles : une par utilisateur plus une de secours, si vous en utilisez. Les prix varient selon le modèle : prenez le tarif en vigueur de la clé présélectionnée.
-
Temps d’administration : demandez à chaque éditeur l’effort mensuel réaliste, puis multipliez-le par votre coût horaire interne.
-
Pilote : même un essai gratuit consomme des heures de travail.
Additionnez les lignes, puis comparez le total avec ce que vous coûtent aujourd’hui les réinitialisations de mots de passe et les départs gérés à la main. Les tarifs par utilisateur changent souvent : ce guide ne donne donc aucune grille de prix. Lisez la page de tarifs actuelle de chaque éditeur le jour de la comparaison.
Comment choisir la meilleure solution SSO ?
La meilleure solution SSO pour une petite équipe est celle que vos applications, votre budget et votre temps d’administration peuvent soutenir, pas celle qui a la plus longue liste de fonctions. Les solutions d’authentification unique pour petites entreprises se répartissent en trois voies : le service d’identité inclus dans une suite que vous payez déjà, un fournisseur d’identité autonome, ou une plateforme sans mot de passe. Chacune couvre une part différente de vos applications et cache des coûts différents. Pour une vue plus détaillée, éditeur par éditeur, consultez notre comparatif des principales solutions SSO.
La règle empirique : avec Microsoft 365, commencez par Entra ID. Avec Google Workspace, testez la console d’administration comme pivot d’identité. Passez à un IdP autonome seulement quand de nombreuses applications sont hors de votre suite, et choisissez une plateforme sans mot de passe quand la résistance au phishing ou les postes partagés dictent la décision. Les quatre critères ci-dessous transforment cette règle en liste de contrôle.
Compatibilité avec les applications métier existantes
La compatibilité dépend de la prise en charge des protocoles, pas de la taille de l’éditeur : une application d’entreprise connue n’est donc pas forcément prête. Vérifiez lesquelles de vos applications cloud prennent en charge SAML ou OpenID Connect, et dans quelle offre tarifaire, avant de comparer le moindre fournisseur. La méthode du tableur est décrite à l’étape 1 du déploiement.
Regardez ensuite du côté du fournisseur. Un bon candidat propose des intégrations SSO prêtes à l’emploi pour les applications que vous utilisez déjà, ainsi qu’un moyen documenté de connecter les autres via une URL de métadonnées ou un modèle SAML ou OIDC générique. Demandez la liste des applications prises en charge et ouvrez un tenant d’essai pour confirmer que vos trois applications les plus critiques se connectent sans développement spécifique.
Vérifiez aussi l’annuaire : votre fournisseur d’identité doit lire les comptes et les groupes de celui que vous utilisez déjà, pour ne pas recréer deux fois les utilisateurs.
Fonctions de sécurité et prise en charge du MFA
Le SSO place chaque application fédérée derrière une seule connexion : la connexion à l’IdP doit donc résister au phishing. Les méthodes diffèrent surtout sur un point : un attaquant peut-il réutiliser ce que l’utilisateur saisit ?
Les passkeys offrent un point de départ FIDO2 sans matériel dédié, là où vos appareils et vos applications les prennent en charge. Vérifiez la compatibilité de chaque application et définissez une procédure de récupération en cas de perte d’appareil.
Deux situations demandent une réflexion supplémentaire. Les postes partagés et l’interdiction des téléphones personnels excluent le MFA par application : des clés de sécurité NFC ou USB-C permettent alors à chaque collaborateur de se connecter et de se déconnecter d’un geste. La certification FIDO est liée à un modèle de clé précis : vérifiez donc le statut de certification du modèle exact que vous comptez acheter, et testez-le sur un poste partagé avant de commander en volume. Pour les applications que le SSO ne peut pas fédérer, un gestionnaire de mots de passe ou une passerelle pour applications web héritées couvre une partie du manque, mais ni l’un ni l’autre ne change la connexion propre de l’application.
Facilité de déploiement et de gestion
Une petite équipe n’a pas de personnel de sécurité en réserve : l’effort de déploiement compte donc autant que les fonctions. Posez une question à chaque éditeur : quel est l’effort d’administration mensuel réaliste une fois le système en service ? Demandez ensuite combien de temps prend la connexion des trois premières applications et qui vous aide quand un certificat expire.
Il n’est pas nécessaire de remplacer Entra ID, Active Directory ou Keycloak pour supprimer les mots de passe. L’annuaire reste la source des comptes et des groupes, et les passkeys ou les clés FIDO2 ne changent que la façon dont les utilisateurs prouvent leur identité. Avant d’ajouter une couche sans mot de passe, vérifiez :
-
quel protocole vos applications acceptent (SAML, OIDC ou WS-Federation) ;
-
quels utilisateurs ont besoin de clés matérielles et lesquels peuvent utiliser un téléphone ;
-
comment une clé perdue est révoquée et remplacée.
Tarification transparente et évolutivité
Choisissez un éditeur dont la page de tarifs montre ce que comprend chaque offre, car le prix par utilisateur affiché met rarement en évidence la facture complète. Repérez la gestion du cycle de vie, le MFA avancé, la conservation des journaux d’audit et le support facturés sur des lignes séparées, et demandez ce qu’il advient du prix si l’effectif double ou si vous ajoutez un deuxième site.
L’évolutivité signifie aussi que le produit continue de fonctionner à mesure que la liste d’applications s’allonge. Vérifiez que l’ajout d’applications n’entraîne aucun frais par application, que les groupes et les rôles se gèrent sans script et que votre configuration peut être exportée si vous partez un jour.
Enfin, demandez des preuves plutôt que des adjectifs. Lors de la présélection des éditeurs, vérifiez les certifications (par exemple ISO/IEC 27001), les journaux d’audit, la localisation des données et la prise en charge des intégrations, et conservez les réponses avec votre tableau de coûts.
Comment mettre en place le SSO ?
Un plan limité dans le temps permet à un seul administrateur informatique de déployer le SSO en plus de ses autres missions. Les cinq étapes ci-dessous prennent environ 30 jours pour une petite équipe, avec le pilote au milieu et une décision « go ou no-go » avant le déploiement élargi.
Étape 1 : examiner vos applications et vos besoins d’accès
Un tableur d’une page suffit pour voir ce que le SSO couvrira. Listez chaque application SaaS et notez ces colonnes :
-
Nom de l’application, responsable et nombre d’utilisateurs
-
Méthode de connexion actuelle (mot de passe, compte Google ou Microsoft, compte local)
-
Prise en charge de SAML ou d’OIDC (oui, non, incertain)
-
Offre tarifaire qui l’active
-
Sensibilité des données (finance, fichiers clients, RH)
Relevez l’offre sur la page de tarifs ou dans la documentation d’administration de chaque éditeur, puis confirmez-la dans un tenant d’essai. Dans la console d’administration, cherchez les paramètres « SSO », « SAML » ou « fournisseur d’identité ». Classez ensuite les applications en trois catégories :
-
Fédérer maintenant : le protocole est disponible dans votre offre actuelle. Commencez par les applications qui contiennent les données les plus sensibles.
-
Fédérer plus tard : le protocole exige une offre supérieure. Comparez le prix de la montée en gamme avec le risque avant de payer.
-
Impossible à fédérer : ni SAML ni OIDC.
Pour la troisième catégorie, les options sont des identifiants stockés dans un gestionnaire de mots de passe, un SSO fondé sur les mots de passe, ou une passerelle pour applications web héritées comme Hideez AuthShield. Aucune ne change la connexion propre de l’application : conservez donc une étape de départ manuelle pour ces applications.
Étape 2 : choisir un fournisseur d’identité
Servez-vous de l’audit pour choisir la voie parmi celles du comparatif ci-dessus : suite incluse, IdP autonome ou plateforme sans mot de passe. Présélectionnez deux fournisseurs au maximum, car chaque essai supplémentaire coûte des heures de travail.
Pour chacun, confirmez quatre points : il connecte vos applications à « fédérer maintenant », il prend en charge un MFA résistant au phishing, il lit votre annuaire existant et sa tarification est claire pour votre effectif. Vérifiez les certifications et les journaux d’audit sur documents, pas sur la parole d’un commercial.
Décidez qui est responsable du système. Nommez un administrateur principal et un suppléant, pour qu’un congé ou une démission ne laisse pas l’IdP sans gestionnaire. Consignez sur une page la décision, le coût mensuel et les applications concernées pour la revue « go ou no-go » de l’étape 4. Documentez aussi la sortie : comment les utilisateurs et la configuration passeraient chez un autre fournisseur si les prix ou les besoins changent.
Étape 3 : configurer le SSO et le MFA
Connectez d’abord trois à cinq applications, en commençant par les plus sensibles. Pour chacune, configurez SAML ou OIDC, associez les attributs utilisateur attendus par l’application (généralement l’adresse e-mail et le nom) et testez une connexion de bout en bout. Imposez ensuite le MFA à la connexion à l’IdP, avec des passkeys ou des clés de sécurité là où les appareils le permettent, et ne gardez le SMS que comme solution de repli de dernier recours.
Le SSO concentre le risque sur une seule connexion : prévoyez donc sa défaillance avant que quiconque en dépende. Créez deux comptes administrateur de secours (break-glass) qui ne dépendent ni du SSO ni de politiques de connexion susceptibles de les bloquer, et conservez leurs identifiants dans des lieux sûrs et distincts. Microsoft recommande au moins deux comptes d’accès d’urgence.
Configurez aussi une méthode d’authentification de secours pour chaque utilisateur, rédigez les étapes de récupération en cas de perte d’appareil et lancez un calendrier des dates d’expiration des certificats. Un certificat SAML expiré est une cause fréquente de panne de connexion soudaine à l’échelle de l’entreprise.
Étape 4 : tester avec un petit groupe de collaborateurs
Choisissez 5 à 10 utilisateurs pilotes aux rôles variés, avec idéalement une personne qui n’aime pas le changement. Donnez-leur les trois à cinq applications connectées, un mode d’emploi d’une page et un canal direct pour signaler les problèmes. Menez le pilote sur plusieurs semaines et fixez vos critères de « go ou no-go » avant son lancement.
Un plan sur quatre semaines suffit pour une petite équipe :
- Semaine 1 : recensez chaque application, puis choisissez 3 à 5 applications et 5 à 10 utilisateurs pilotes.
- Semaine 2 : configurez SAML ou OIDC et imposez le MFA ou les passkeys.
- Semaine 3 : recueillez les points de friction et les tickets du support.
- Semaine 4 : décidez « go ou no-go » selon vos critères.
Comparez les tickets avec le volume de réinitialisations que vous avez relevé plus tôt. Testez volontairement les cas difficiles : une clé perdue, un nouveau téléphone, un utilisateur qui part et un poste partagé.
Étape 5 : déployer le SSO et surveiller les accès
Si le pilote répond à vos critères, déployez par vagues, équipe par équipe, plutôt qu’en un seul week-end. Annoncez la date, publiez le mode d’emploi et gardez les anciens modes de connexion disponibles pendant une courte période fixe, pour qu’un échec de connexion ne bloque jamais un appel client.
Quand tout le monde utilise le SSO, passez à une surveillance de routine. Examinez les journaux de connexion pour repérer les échecs et les localisations inhabituelles, faites une revue d’accès trimestrielle et vérifiez le calendrier des certificats chaque mois. À chaque départ, désactivez d’abord l’identité, puis nettoyez les applications non fédérées de votre tableau de l’étape 1.
Réexaminez l’inventaire des applications tous les six mois. Les nouveaux outils arrivent discrètement, et chacun de ceux qui contournent l’IdP rouvre le problème de mots de passe que le SSO devait refermer.
Défis courants du SSO pour les petites entreprises (et comment les surmonter)
La CISA a étudié les freins à l’adoption du SSO dans les petites et moyennes entreprises et a publié son rapport en juin 2024. Le tableau recense les défis courants des petites équipes et une façon concrète de surmonter chacun.
La plupart de ces défis deviennent des points de liste de contrôle quand on les anticipe avant d’acheter.
Comment Hideez aide les petites entreprises à mettre en place le SSO sans mot de passe
Hideez Workforce Identity propose un SSO sans mot de passe : les collaborateurs se connectent une seule fois pour accéder aux applications métier connectées, sans mots de passe distincts. La solution prend en charge SAML et OpenID Connect, avec une authentification par passkeys, par l’application mobile Hideez Authenticator ou par des clés de sécurité FIDO2.
Pour les petites équipes informatiques, cela signifie moins de mots de passe à réinitialiser et un seul endroit pour gérer l’accès aux services connectés. Hideez s’intègre à Active Directory et à Microsoft Entra ID : les entreprises gardent ainsi leur annuaire de collaborateurs existant. Pour les applications web héritées compatibles qui n’offrent pas de SSO natif, Hideez AuthShield apporte une option d’intégration supplémentaire.
L’offre SSO pour petites entreprises comprend une version cloud gratuite jusqu’à cinq utilisateurs, qui permet aux équipes de tester leurs applications avant de passer à l’échelle. Les déploiements en cloud privé et sur site (on-premise) sont également disponibles. Notre calculateur de ROI estime les coûts logiciels et matériels de Hideez, ainsi que les gains potentiels de temps pour le support informatique et les collaborateurs.
Des fonctions supplémentaires étendent la protection des accès aux ordinateurs Windows. Les collaborateurs peuvent se connecter sans mot de passe avec un smartphone ou la Hideez Key 5, avec un accès sans contact et un verrouillage automatique de la session à distance quand ils s’éloignent. Avec un système de contrôle d’accès compatible, la Hideez Key 5 peut aussi servir de badge d’accès au bâtiment.
Lancez le SSO sans mot de passe dans votre petite entreprise
Venez à l’appel avec votre liste d’applications et votre effectif. Demandez une démo : l’appel comprend un pilote gratuit. Des questions avant cela ? Utilisez la page de contact.
