Donc j'ai demandé le PC du lead dev, j'ai renommé son Agents.md et j'en ai utilisé un autre, que j'avais préparé. J'ai lancé son codex et j'ai traité 5 tickets en 30 min. Des tickets choisis par les dev eux même (qui ont gentiment pris des tickets qu'ils n'arrivaient pas à résoudre ou tentaculaires). On est allé jusqu'à la PR, preprod, staging et... tout fonctionne. Code impeccable.
L'équipe ne disait plus un mot et en toute honnêteté ils ne comprenaient pas comment c'était possible. On a du coup discuté de la manière dont moi je m'en servais et de l'Agents.md
On a relu leur agent.md qui était, à mon sens, l'exact inverse de ce qu'il doit contenir.

En l’état, Google ne propose **aucun plafonnement “dur” par clé Vertex / Gemini**.  
Tu as raison : les “budgets” ne font qu’envoyer des alertes, ils ne bloquent pas la consommation.
 
Par contre, tu peux te construire un **plafond quasi-dur au niveau du projet** + **limiter le débit max** + **durcir la clé**, ce qui réduit énormément le risque de facture à 5 chiffres.
 
***
 
## 1. Idée générale de la solution
 
1. **Projet dédié “jetable” pour Vertex / Gemini**  
   - Tu mets **toutes tes clés Vertex / Gemini** dans un projet GCP séparé (par ex. `vertex-sandbox-capped`).  
   - Si ce projet part en vrille, tu peux le “tuer” sans impacter tes autres ressources.
 
2. **Plafond de coût par projet avec kill-switch automatique**  
   - Tu crées un **budget** sur ce projet (ex. 100 €/mois).  
   - Tu actives les **notifications de budget vers Pub/Sub**.  
   - Tu déploies une **Cloud Function / Cloud Run** qui, quand le budget est atteint, **désactive la facturation du projet via l’API Cloud Billing**.  
   - C’est documenté officiellement par Google comme “Disable billing with notifications”.[1][2]
 
3. **Réduction des quotas Vertex AI**  
   - Dans “Quotas”, tu descends à la main les quotas Vertex (tokens/minute, requêtes/minute, etc.) pour que le **débit max théorique** soit compatible avec ce que tu es prêt à perdre en cas de fuite de clé.[3][4]
 
4. **Durcir la clé elle‑même**  
   - Restreindre la clé à tes **IP serveurs** (VPS + éventuellement IP fixe chez toi).  
   - Restreindre la clé aux **APIs nécessaires uniquement (Vertex / Gemini)**.[5][6]
   - Rotations régulières, jamais dans un repo, etc.[7][8]
 
Ça ne donne pas une “limite parfaite à 100,00 €”, mais dans la pratique, tu transformes un risque de 100 k€ en quelque chose comme “quelques dizaines / centaines d’euros maxi” si tu as bien dimensionné quotas + budget.
 
***
 
## 2. Kill-switch de facturation (la partie la plus importante)
 
Google documente **officiellement** comment faire un “cap” de coût en **désactivant automatiquement la facturation du projet** quand un budget est atteint :[2][9]
 
### 2.1. Étapes concrètes
 
Sur ton projet dédié Vertex :
 
1. **Créer un budget Cloud Billing**
   - Console  *Billing*  *Budgets & alerts*  *Create budget*.  
   - Scope = **ce projet uniquement**.  
   - Montant = ton plafond max acceptable (ex. 50 € / 100 € / 200 €).  
   - Ajoute un seuil à **100 % de budget** (et éventuellement 50 % / 80 % pour des alertes e‑mail).
 
2. **Activer les notifications programmatiques**
   - Dans le budget, choisis comme action d’alerte :  
      **Envoyer vers un topic Pub/Sub**.  
   - Crée un topic, ex. `billing-budget-vertex`.
 
3. **Déployer une fonction qui coupe la facturation**
   - Tu peux suivre la doc Google : *“Disable billing usage with notifications”*.[2]
   - Ils donnent un exemple de **Cloud Run / Cloud Function** qui:
     - est déclenchée par Pub/Sub,
     - lit le message (montant dépensé vs budget),
     - appelle l’API Cloud Billing pour **désactiver la facturation du projet** (`projects.updateBillingInfo`).
 
   L’idée est la même que dans les repos suivants :
   - `poweroff-google-cloud-cap-billing` (Terraform, automation complète)[10]
   - `gp-gcp-disable-billing-cap-cost` (exemple fonction Python)[11]
   - ou les tutos “Google Cloud Killswitch”.[12][13]
 
4. **Tester avec un budget ridicule**
   - Mets un budget à **1 €** juste pour tester (ou une très petite valeur).  
   - Fais quelques appels Vertex pour franchir le seuil.  
   - Vérifie dans la console que **la facturation du projet passe à “désactivée”** quand l’alerte se déclenche.
 
### 2.2. Limitations à connaître
 
- Il y a un **délai** entre la consommation réelle et l’arrivée des données côté Billing (jusqu’à plusieurs heures, parfois ~24 h).[1][2]
   Tu peux donc dépasser un peu ton budget (met ton budget *en dessous* de ton plafond réel).  
- **Désactiver la facturation arrête tous les services** du projet, et certains ne reviennent pas “proprement” tout seuls.[1][2]
   D’où l’intérêt d’avoir **un projet isolé uniquement pour Vertex / Gemini**.
 
***
 
## 3. Limiter le débit max de Vertex (réduire le “taux de brûlage”)
 
Même avec le kill-switch, si quelqu’un spamme à fond pendant quelques heures, ça peut coûter cher avant que le budget se déclenche.  
Tu peux donc **abaisser drastiquement les quotas Vertex AI** dans ce projet.
 
### 3.1. Où et quoi changer
 
1. Console  *IAM & Admin*  *Quotas*.  
2. Filtre :
   - Service = **Vertex AI API** (et/ou “Generative AI on Vertex AI”).  
   - Région où tu appelles (ex. `europe-west1`).  
3. Cherche les métriques liées aux generative models, par ex. (selon modèle / version) :[4][3]
   - `Gemini tokens per minute` / `Throughput`,  
   - `Requests per minute` ou `Online prediction requests`,  
   - etc.
 
### 3.2. Comment les utiliser comme pseudo-plafond
 
Exemple d’idée de calcul rough :
 
- Tu sais que **1M tokens output en Gemini Pro** coûte X $ (voir pricing docs).  
- Tu limites `tokens/min` à une valeur très basse, ex. 5k/min.  
- Coût max théorique par heure  `5k * 60 / 1e6 * prix_1M_tokens`.  
- Tu t’assures que même si quelqu’un spamme en continu à ce débit pendant 24 h, la facture reste supportable.
 
Ce n’est **pas par clé**, c’est **par projet / région**, mais combiné avec le projet isolé + kill‑switch de billing, ça te donne un **plafond de risque très raisonnable**.
 
***
 
## 4. Durcir la clé Vertex / Gemini elle-même
 
Tu peux aussi **réduire drastiquement la surface d’attaque** si ta clé est volée.
 
### 4.1. Restreindre par IP et par API
 
Pour les clés “Google Cloud API key” (y compris clés Gemini/Vertex), tu peux :[6][14][5]
 
1. Aller dans **APIs & Services  Identifiants  ta clé**.
2. Sous “Restrictions de l’application” :
   - Choisir **“Adresse IP du serveur”** (`serverKeyRestrictions`).  
   - Mettre:
     - l’IP publique de ton VPS,
     - éventuellement l’IP fixe de ta box (ou un /24 si tu changes régulièrement).
3. Sous “Restrictions d’API” :
   - Limiter la clé uniquement à **Vertex AI / Generative AI** (Gemini API sur Google Cloud, etc.).  
 
Résultat : si quelqu’un récupère ta clé et l’utilise depuis un autre réseau, **tous ses appels échouent immédiatement**, car l’IP ne colle pas aux restrictions.[8][5][6]
 
### 4.2. Hygiène autour de la clé
 
Les bonnes pratiques (Google les répète partout) :[5][7][8]
 
- **Jamais** dans un repo Git (même privé).  
- Stockage via **variables d’environnement** ou gestionnaire de secrets (chez toi : `.env` chiffré, vault perso; sur GCP : Secret Manager).  
- **Rotation régulière** (re-générer la clé, mettre à jour tes services, supprimer l’ancienne).  
- Surveiller **l’onglet “quota / usage”** de l’API pour repérer :
  - des spikes de requêtes,
  - des requêtes depuis des régions / IP suspectes (dans les logs).
 
***
 
## 5. Alternative forte : éviter les clés, utiliser IAM / Workload Identity
 
Tu dis que tu appelles Vertex **depuis du local et un VPS**. Tant que tu utilises une **clé longue durée** (API key ou JSON de service account), tu as intrinsèquement un secret qui peut fuiter.
 
Deux mitigations plus “enterprisey” :
 
1. **Appeler Vertex depuis un service GCP (Cloud Run / GCE) avec Workload Identity**  
   - Cloud Run / GCE utilisent un **service account attaché**, sans fichier JSON stocké nulle part.  
   - Auth vers Vertex = **jetons courts** fournis par la métadonnée d’instance.  
   - Ton VPS ou ton poste local n’a alors qu’un **token ou un auth applicatif vers TON service**, pas vers Google directement.  
   - Tu peux appliquer **rate limiting / auth / quotas** côté service.
 
2. **Entourer Vertex avec VPC Service Controls** (si tu es déjà sur org GCP)  
   - Permet de **restreindre l’accès aux APIs Vertex à un périmètre réseau GCP précis** (VPC interne, etc.).[15][16]
   - Plus lourd à mettre en place, mais réduit encore la surface en cas de compromission.
 
***
 
## 6. Renforcer encore le “filet de sécurité”
 
En complément de tout ça :
 
- **Projet séparé et minimaliste pour ton usage dev/VPs**  
  - Aucune autre ressource critique dans ce projet.  
  - Kill‑switch dessus, quotas au minimum, clé IP‑restreinte.
 
- **Carte avec plafond bas / carte virtuelle** dédiée à ce compte GCP  
  - Certains utilisent une carte virtuelle avec un **plafond mensuel strict**.  
  - Ce n’est pas élégant mais en dernier recours, c’est ton **vrai hard‑cap** (si la banque refuse la transaction, GCP ne peut pas débiter plus).
 
***
 
## 7. Résumé opérationnel
 
Si tu veux quelque chose de concret à faire ce week‑end :
 
1. **Créer un projet GCP “vertex-sandbox-capped”** uniquement pour Vertex / Gemini.
2. **Baisser les quotas Vertex AI** dans ce projet (tokens/min, req/min) à un niveau “safe”.
3. **Mettre un budget** (par ex. 50 €/mois) + **notifications Pub/Sub**.
4. **Déployer la fonction de kill‑switch** qui désactive la facturation quand le budget est atteint (doc officielle *Disable billing with notifications* + éventuellement un repo GitHub clé en main).[10][11][2]
5. **Créer une clé API restreinte**:
   - IP = VPS + IP fixe maison,
   - APIs = Vertex / Gemini uniquement.[6][5]
6. **N’utiliser que cette clé** sur ton poste local et ton VPS.
 
Avec ça, même si ta clé fuite sur GitHub et se fait attaquer :
 
- Les attaquants seront bloqués par les **restrictions IP** dans la majorité des cas.  
- Dans le pire scénario (IP spoofée / autre compromission), **quotas + budget + kill‑switch** limitent très fortement le montant maximal avant coupure.
 
Si tu veux, tu peux préciser comment tu appelles Vertex (SDK Python, REST brut, via un framework, etc.) et je peux te proposer un setup encore plus ciblé (par ex. mini reverse proxy avec limite de tokens/jour, config Terraform pour le kill‑switch, etc.).
 
Sources
[1] Disable billing usage with notifications https://docs.cloud.google.com/billi [...] ifications
[2] Disable billing usage with notifications - Google Cloud https://cloud.google.com/billing/do [...] ifications
[3] Vertex AI quotas and limits https://docs.cloud.google.com/vertex-ai/docs/quotas
[4] Generative AI on Vertex AI quotas and system limits https://docs.cloud.google.com/verte [...] ocs/quotas
[5] Using Gemini API keys | Google AI for Developers https://ai.google.dev/gemini-api/docs/api-key
[6] Adding restrictions to API keys https://docs.cloud.google.com/api-k [...] s-api-keys
[7] Best practices for managing API keys | Authentication https://docs.cloud.google.com/docs/ [...] -practices
[8] Securing your Gemini API key is crucial https://discuss.ai.google.dev/t/sec [...] ial/106912
[9] Better cost control with Google Cloud Billing programmatic ... https://cloud.google.com/blog/produ [...] ifications
[10] Cyclenerd/poweroff-google-cloud-cap-billing https://github.com/Cyclenerd/powero [...] ap-billing
[11] GitHub - greenpeace/gp-gcp-disable-billing-cap-cost: A Google Cloud Python Function that disables billing and cap the cost with Slack channel and email through mailgun notification https://github.com/greenpeace/gp-gc [...] g-cap-cost
[12] How to Stop Runaway Bills on Google Cloud Platform https://www.youtube.com/watch?v=KiTg8RPpGG4
[13] GCP Billing Killswitch  : r/googlecloud https://www.reddit.com/r/googleclou [...] illswitch/
[14] Best practices for securely using API keys - Google Helpsupport.google.com › googleapi › answer https://support.google.com/googleap [...] 0037?hl=en
[15] i have gemini api key i want it to be only allowed from my private gke cluster only https://www.reddit.com/r/googleclou [...] o_be_only/
[16] About accessing the Vertex AI API https://docs.cloud.google.com/verte [...] ss-methods
[17] CS student receive $55444 Google Cloud bill after API key ... https://voice.lapaas.com/cs-student [...] leak-2025/
[18] Google Cloud needs a “hard spending limit” with a mandatory cooldown https://www.reddit.com/r/googleclou [...] it_with_a/
[19] Student hit with a $55444.78 Google Cloud bill after ... https://www.reddit.com/r/googleclou [...] loud_bill/
[20] Is there any way to hard cap money spend on GCP? https://www.reddit.com/r/googleclou [...] nd_on_gcp/
[21] Project limits & api keys for vertex & gemini - Google Developer forums https://discuss.google.dev/t/projec [...] ini/256502
[22] Desperate: $6,347 GCP Bill from API Key Leak, What Can I Do? https://www.reddit.com/r/googleclou [...] leak_what/
[23] Can I set a hard limit to Google Cloud Platform spend? if ... https://stackoverflow.com/questions [...] if-yes-how
[24] Vertex AI quota https://www.reddit.com/r/Firebase/c [...] _ai_quota/
[25] How does leaked API keys work? https://www.reddit.com/r/googleclou [...] keys_work/
[26] Gemini 2.0 - Vertex AI - Quotas and limits · Issue #426 - GitHub https://github.com/googleapis/python-genai/issues/426
[27] Stop Surprise Cloud Bills with GCP AI Spending Kill Switch https://www.linkedin.com/posts/arvi [...] 99712-7SHf
[28] Need to Stop VertexAI Services - Custom ML & MLOps https://discuss.google.dev/t/need-t [...] ces/161323
[29] Cloud Functions https://mesodiar.com/2023/08/26/tut [...] glish-ver/
[30] How to set up and use Google Cloud budget alerts - Terra Support https://support.terra.bio/hc/en-us/ [...] get-alerts
[31] billing.md.txt - Google AI for Developers https://ai.google.dev/gemini-api/docs/billing.md.txt
[32] GitHub - salesp07/Cap-Firebase-Billing: A seamless guide to capping costs on Firebase. https://github.com/salesp07/Cap-Firebase-Billing
[33] Understand pricing | Firebase AI Logic - Google https://firebase.google.com/docs/ai-logic/pricing
[34] Avoid surprise bills | Firebase Documentation - Google https://firebase.google.com/docs/pr [...] rise-bills
[35] Best practices with Gemini Live API | Generative AI on ... https://docs.cloud.google.com/verte [...] -practices
[36] How to secure your API Keys with Trusted IPs https://support.gemini.com/hc/en-us [...] rusted-IPs
[37] How to Restrict a Google Cloud API Key for Safety  Quick Guide to Secure Your API https://www.youtube.com/watch?v=LlIFcZMflhM
[38] Configuring per customer Gemini API key usage for AI ... https://support.google.com/gemini/t [...] -gcp?hl=en
[39] Blocked IP Address - Gemini API - Google AI Developers Forum https://discuss.ai.google.dev/t/blo [...] ess/109999
[40] How to set Google API key restriction - HTTP referrers https://stackoverflow.com/questions [...] -referrers
[41] Get a Google Cloud API key | Generative AI on Vertex AI https://docs.cloud.google.com/verte [...] t/api-keys
[42] Check for API Key Application Restrictions https://www.trendmicro.com/cloudone [...] tions.html
[43] Safety and factuality guidance | Gemini API https://ai.google.dev/gemini-api/docs/safety-guidance