Comment éviter les factures surprises Firebase : une checklist

Firebase a une page intitulée Avoid surprise bills. C'est un bon point de départ, qui couvre trois choses : tester votre code, surveiller votre usage, configurer des budgets. Voici le même terrain en checklist, dans le même ordre, avec ce que chaque étape laisse ouvert et les étapes que la page ne mentionne pas.

Une chose à garder en tête dès le départ : "Firebase pricing plans apply to the entire project, not just to individual apps registered in the project." (les forfaits Firebase s'appliquent à tout le projet, pas seulement à chaque app enregistrée). Chaque app du projet (web, iOS, Android, un build de test pointé sur la production) s'ajoute à la même facture.

Google recommande la Local Emulator Suite, qui fait tourner Firestore, Cloud Functions, Realtime Database et d'autres sur votre machine, pour que "you don't incur any Firebase costs that might result from testing against services in production" (vous n'ayez aucun coût Firebase lié à des tests sur les services de production). Pendant vos tests, elle cite deux schémas à surveiller :

• "Forgetting to add a limit to a database query with millions of results" (oublier de mettre une limite à une requête qui renvoie des millions de résultats)
• "Combinations of Cloud Functions that cause excessive fan-out workloads or even infinite loops" (des combinaisons de Cloud Functions qui provoquent un fan-out excessif, voire des boucles infinies)

Ce qui reste ouvert : l'émulateur montre ce que fait votre code, pas ce que de vrais utilisateurs ou un inconnu en feront. Il ne verra pas un listener qui se réabonne à chaque écran de la vraie app, ni un bot qui appelle votre fonction. Pour les schémas de lecture qui échappent aux tests, voir comment trouver ce qui lit votre Firestore.

Deuxième étape de Google : "You need to know what normal usage patterns look like for your app" (vous devez savoir à quoi ressemble l'usage normal de votre app). Chaque produit a un onglet Usage dans la console Firebase, et Settings, Usage and billing montre tout le projet face au quota gratuit.

Deux nuances. Les chiffres n'avancent pas au même rythme : "Cloud Firestore and Cloud Storage usage are calculated daily" (l'usage de Firestore et Storage est calculé chaque jour) et "Cloud Functions usage is calculated monthly" (celui de Cloud Functions, chaque mois). Et le tableau de bord Firestore est une estimation : "the dashboard is not an exact view of billed operations. Billed usage is likely higher." (le tableau de bord n'est pas une vue exacte des opérations facturées, et l'usage facturé est probablement plus élevé) (documentation sur l'usage de Firestore).

Ce qui reste ouvert : quelqu'un doit regarder. Un tableau de bord montre le pic à qui l'ouvre, et à 3 h du matin personne ne l'ouvre. Si la facture est déjà plus haute que prévu, comment trouver ce qui vous est facturé parcourt les rapports de facturation jusqu'au SKU et au jour.

En passant au forfait Blaze, Firebase vous propose de créer un budget. Faites-le, mais sachez ce que c'est : "Budget alerts do not pause services." (les alertes budgétaires ne mettent pas les services en pause). Elles existent "so that you can take action, if needed" (pour que vous puissiez agir, si besoin).

Ce qui reste ouvert : l'alerte arrive des heures après la dépense, et quelqu'un doit encore agir. Pourquoi, avec les mots de Google : pourquoi les alertes budgétaires n'arrêtent pas votre facture.

Les budgets avec spend cap sont l'option la plus récente : quand un service atteint 100 % de son budget, Cloud Billing "pauses that service for the rest of the month" (met ce service en pause pour le reste du mois). Ils ne couvrent que Firebase AI Logic, App Hosting, Cloud Functions for Firebase et Extensions.

Ce qui reste ouvert : Firestore, Realtime Database, Cloud Storage et Hosting ne sont pas couverts. Et Google prévient : "Spend caps are not "hard caps"." (les spend caps ne sont pas des « plafonds stricts »). L'application "can be delayed by several minutes" (peut être retardée de plusieurs minutes), et ce qui est dépensé dans cet intervalle est facturé normalement.

La page de Google parle de surveiller les coûts. La plupart des factures à cinq chiffres de nos histoires d'horreur venaient d'ailleurs : quelque chose hors de l'app qui appelait des services payants. Trois choses à faire avant le lancement :

• Restreignez vos clés API. Limitez chaque clé aux API et aux apps qui en ont besoin, et gardez l'API Gemini hors de toute clé embarquée dans votre app : comment restreindre une clé API Firebase.
• Activez App Check et des règles de sécurité strictes. Pour que seule votre app atteigne votre base de données et vos fonctions callable : attaques par déni de portefeuille.
• Plafonnez les instances de vos fonctions. Une fonction qui s'emballe coûte d'autant plus qu'elle obtient d'instances. Fixez un maximum : comment limiter les dépenses Firebase.

La page de Google va dans le même sens : elle suggère d'utiliser les notifications budgétaires pour désactiver la facturation du projet. Vous pouvez le construire vous-même avec une fonction sur le topic Pub/Sub du budget (guide pas à pas), mais lisez d'abord ce qui se passe quand la facturation s'arrête : cela arrête tous les services payants du projet.

Ou laissez FireShield s'en charger. Il agit sur chaque notification budgétaire dès qu'elle arrive, peut envoyer un webhook de Soft Kill pour que votre app se dégrade d'elle-même avant la coupure de la facturation, et sur Pro il surveille l'usage de chaque service pour repérer les pics, si bien qu'un emballement apparaît en moins d'une heure et non dans le prochain rapport de coûts.

1. Testez dans la Local Emulator Suite, avec une limite sur chaque requête.
2. Connaissez votre usage normal par produit, et vérifiez-le après chaque version.
3. Créez un budget, en sachant qu'il n'envoie que des alertes.
4. Activez les spend caps pour AI Logic, App Hosting, Cloud Functions et Extensions.
5. Restreignez les clés API, activez App Check, plafonnez les instances des fonctions.
6. Branchez quelque chose qui agit sur le budget sans attendre un humain.