Connexion unique (SSO) avec Microsoft 365 ou Google

Vos équipes jonglent avec des dizaines de mots de passe et chaque départ de salarié oblige à fermer des accès outil par outil. La connexion unique (SSO, pour single sign-on) règle ce problème : l’application métier délègue l’identification à Microsoft 365 ou à Google Workspace. Voici comment je la mets en place, ce qu’elle coûte et les décisions à prendre avant le développement.

Comment fonctionne la connexion unique

Le principe est simple. Quand un salarié clique sur « Se connecter avec Microsoft » ou « Se connecter avec Google », l’application le redirige vers la page de connexion de son entreprise. Microsoft ou Google vérifie son identité (mot de passe, double authentification), puis renvoie à l’application une preuve signée : qui il est, son adresse, parfois ses groupes. L’application n’a jamais connaissance du mot de passe.

Deux protocoles standard font ce travail :

• OpenID Connect, bâti sur OAuth 2.0 : le plus courant pour les applications web modernes. Google indique que ses API OAuth 2.0 sont conformes à la spécification OpenID Connect (documentation Google Identity, consultée en octobre 2026).
• SAML 2.0 : plus ancien, encore très présent dans les grandes entreprises et les annuaires d’entreprise.

Pour une application développée sur-mesure, je privilégie OpenID Connect, plus simple à maintenir. SAML reste possible quand le service informatique du client l’impose.

Microsoft 365 ou Google : ce qui change

Sources : tarifs Microsoft Entra, qui mentionnent pour l’offre Free un « SSO illimité vers toute application SaaS » et l’inclusion dans les abonnements Microsoft 365 ; aide Google Workspace sur les applications SAML personnalisées. Tarifs publics relevés en octobre 2026, en dollars US, facturés par utilisateur et par mois avec engagement annuel.

Si votre entreprise utilise les deux, l’application peut proposer les deux boutons. Je conseille de le prévoir dès le cadrage : le surcoût est faible au départ et nettement plus élevé une fois l’application en production.

Ce que coûte le SSO dans un projet

Dans un projet neuf, la connexion unique fait partie de la brique comptes et rôles, chiffrée 1 500€HT dans l’estimateur. Elle s’ajoute au prix de base d’une application métier, soit 6 000 à 20 000€HT selon le périmètre.

Ce qui fait varier le travail :

1. Le nombre de fournisseurs d’identité. Microsoft seul, Google seul, ou les deux.
2. La récupération des groupes. Attribuer automatiquement un rôle dans l’application selon le groupe Microsoft ou Google du salarié demande un peu plus de configuration, mais évite de gérer les droits à la main.
3. La création automatique des comptes. Soit le compte est créé à la première connexion, soit un administrateur doit d’abord l’autoriser. Le second mode est plus sûr pour les données sensibles.
4. La cohabitation avec des utilisateurs externes. Clients, partenaires, sous-traitants n’ont pas de compte dans votre annuaire : ils gardent un autre mode de connexion.

Pour une application existante, le coût dépend de la façon dont la connexion a été codée. Je le chiffre après un audit (audit express à 589€HT), car une authentification mal structurée peut demander une reprise plus large que le seul bouton « Se connecter avec Microsoft ».

Les points à cadrer avec votre service informatique

Le SSO touche à la sécurité de l’entreprise : votre DSI ou votre prestataire informatique doit être associé dès le départ. Voici ce que je fais valider au cadrage :

• qui enregistre l’application dans Entra ID ou dans la console Google et qui en garde la maîtrise ;
• quels comptes sont autorisés : tout le domaine, ou seulement certains groupes ;
• quelles informations sont transmises : nom, e-mail, groupes. Le minimum nécessaire, conformément au principe de minimisation du RGPD ;
• la correspondance entre groupes et rôles dans l’application ;
• ce qui se passe au départ d’un salarié : désactivation immédiate, conservation de son historique.

La gestion fine des droits est détaillée dans la page sur les droits d’accès par rôle et la sécurisation des comptes dans celle sur la double authentification.

Quand le SSO n’est pas utile

Je ne le recommande pas systématiquement. Il apporte peu quand :

• l’application sert surtout à des clients ou partenaires externes, qui n’ont pas de compte dans votre annuaire ;
• l’entreprise n’utilise ni Microsoft 365 ni Google Workspace de façon centralisée ;
• les utilisateurs sont peu nombreux et l’application n’est pas sensible : une connexion par e-mail avec double authentification suffit.

À l’inverse, dès que plus d’une vingtaine de salariés utilisent l’outil, ou que vos clients grands comptes exigent une politique d’accès stricte, le SSO devient un argument de sécurité et de confort qui se justifie largement.

Par où commencer

1. Faites l’inventaire des comptes : qui doit se connecter, avec quel annuaire et quels profils sont externes.
2. Associez votre service informatique à l’appel découverte de 30 minutes.
3. Au cadrage, nous fixons les fournisseurs d’identité, la correspondance groupes et rôles et le devis ferme.
4. Au développement, la connexion est testée sur un compte de test de votre annuaire avant l’ouverture à tous.

Pour un premier chiffrage de votre application, avec la brique comptes et rôles, l’estimateur donne une fourchette en une minute.