Les plafonds de dépenses Google Cloud sont disponibles, mais le débit provisionné continue

Le 30 octobre 2026, Google Cloud a annoncé la disponibilité générale des plafonds de dépense intégrés à Google Cloud Budgets. Cette version ajoute une API, des rapports de coûts estimés en temps réel et une réinitialisation mensuelle automatique pour les services éligibles, afin de limiter une consommation excessive sans supprimer les ressources. Le plafond peut interrompre les requêtes facturées à l'usage et celles couvertes par des remises d'engagement, mais il n'interrompt jamais les requêtes utilisant Provisioned Throughput, dont la capacité réservée continue à servir le trafic. Notre édition du 2 novembre conserve la date de l'annonce et cette exception essentielle.

L'API des plafonds est accessible depuis l'API existante Cloud Billing Budgets. Un administrateur peut créer, modifier, lever ou supprimer un plafond par programme pour les services éligibles d'un projet. Un environnement de développement ou un nouveau bac à sable peut ainsi recevoir une limite dès sa création, au lieu d'attendre une vérification manuelle de la facture. Cela ne signifie pas que tous les produits Google Cloud appliquent la même interruption ni que les frais déjà engagés disparaissent. Avant de déclarer un projet protégé, il faut vérifier son service, son modèle de facturation, les autorisations de gestion et la configuration effective du plafond.

Pour les services d'intelligence artificielle, Google indique que les coûts estimés en direct peuvent déclencher un plafond quelques minutes après l'utilisation. Cost Reports affiche désormais les estimations qui ont motivé la décision, sans attendre la chaîne plus lente de facturation nette. L'estimation rapide et la facture définitive peuvent différer quant au moment et au montant. Un dossier d'incident doit donc conserver les réglages, l'heure du déclenchement, la capture du rapport, les réponses refusées et les charges finalement comptabilisées. La formule « quelques minutes » décrit les services d'IA pris en charge; elle ne garantit pas que chaque euro de chaque produit s'arrête exactement au seuil fixé.

Le guide API précise que tous les plafonds reviennent automatiquement à CONFIGURED au début de la période budgétaire suivante et que les services bloqués reprennent. Une levée manuelle permet seulement une reprise anticipée pendant la période courante. Avec AWAITING_NEXT_PERIOD, le plafond ne se déclenche plus durant cette période, sauf hausse du montant et rétablissement de inputState à CONFIGURED. Le billet principal évoque une dérogation manuelle, mais le guide ne documente aucune option intégrée qui désactive la reprise automatique inter-périodes ou impose une approbation préalable. Un contrôle externe d’approbation serait une recommandation de conception supplémentaire, pas une fonction intégrée. Rechercher la tâche fautive avant le changement de période.

Par défaut, des alertes sont adressées aux administrateurs de facturation et aux propriétaires du projet à 50 %, 80 % et 100 % du plafond. Une équipe qui crée des projets automatiquement doit vérifier que ces rôles ont des destinataires réels et que les messages arrivent. Les autorisations de plafonnement peuvent être ajoutées à des rôles personnalisés, mais le droit de lever une limite mérite une portée réduite et une trace d'audit. On peut commencer avec un petit plafond sur un bac à sable hors production, produire une charge contrôlée et observer les alertes, le rapport en direct, le refus de requête et la remise à zéro. Prévoir aussi comment rétablir une activité légitime et comment enquêter sur des coûts qui restent hors du champ d'application.

La limite la plus importante concerne Provisioned Throughput. Selon l'annonce, les requêtes sur capacité réservée ne sont jamais arrêtées par les plafonds et continuent à fonctionner même lorsque le seuil est atteint. Les requêtes à l'usage et couvertes par une remise d'engagement, elles, sont interrompues. Une équipe combinant ces modes ne doit pas conclure, après un seul refus à l'usage, que l'ensemble de ses dépenses est gelé. Elle doit recenser séparément capacité réservée et engagements fixes, puis les surveiller avec les rapports et contrats appropriés. Le plafond est un garde-fou pour les requêtes éligibles, pas une limite universelle de la facture cloud.

Pour valider, lister projets, services éligibles, droits API et destinataires des alertes. Distinguer la remise à zéro automatique à la période suivante de la levée manuelle anticipée et de AWAITING_NEXT_PERIOD, qui empêche un nouveau déclenchement seulement pendant la période courante selon les conditions du guide. Dans un environnement jetable, provoquer le plafond de façon contrôlée et conserver heures, estimations, codes de réponse et facture ultérieure; essayer séparément les requêtes à l’usage et Provisioned Throughput effectivement utilisé. Toute approbation entre périodes doit être testée comme contrôle externe, pas comme option intégrée.

La disponibilité générale rend les plafonds plus simples à automatiser et à diagnostiquer; la remise à zéro mensuelle change aussi leur exploitation. Leur efficacité dépend toujours de l'éligibilité du service et du modèle de facturation: vérifier l'API et les observations, puis gérer Provisioned Throughput et les autres engagements persistants au moyen de contrôles financiers distincts.