Guide
Pourquoi les alertes budgétaires Firebase n'arrêtent pas votre facture
21 octobre 2026 · 5 min de lecture
Un budget Firebase ou Google Cloud ne fait qu'envoyer des alertes, et elles arrivent avec des heures de retard. Ce que dit la documentation de Google, et ce qui arrête réellement les dépenses.
La réponse courte
Un budget Firebase ou Google Cloud est une alerte, pas une limite. Lorsque vos dépenses dépassent 50 %, 90 % ou 100 % du montant défini, Google envoie un e-mail ou un message Pub/Sub, et rien d'autre ne se passe : vos lectures Firestore, vos fonctions et vos téléchargements continuent de tourner et d'être facturés. Google le dit clairement dans la documentation Cloud Billing : définir un budget limité aux alertes "doesn't automatically cap Google Cloud or Google Maps Platform usage or spending." (autrement dit, « ne plafonne pas automatiquement l'utilisation ni les dépenses Google Cloud ou Google Maps Platform »).
La documentation Firebase le répète : les alertes budgétaires "do not cap your usage or charges" (« ne plafonnent pas votre utilisation ni vos frais »), ce sont des alertes "so that you can take action, if needed" (« pour que vous puissiez agir, si nécessaire ») (formules tarifaires Firebase). Quelqu'un doit lire l'alerte et agir. C'est là que se trouve la faille.
Pourquoi l'alerte arrive en retard
Même si quelqu'un surveille, l'alerte elle-même est en retard sur les dépenses. Google documente trois délais distincts :
- Remontée des coûts. "There is a delay between your use of Google Cloud resources, and the usage costs reporting to Cloud Billing" (« il existe un délai entre votre utilisation des ressources Google Cloud et la remontée des coûts dans Cloud Billing ») (documentation des budgets).
- Fréquence des notifications. Les notifications de budget sont envoyées à Pub/Sub "multiple times per day" (« plusieurs fois par jour »), pas en continu (notifications programmatiques).
- Calcul quotidien de l'utilisation. Pour Firebase, "Cloud Firestore and Cloud Storage usage are calculated daily" (« l'utilisation de Cloud Firestore et Cloud Storage est calculée chaque jour ») et "Cloud Functions usage is calculated monthly" (« l'utilisation de Cloud Functions est calculée chaque mois ») (éviter les factures surprises).
Pour un budget tout neuf, Google prévient qu'il "may take several hours before receiving the first email or Pub/Sub notification" (« peut falloir plusieurs heures avant de recevoir le premier e-mail ou la première notification Pub/Sub »). Une fonction bloquée dans une boucle ou un script qui martèle votre base de données n'attend pas aussi longtemps.
Et les plafonds de dépenses Firebase ?
En 2026, Firebase a ajouté des plafonds de dépenses, en Preview. C'est un vrai progrès, avec deux limites à connaître :
- Ils ne couvrent que Firebase AI Logic, App Hosting, Cloud Functions for Firebase et les Extensions. Firestore, Realtime Database et Cloud Storage ne sont pas couverts, et c'est là que se produisent la plupart des boucles de lecture et des avalanches de téléchargements.
- Google lui-même indique que les plafonds de dépenses "are not 'hard caps'" (« ne sont pas des plafonds stricts ») : ils agissent sur les mêmes données de coûts différées, et "any cost overages incurred during this delay will be billed as normal." (« tout dépassement de coût survenu pendant ce délai sera facturé normalement »).
Activez-les si vous utilisez ces produits. Ne les considérez simplement pas comme un plafond pour l'ensemble du projet.
Ce qui arrête réellement les dépenses
Quelque chose doit réagir à l'alerte sans attendre un humain. En pratique :
- Demander à votre application de ralentir. Désactivez les fonctionnalités coûteuses, mettez en pause les traitements par lots ou affichez une page de maintenance pendant que vous enquêtez. Nous appelons cela un Soft Kill.
- Dissocier la facturation en dernier recours. Sans compte de facturation, Google arrête tous les services payants du projet. Cela fonctionne même si votre code est cassé, mais avec des conséquences à lire d'abord : ce qui se passe quand la facturation s'arrête.
- Repérer le pic avant le rapport de coûts. Les métriques d'utilisation (lectures, invocations, octets téléchargés) apparaissent dans Cloud Monitoring en quelques minutes, bien avant les coûts.
Vous pouvez construire les deux premières vous-même avec une fonction déclenchée par Pub/Sub (voir le kill switch fait maison), ou laisser FireShield s'en charger : il écoute vos notifications de budget, exécute un Soft Kill ou un Hard Kill aux seuils que vous choisissez et, sur la formule Pro, surveille l'utilisation de chaque service pour détecter les pics.
