Une clé API Gemini volée a transformé une facture de 180 $ en 82 000 $ en deux jours : quand la doctrine «Shared Responsibility Model» de Google laisse les petits développeurs seuls face à des factures énormes

Une clé API Gemini volée a transformé une facture de 180 $ en 82 000 $ en deux jours :
quand la doctrine « Shared Responsibility Model » de Google laisse les petits développeurs seuls face à des factures catastrophiques

Une startup mexicaine de trois développeurs se retrouve face à une facture de 82 314 dollars en quarante-huit heures, après le vol d'une clé API Google Cloud. Ce cas spectaculaire n'est pas un fait divers isolé : il révèle une faille structurelle dans la façon dont Google a intégré Gemini à son infrastructure de clés API existante — et soulève des questions fondamentales sur la responsabilité des grands fournisseurs cloud face aux petites équipes qui leur font confiance.

Il a suffi de deux jours. Entre le 11 et le 12 février 2026, une clé API Google Cloud compromise a permis à des attaquants inconnus de générer 82 314,44 dollars de consommation sur les services Gemini d'une jeune pousse mexicaine. La facture mensuelle habituelle de cette équipe de trois développeurs s'élevait à environ 180 dollars. En moins de quarante-huit heures, elle avait été multipliée par 457.

L'un des développeurs affectés a partagé sa détresse sur Reddit avec ces mots : « Je suis en état de choc et de panique en ce moment. » Il y décrit comment la clé API Google Cloud de leur startup a été compromise sur une courte fenêtre de temps, utilisée massivement pour accéder aux services Gemini 3 Pro Image et Gemini 3 Pro Text.

La startup opérait dans des conditions financières serrées, espérant qu'un jour son produit deviendrait rentable. Les développeurs redoutent que même le paiement d'un tiers de cette somme pourrait suffire à mettre la société en faillite. Face à cette situation, ils ont tenté de négocier avec Google, mais le géant technologique a refusé de revoir le montant avant tout paiement. Ils ont également déposé plainte auprès du FBI.

La défense de Google : le modèle de responsabilité partagée

La réponse officielle de Google a été rapide et sans concession. Un porte-parole de Google Mountain View a indiqué que les clients utilisant les services d'IA générative sont responsables de la protection de leurs propres identifiants, dans le cadre du « Shared Responsibility Model » de la plateforme. En vertu de ce modèle, les fournisseurs cloud sécurisent l'infrastructure, mais les utilisateurs doivent sécuriser leurs propres outils d'authentification.

Les développeurs ont déclaré ne pas avoir commis d'erreur opérationnelle « évidente ». Et, selon eux, c'est là tout le problème : la frontière entre une bonne et une mauvaise pratique de sécurité est de plus en plus floue dans l'écosystème cloud, notamment en raison d'une vulnérabilité structurelle que des chercheurs ont mis des mois à faire reconnaître par Google lui-même. Ce positionnement est juridiquement défendable. Il est aussi profondément problématique.

La faille sous-jacente : quand Gemini a silencieusement élargi les privilèges des clés API

Pour comprendre ce qui s'est passé, il faut revenir en arrière. Pendant des années, les clés API Google Cloud — reconnaissables à leur préfixe AIza — ont été conçues comme de simples identifiants de projet pour la facturation. La documentation officielle de Google Maps, par exemple, invitait explicitement les développeurs à intégrer leur clé API directement dans le code HTML de leurs pages web, dans une balise <script> visible dans le code source de n'importe quel navigateur.

La documentation Firebase allait dans le même sens, en affirmant que les clés API pour les services Firebase « ne sont pas secrètes » et qu'elles peuvent « être intégrées en toute sécurité dans le code client ».

Ces instructions étaient exactes au moment de leur rédaction. Les clés n'étaient pas des credentials d'authentification à proprement parler. Puis Gemini est arrivé — et tout a changé, sans que personne ne soit prévenu.

Lorsqu'un développeur active l'API Gemini (officiellement dénommée « Generative Language API ») sur un projet Google Cloud, toutes les clés API existantes de ce projet acquièrent silencieusement la capacité de s'authentifier auprès des endpoints Gemini. La clé elle-même ne change pas. Ce qui change, c'est ce que le backend de Google accepte désormais d'elle.

La firme de cybersécurité TruffleSecurity, à l'origine de cette découverte, résume le problème en une phrase : « Aucun avertissement. Aucune boîte de dialogue de confirmation. Aucune notification par e-mail. »


2 863 clés exposées découvertes dans une seule exploration du web

L'ampleur du problème est vertigineuse. TruffleSecurity a scanné le jeu de données Common Crawl de novembre 2025 — une archive publique couvrant environ 700 téraoctets de contenu web, soit 2,29 milliards de pages — et a identifié 2 863 clés API Google actives et vulnérables à cette escalade de privilèges.

Parmi les victimes potentielles : des institutions financières majeures, des entreprises de sécurité, des cabinets de recrutement mondiaux, et Google lui-même. L'une des clés découvertes était intégrée dans la page source d'un produit public de Google depuis au moins février 2023, confirmé via Internet Archive. Lors des tests, un simple appel à l'endpoint /models de l'API Gemini retournait un code 200 OK avec la liste complète des modèles disponibles.

La surface d'attaque mobile est encore plus vaste. La société Quokka a publié un rapport complémentaire révélant que 39,5 % des applications d'un corpus de 250 000 apps contenaient des clés API Google codées en dur, représentant plus de 35 000 clés uniques. Les APK Android étant décompilables avec des outils open source librement disponibles, extraire une clé ne nécessite qu'une simple expression régulière suivie d'un appel API.

Les deux catégories de vulnérabilités identifiées sont CWE-1188 (initialisation non sécurisée par défaut) et CWE-269 (attribution incorrecte de privilèges). Un développeur créant une clé pour un widget cartographique génère sans le savoir un credential capable d'accéder à des endpoints d'IA sensibles, parce que la configuration par défaut autorise l'accès à toutes les API activées dans le projet — y compris Gemini.

Une divulgation laborieuse : Google a d'abord rejeté le rapport

Le chemin de la découverte à la reconnaissance publique a été semé d'embûches. TruffleSecurity a soumis son rapport au programme de divulgation des vulnérabilités de Google le 21 novembre 2025. Quatre jours plus tard, Google a conclu que le comportement était « intentionnel » et a classé le rapport sans suite.

Les chercheurs ont tenu bon. Le 1^er décembre 2025, après avoir fourni des exemples concrets tirés de l'infrastructure propre de Google — notamment des clés sur des sites web de produits Google — le rapport a gagné en traction en interne. Le lendemain, Google reclassifiait le rapport de « Customer Issue » en « Bug », en rehaussait la sévérité, et demandait la liste complète des 2 863 clés exposées.

Le 13 janvier 2026, Google a formellement classé la vulnérabilité comme une escalade de privilèges inter-services de niveau 1. Le 2 février 2026, la correction de la cause racine était toujours en cours. La fenêtre de divulgation de 90 jours ayant expiré le 19 février, la divulgation publique a suivi le 25-26 février 2026. Entre-temps, Google a déclaré avoir mis en place des mesures proactives pour détecter et bloquer les clés API exposées tentant d'accéder à l'API Gemini. Mais pour l'équipe mexicaine dont la facture s'est envolée à 82 000 dollars, ce correctif est arrivé trop tard.


La vraie question : qui doit protéger les développeurs des excès de facturation ?

Au-delà de la faille technique, cette affaire met en lumière un débat plus profond sur la responsabilité des grands fournisseurs cloud vis-à-vis des petits développeurs.

Les opérateurs de cartes de crédit ont résolu ce problème il y a des décennies avec des systèmes de détection de fraude et des plafonds de responsabilité. Les fournisseurs cloud ont fait le choix de ne pas en faire autant. Un plafond de dépenses strict — qui couperait le service lorsque la facture atteint un seuil défini par l'utilisateur — serait techniquement trivial à mettre en place. La question est de savoir pourquoi aucun d'entre eux ne le propose comme option par défaut.

L'un des développeurs a argumenté que les fournisseurs cloud devraient mettre en place des protections plus robustes contre les anomalies de facturation extrêmes, suggérant que les plateformes devraient automatiquement stopper ou vérifier les charges dès que l'utilisation atteint des seuils anormaux.

La distinction entre une alerte de facturation et un coupe-circuit est fondamentale. Les alertes sont des notifications — elles arrivent après coup, pendant que le compteur tourne. Pour une startup brûlant quelques centaines de dollars par mois, un pic anormal ne sera pas intercepté par une équipe financière. Pour un développeur seul dans un pays où 82 000 dollars représentent une somme qui peut changer une vie, il n'existe aucun filet de sécurité.


Ce que les développeurs doivent faire maintenant

Face à cette vulnérabilité, TruffleSecurity recommande plusieurs mesures immédiates à tout utilisateur de Google Cloud. L'outil open source TruffleHog — fort de plus de 24 800 étoiles sur GitHub — permet de scanner les dépôts de code, les pipelines CI/CD et les assets web à la recherche de clés API Google exposées. Il supporte la vérification active, c'est-à-dire qu'il tente réellement de s'authentifier avec les clés trouvées pour confirmer si elles sont actives.

Il convient également de revoir les restrictions appliquées à chaque clé API dans la console Google Cloud. Une clé destinée à Google Maps n'a aucune raison d'avoir accès à l'API Gemini. La mise en place de restrictions par API et par référent HTTP est une hygiène de base que beaucoup de projets négligent, souvent parce que la documentation officielle a historiquement minimisé les risques associés à ces clés.

Enfin, la rotation régulière des clés API — même en l'absence de compromission connue — reste une bonne pratique. Les clés statiques, intégrées une fois dans un projet et jamais réévaluées, sont un vecteur d'attaque sous-estimé.

Conclusion

L'affaire de la startup mexicaine est le symptôme d'un problème systémique à l'intersection de trois dynamiques : la démocratisation rapide des APIs d'IA générative, une architecture de clés API conçue pour une époque révolue, et un modèle de facturation qui expose les utilisateurs les plus vulnérables à des risques catastrophiques.

Google a reconnu la faille et travaille à la corriger. Mais pour des milliers de développeurs dont les clés sont déjà publiques sur le web — souvent à la suite des instructions de Google lui-même — la menace reste entière. Et la question de savoir qui doit payer quand le système échoue reste, pour l'instant, sans réponse satisfaisante.

Sources : TruffleSecurity, documentation Google, vidéo dans le texte, Shared Responsibility Model, capture d'écran de l'un des développeurs

Et vous ?

Les grands fournisseurs cloud (Google, AWS, Azure) ont-ils une responsabilité morale — ou même légale — lorsqu'une vulnérabilité dans leur propre architecture de sécurité conduit à des pertes financières catastrophiques pour leurs clients ?

Un plafond de dépenses obligatoire et contraignant (qui coupe réellement l'accès plutôt que d'envoyer une alerte) devrait-il être imposé par la réglementation aux fournisseurs cloud, à l'instar des protections dont bénéficient les détenteurs de cartes bancaires ?

La doctrine du « Shared Responsibility Model » est-elle encore pertinente à l'ère de l'IA générative, où la surface d'attaque et les coûts associés à une compromission ont été multipliés par des ordres de grandeur ?

TruffleSecurity a dû montrer à Google des exemples tirés de sa propre infrastructure pour faire reconnaître la vulnérabilité. Que dit cela de l'efficacité des programmes de divulgation responsable chez les grandes plateformes ?