Les entreprises peuvent désormais imposer des plafonds de dépenses sur leurs projets dans le cloud, un outil de maîtrise budgétaire qui se déploie différemment chez AWS et Google Cloud. Chez AWS, cette fonction permet de fixer le montant maximum à payer par mois pour un projet spécifique. Si l’usage atteint ce seuil, l’intégralité des ressources du projet est suspendue, ce qui arrête les coûts.

Ce système, qui est une extension des AWS Budgets, est conçu pour les phases d’expérimentation ou de tests. Le plafond ne représente pas des frais, mais le plafond des coûts avant impôts. Pour le mettre en place, il faut être sur un plan payant. La valeur minimale autorisée est fixée au plus haut entre 20 dollars ou une estimation prudente de la dépense probable. Cette estimation tient compte de l’activité passée du mois, mais elle n’est pas une extrapolation linéaire stricte, car AWS examine l’activité actuelle et les ressources déjà en cours d’exécution.

L’approche granulaire de Google Cloud pour les usages IA

Google Cloud, quant à lui, a rendu les plafonnements de dépenses (spend caps) disponibles dans la version générale (GA) de ses Budgets de facturation. La différence majeure réside dans l’application : au lieu de couper tout le projet, un cap spécifique bloque simplement les nouvelles requêtes vers le service concerné une fois le budget mensuel atteint. Les requêtes déjà en cours sont menées à terme et facturées normalement, et les ressources persistantes restent actives.

Ce mécanisme est particulièrement ciblé sur les services d’intelligence artificielle, comme l’API Gemini ou la plateforme Gemini Enterprise Agent. Selon InfoQ, un changement significatif est que l’application de la limite se base désormais sur les coûts estimés en temps réel, ce qui permet d’intervenir bien avant que la facture ne soit définitivement établie, contrairement à une facturation qui peut prendre plusieurs heures pour se stabiliser.

Les systèmes de contrôle des coûts : des mécanismes différents

Si les deux plateformes visent à rassurer les équipes sur leurs budgets, leur philosophie d’intervention diffère. AWS, dans son expérience d’acquisition de nouveaux comptes, propose un arrêt complet du projet en cas de dépassement. Ce mécanisme, qui est en cours de déploiement, peut être disruptif, mais il préserve les données du projet pendant 90 jours. De plus, AWS propose des contrôles plus fins et proactifs : environ sept jours avant d’atteindre le plafond, le lancement de nouvelles ressources cesse. Cinq jours avant, les ressources inactives sont mises en pause, et quatre jours avant, les ressources générant le coût le plus élevé sont suspendues.

InfoQ rappelle que cette fonctionnalité AWS se rapproche de ce que certains développeurs réclamaient depuis longtemps : la nécessité que les services de paiement à l’usage intègrent des limites matérielles par défaut, pour éviter les surprises de factures importantes. Google Cloud, pour sa mise en production, se limite actuellement à couvrir un seul service par projet pour un mois calendaire, excluant des services comme Compute Engine ou le stockage. Les administrateurs reçoivent des notifications aux seuils de 50 %, 80 % et 100 % du plafond, mais ils doivent veiller à configurer le cap légèrement en dessous de leur limite absolue pour tenir compte des écarts de facturation.

Sources

• Create a spend limit in AWS Settings, docs.aws.amazon.com
• Google Cloud Spend Caps Reach General Availability with API and Monthly Resets, InfoQ, 10 novembre 2026