- Le compte Google Cloud de SSLMate a été suspendu une troisième fois sans préavis, interrompant à répétition les fonctions d’intégration du service
- Pour les intégrations Cloud DNS et Cloud Domains des clients, l’entreprise utilisait une architecture fondée sur la création et la délégation de comptes de service selon la documentation de Google, mais cette méthode continue d’être visée par des suspensions
- La première suspension (2024) a provoqué une forte confusion en raison de l’inefficacité du processus de rétablissement et de l’absence de cause claire ; les deux suspensions suivantes se sont elles aussi limitées à des e-mails automatisés répétés, sans préavis
- Comme alternatives, l’authentification par clé de longue durée est fragile sur le plan de la sécurité, tandis que OIDC (OpenID Connect) implique une procédure de configuration excessivement complexe
- En conséquence, les intégrations Google Cloud révèlent une limite structurelle où l’on ne peut choisir que deux éléments parmi sécurité, simplicité et stabilité
Cas de suspensions répétées d’un compte Google Cloud
- Le compte Google Cloud de SSLMate a été suspendu sans préavis deux fois, en 2024 puis en 2025, chaque fois un vendredi consécutif
- Une suspension identique avait déjà eu lieu en 2024 et, dans les trois cas, aucune raison claire ni méthode pour éviter une récidive n’a été fournie
- Pour s’intégrer aux comptes Google Cloud de ses clients, SSLMate utilise une méthode de délégation de comptes de service
- Pour chaque client, un compte de service est créé dans un projet SSLMate, puis le client lui accorde l’accès à Cloud DNS et Cloud Domains
- SSLMate peut ensuite, lorsque nécessaire, usurper virtuellement (
impersonate) ce compte de service pour y accéder
- Cette architecture repose sur la méthode recommandée dans la documentation officielle de Google et constitue une approche sûre et simple à configurer, sans identifiants de longue durée
Première suspension (2024)
- Lors de la première suspension, toutes les intégrations client ont échoué et l’accès à la console a été bloqué
- L’équipe de support Google a répondu, mais la procédure de rétablissement était inefficace, notamment parce que les e-mails rebondissaient du fait de la désactivation du compte
- L’entreprise s’est vu demander les ID de projet, mais ne pouvait pas les fournir puisque l’accès à la console était impossible
- Après vérification du numéro de téléphone, seuls certains projets ont été rétablis, puis un nouvel e-mail automatique a signalé le lendemain une restriction d’accès
- Après plusieurs e-mails automatisés supplémentaires, le rétablissement complet a eu lieu environ 19 heures plus tard
- Google n’a pas expliqué la raison de la suspension et aucun e-mail d’avertissement préalable n’a été envoyé
- SSLMate a ensuite ajouté une fonction de health check surveillant le taux d’erreurs d’intégration pour tenter une détection précoce
Deuxième suspension (vers octobre 2025)
- Le health check a échoué et la plupart des intégrations ont renvoyé l’erreur « Invalid grant: account not found »
- La connexion à la console restait possible, mais seuls des e-mails indiquant que chaque projet avait été « rétabli sur la base des informations fournies » ont été reçus
- Aucun e-mail de notification de suspension n’a, là encore, été reçu
- Les intégrations ont ensuite recommencé à fonctionner normalement
Troisième suspension (novembre 2025)
- Après un nouvel échec du health check, un nouveau type de message d’erreur est apparu lors de l’accès à la console
- La plupart des projets ont été suspendus, y compris ceux destinés aux intégrations clients
- Un recours a été déposé le vendredi, mais un e-mail notifiant la suspension complète du compte n’est arrivé que le dimanche
- Le lundi, juste après la publication du billet sur Hacker News, la plupart des projets ont été rétablis, puis quelques heures plus tard l’accès complet a été restauré
- Cette fois encore, aucune cause ni méthode de prévention n’a été fournie
Cas d’un client faisant exception
- Pendant toutes les périodes de suspension, l’intégration d’un seul client a continué à fonctionner normalement
- Bien qu’elle utilise un compte de service du même projet, elle n’a pas été affectée
- Aucune explication supplémentaire n’a été donnée sur cette différence
Problème de dépendance à Google Cloud et alternatives
- SSLMate estime qu’il est impossible de dépendre d’un compte Google en environnement de production
- Les systèmes de Google permettent qu’un compte, un projet ou même l’ensemble de GCP soit suspendu de manière arbitraire
- Alternative 1 : le client crée lui-même un compte de service et fournit à SSLMate une authentification par clé de longue durée (
long-lived key)
- La configuration est simple, mais la sécurité est faible en raison du risque de fuite de clé et de l’impossibilité de rotation
- Alternative 2 : utiliser OpenID Connect (OIDC)
- C’est la méthode standard utilisée avec GitHub Actions ou les intégrations Azure, permettant un accès sûr sans identifiants de longue durée
- Cependant, la configuration sur Google Cloud suit une procédure en 7 étapes jugée excessivement complexe
Complexité de la configuration OIDC
- Pour utiliser OIDC, les étapes suivantes sont nécessaires
- Activer l’API IAM Service Account Credentials
- Créer un compte de service
- Créer un Workload Identity Pool
- Créer dans ce pool un Workload Identity Provider
- Autoriser SSLMate à usurper le compte de service
- Attribuer un rôle (
Role) au compte de service
- Transmettre à SSLMate l’ID du compte de service créé ainsi que l’ID du Provider
- Chaque étape nécessite l’ID de ressource de l’étape précédente, ce qui rend le processus difficile à suivre pour les clients
- L’auteur considère les points suivants comme des procédures inutiles
- Il devrait être possible d’attribuer directement des rôles sans créer de compte de service
- Dans la plupart des cas, un pool ne contient qu’un seul Provider ; la création du pool elle-même est donc une duplication inutile
- Il devrait être possible d’attribuer directement des rôles à l’URL de l’émetteur OIDC et au sujet (
subject) sans créer de Provider
Problème structurel et conclusion
- Dans l’état actuel des intégrations Google Cloud, on ne peut choisir que deux options parmi les trois suivantes
- Pas d’identifiants de longue durée
- Une configuration simple pour le client
- Une protection contre les suspensions arbitraires
- La méthode fondée sur les comptes de service de SSLMate assure la sécurité et la simplicité, mais comporte un risque de suspension
- La méthode compte de service + clé est simple à configurer et moins exposée au risque de suspension, mais sa sécurité est faible
- La méthode OIDC offre sécurité et résistance aux suspensions, mais sa configuration est complexe
- La conclusion est qu’à moins que Google ne simplifie OIDC pour en faire une méthode d’intégration de premier plan, il sera difficile d’obtenir des intégrations à la fois sûres et stables
Résumé des commentaires des lecteurs
- Un lecteur a déclaré : « Utilisez un autre fournisseur cloud, GCP est le pire »
- L’auteur a répondu : « Nous en avons besoin pour l’intégration parce que nos clients utilisent GCP »
- Un autre lecteur a estimé que « la sécurité et la fiabilité sont en conflit avec la simplicité », et qu’un client donnant la priorité à la simplicité n’est pas adapté
2 commentaires
« Android developer verification finirait par se passer exactement comme ça. Beaucoup de gens se verraient interdire de développer pour Android. »
C’est probablement l’avis sur Hacker News qui m’a le plus marqué. Je pense que ce n’est plus très loin.
Réactions sur Hacker News
Les gens considèrent Google comme un partenaire fiable, mais en réalité c’est un système conçu comme une immense usine de retail
destiné à des millions de personnes, où une seule mesure de protection automatisée erronée peut détruire la vie de milliers d’entre elles
l’absence de support client ou les réponses automatisées dénuées de sens ressemblent moins à une simple réduction des coûts qu’à une stratégie de minimisation de la responsabilité juridique
La plupart des gens savent qu’un compte Google peut être suspendu à tout moment, sans raison
En pratique, tout le monde connaît au moins une ou deux personnes autour de soi qui ont perdu l’accès à leur compte
À moins de signer un contrat de plusieurs millions de dollars, je pense que presque personne ne considère Google comme un vrai partenaire
Toutes les plateformes privilégient la montée en charge
Il est impossible de conserver une relation humaine avec chaque utilisateur tout en gardant une rentabilité digne de trafiquants de drogue
Même si une personne honnête se fait piéger à tort, cela est considéré comme un « coût nécessaire »
Hier c’était Wise, avant cela des comptes GitHub ont été bloqués de cette manière
Les entreprises ne fonctionnent pas comme des démocraties, mais comme des fiefs féodaux
Si un système automatisé vous juge criminel, la punition tombe immédiatement, sans procès
On peut parler à de vraies personnes, pas à un simple chatbot
En ce moment, j’utilise Tuta Mail, et j’aime bien le chiffrement résistant au quantique ainsi que l’absence de publicité
Je peux aussi créer autant d’alias que je veux sur mon propre domaine
Il y a quelques années, mon compte YouTube Premium a été bloqué pour spam
Je ne faisais pourtant que regarder des vidéos, mais mon compte a été supprimé et l’accès à la page de paiement a aussi été coupé
Pendant la procédure d’appel robotisée, possible seulement une fois toutes les trois semaines, les frais continuaient à m’être facturés
Même le support payant de Google One n’a servi à rien, sous prétexte que « c’était une autre équipe »
J’ai fini par régler le problème en faisant opposition à ma carte, puis quelques mois plus tard j’ai reçu un message disant que « c’était une erreur »
Ironiquement, WeChat a résolu le problème en un jour avec un vrai interlocuteur au téléphone — cela m’a donné l’impression que le support client d’un État censeur était meilleur
Le problème ne se limite pas à Google, mais concerne l’ensemble de la structure des grandes entreprises dépendantes des algorithmes
Sur Reddit aussi, mon compte vieux de 20 ans a été shadowban sans raison
Les appels ont été ignorés, et tous mes posts comme mes commentaires ont été filtrés
Le Fediverse montre un meilleur modèle alternatif — fondé sur de petites communautés et une forte proportion de modérateurs
Une simple balise #fediblock peut déclencher un blocage automatique sur des centaines de serveurs, ce qui reproduit une censure irresponsable
C’est exactement comme cela que l’instance Mastodon de notre ville a fini par disparaître, et tout le monde est parti sur Bluesky
Ce ne serait pas difficile d’affecter une centaine de personnes au traitement de ces cas limites
Mais ils ne le font pas parce que cela réduirait leurs marges
Ce n’est pas qu’elles n’ont pas l’argent, c’est qu’elles choisissent de ne pas le dépenser
À l’avenir, ce genre de problème risque aussi d’arriver avec l’API Gemini
Si un client génère une image qui enfreint les règles, cela pourrait entraîner la suspension permanente immédiate d’un Gmail professionnel ou même du Gmail personnel utilisé pour la récupération
La certification des développeurs Android risque aussi d’évoluer dans ce sens
Beaucoup de développeurs risquent de subir une suspension de leur statut de développeur sans raison claire
J’ai déjà vu le cas d’employés d’une petite entreprise dont les comptes personnels ont été bloqués eux aussi, au motif qu’ils étaient « associés à un compte développeur précédemment suspendu »
Je pense qu’il est difficile de conserver une expertise durable dans une telle dépendance à la plateforme
Notre service utilisait simplement le bouton « Login with Google », et soudain le compte a été bloqué
La seule explication était une vague « violation des conditions d’utilisation »
Pendant que nous déposions un recours et préparions en urgence une autre solution de connexion pour les utilisateurs, nous avons reçu dès le lendemain un e-mail annonçant que « le recours était accepté »
Au final, le compte a bien été rétabli, mais un sentiment de méfiance est resté
Mon compte AdSense a été suspendu trois fois parce que j’avais mis un seul point d’exclamation dans une annonce
J’ai fini par fermer le compte, mais j’ai l’impression d’être encore suivi comme « compte potentiellement frauduleux »
Si un nouvel utilisateur peut être suspendu en une heure, on peut se demander pourquoi l’inscription a été rendue si simple dès le départ
Dans une telle situation, on se demande s’il faut poursuivre Google en justice ou réclamer un durcissement de la régulation
J’ai entendu dire que Google ne se présentait parfois pas, ou que ses arguments fondés sur les TOS se retournaient contre lui devant le juge
Je me demande ce qu’il advient des comptes en connexion uniquement par Passkey enregistrés avec une adresse e-mail suspendue
Peu de gens semblent avoir testé si une Passkey synchronisée dans Google Password Manager continue de fonctionner après la suspension du compte,
ou si l’absence d’accès à l’e-mail rend toute récupération impossible