Le problème n’était pas Google lui-même. Le problème, c’était que toute son infrastructure dépendait d’un seul bouton : “Sign in with Google”.
Son compte Google servait de clé d’accès à tout :
Notion → specs produit, contrats, notes clients
Figma → design system et maquettes
Linear → roadmap et tickets
GitHub/Vercel → production encore en ligne… mais impossible à modifier
Stripe → impossible de consulter les paiements ou rembourser des clients
Le SaaS tournait encore. Mais lui n’avait plus les clés.
Et le plus inquiétant : il ne sait toujours pas précisément pourquoi le compte a été suspendu.
Le vrai problème du “Sign in with Google”
Le SSO (“Single Sign-On”) est vendu comme une solution moderne, simple et sécurisée.
En réalité, pour beaucoup d’entreprises, c’est surtout un point de défaillance unique.
Le confort est réel :
un clic,
pas de mot de passe à retenir,
onboarding rapide.
Mais en échange, vous concentrez toute votre identité numérique chez un seul fournisseur.
Quand tout va bien, personne n’y pense. Quand ce fournisseur coupe l’accès, tout tombe d’un coup.
1. Vous ne contrôlez plus réellement votre accès
Quand vous utilisez “Sign in with Google”, vous ne créez pas un compte indépendant chez le service.
Vous déléguez votre identité à Google.
Tant que Google valide votre session, tout fonctionne. Le jour où ce lien est rompu, vous perdez potentiellement l’accès à des dizaines de plateformes critiques.
Et contrairement à ce que beaucoup imaginent :
il n’y a souvent pas de support humain,
pas de SLA,
pas de procédure rapide de récupération.
Même des profils très connus ont déjà subi ce type de blocage.
Le cas le plus célèbre reste celui d’Andrew Spinks, dont le compte Google a été désactivé sans explication en 2021. Il n’a récupéré son accès qu’après une forte médiatisation de l’affaire.
2. Centraliser toute votre identité augmente l’impact d’un incident
Le SSO est souvent présenté comme “plus sécurisé qu’un mot de passe”.
En pratique, ce n’est pas si simple.
Un gestionnaire de mots de passe + :
un mot de passe unique par service,
des alias email,
des clés physiques FIDO2/U2F,
offre souvent une meilleure résilience.
Le vrai sujet n’est pas uniquement la probabilité d’incident. C’est l’ampleur des dégâts.
Perdre l’accès à un service est gênant. Perdre l’accès à 20 services critiques simultanément peut stopper une entreprise entière.
3. Certaines failles OAuth ont eu un impact massif
En 2025, des chercheurs de Truffle Security ont révélé un scénario problématique autour des domaines expirés et de Google OAuth.
Le principe :
Une startup ferme
Son nom de domaine expire
Un attaquant rachète le domaine
Il recrée les anciennes adresses email via Google Workspace
Certains services tiers lui accordent alors un accès aux anciens comptes via “Sign in with Google”
Pourquoi ? Parce que plusieurs plateformes se fiaient essentiellement :
à l’adresse email,
et à la validation Google associée au domaine.
Des outils comme Slack, Notion ou Zoom pouvaient alors devenir accessibles si la logique de vérification côté application était insuffisante.
Le problème ici n’est pas uniquement Google. C’est tout l’écosystème qui s’est construit autour d’une confiance implicite dans le SSO.
4. Changer son mot de passe ne suffit plus toujours
Beaucoup pensent encore :
“Si mon compte est compromis, je change mon mot de passe et c’est réglé.”
Les attaques modernes fonctionnent différemment.
Aujourd’hui, les attaquants cherchent surtout à voler :
des tokens OAuth,
des cookies de session,
des accès persistants.
Dans plusieurs campagnes récentes, des malwares ont réussi à maintenir des sessions Google actives même après un changement de mot de passe, tant que les sessions OAuth n’étaient pas explicitement révoquées.
C’est une réalité encore mal comprise par beaucoup d’entreprises.
5. Le phishing moderne contourne souvent la 2FA
Autre idée reçue :
“J’ai la double authentification, donc je suis protégé.”
Pas forcément.
Les attaques de “consent phishing” utilisent parfois :
une vraie page Google,
un vrai certificat,
une vraie authentification déjà active.
L’utilisateur ne donne pas son mot de passe. Il autorise simplement une application malveillante à accéder à :
ses emails,
son Drive,
ses données Google Workspace.
Techniquement, l’utilisateur valide lui-même l’accès. La 2FA ne bloque donc pas l’attaque.
6. Même le bouton “Sign in with Google” pose des questions de confidentialité
Le bouton Google intégré sur les sites n’est généralement pas une simple image.
C’est un script chargé depuis les serveurs de Google.
Concrètement, cela signifie que Google peut voir :
la page visitée,
le navigateur,
certaines métadonnées,
et parfois l’identité du compte connecté.
Même sans cliquer sur le bouton.
Faut-il arrêter totalement le SSO ?
Non.
Le SSO reste pratique pour :
des services secondaires,
des outils peu critiques,
des comptes jetables ou temporaires.
Le problème apparaît quand la même identité Google devient :
votre accès Stripe,
votre accès cloud,
votre gestionnaire de domaine,
votre outil comptable,
votre production,
votre documentation interne.
À ce moment-là, un seul incident peut devenir systémique.
> use a google account for 15+ years > do everything with it: youtube: google, drive, playstore > launch a saas > stripe, slack, notion, vercel, ....: sign in with google > wake up and see: "your account has been suspended for ..." > can't open notion → 3 years of client files… https://t.co/PVfEZtThcYpic.twitter.com/uAv1zvYkuz
Comment héberger Microsoft Exchange derrière une seule IP publique sans casser NTLM ou ActiveSync ? Découvrez une architecture hybride avec HAProxy en Layer 4 et Nginx en Layer 7 pour garantir stabilité, performance et compatibilité Outlook.
