Firexport / Blog

Depuis le 1er septembre 2026, le prix de Firebase Remote Config dépend de la fréquence à laquelle les applications récupèrent leur configuration. Les 100 000 premiers fetchs par jour sont gratuits dans toutes les formules. Au-delà, les projets Blaze paient chaque fetch et les projets Spark finissent par être limités. La plupart des applications restent sous la barre. Que la vôtre y reste dépend moins du nombre de vos utilisateurs que d’un réglage dans votre code : l’intervalle minimal de fetch.

Les tarifs

• Les 100 000 s’entendent par projet. Une application Android, une application iOS et un site web du même projet se les partagent.
• Ils s’entendent par jour, et un jour calme ne compense pas un jour chargé. Un jour de lancement à un million de fetchs coûte 5,40 $, même si le reste du mois reste sous les 100 000.
• Ni votre code ni la version de votre SDK n’ont à changer. Firebase compte les fetchs de son côté, dans les deux formules.

Quand la nouvelle tarification s’applique à votre projet

Les projets qui ont activé Remote Config avant le 1er septembre 2026 ont d’abord droit à une période de transition. Laquelle dépend de la formule du projet :

La page des tarifs ne dit pas ce qu’il advient d’un projet Spark passé à Blaze entre le 15 novembre et le 1er décembre. Si c’est ce que vous prévoyez, comptez sur une facturation à partir du 1er décembre.

Faut-il passer à Blaze avant le 15 novembre ?

• Si votre projet fait moins de 100 000 fetchs par jour, non. Spark continue de fonctionner comme avant, et Blaze aussi.
• S’il en fait plus, ou s’en approche, passer à Blaze avant le 15 novembre vous laisse deux mois, décembre et janvier, pour réduire les fetchs avant toute facturation. L’alternative, avec Spark, c’est la limitation, ce qui est pire que quelques dollars pour la plupart des applications.
• Blaze associe le projet à un compte Cloud Billing et n’a pas de plafond de dépenses. Les autres produits gardent leur utilisation sans frais, et vous ne payez que ce qui la dépasse. Configurez une alerte budgétaire au moment du passage (voir plus bas).

Ce que signifie la limitation avec Spark

Le premier jour où un projet Spark dépasse 100 000 fetchs déclenche une période de grâce de 30 jours, pendant laquelle chaque fetch est encore servi. Le décompte ne s’interrompt pas et ne repart pas de zéro si l’utilisation repasse sous la barre entre-temps. À partir du 31e jour, les fetchs au-delà du 100 000e de chaque jour sont refusés. L’application continue de fonctionner, mais un appareil dont le fetch est refusé garde les valeurs qu’il a déjà, ou ses valeurs par défaut intégrées à l’application : un déploiement, un test A/B ou un kill switch ne l’atteint pas. Les administrateurs du projet reçoivent des e-mails et voient une bannière dans la console à l’approche de la limite : un avertissement dans votre boîte de réception, c’est le moment de regarder.

Compter vos fetchs

Un fetch est une requête qui atteint le serveur Remote Config :

Les appels que d’autres produits Firebase font en interne ne comptent pas non plus. Pour voir combien de fetchs fait votre projet :

• Console Firebase : Utilisation et facturation (Usage and billing), section Remote Config. Avec Spark, la carte de progression du quota compare les fetchs du jour à 100 000. Avec Blaze, un graphique à barres répartit chaque jour entre les paliers de prix.
• Console Google Cloud : IAM et administration > Quotas et limites du système (IAM & Admin > Quotas & System Limits), filtré sur firebaseremoteconfig.googleapis.com, dans les deux formules. Avec Blaze, les rapports Cloud Billing affichent les frais sous le SKU Fetch Requests : 37B1-4623-6F54 pour les projets créés le 1er septembre 2026 ou après, 598C-0184-404A pour les plus anciens.

Divisez ensuite les fetchs d’un jour type par les utilisateurs actifs de ce jour-là dans Analytics. Avec l’intervalle par défaut de 12 heures et sans écouteur en temps réel, un appareil ne peut pas faire plus de deux fetchs par jour environ : le résultat est donc de 2 ou moins, un peu plus si beaucoup d’utilisateurs ont l’application sur plusieurs appareils ou viennent sur votre site web depuis plusieurs navigateurs. Nettement au-dessus de 2, quelque chose dans votre code contourne l’intervalle, et la section sur les fetchs en trop montre où chercher.

Ce que votre application va payer

Les fetchs quotidiens, ce sont les utilisateurs actifs par jour multipliés par les fetchs par utilisateur et par jour. Saisissez vos propres chiffres, ou ceux que vous attendez après un lancement :

Quelques ordres de grandeur, avec Blaze, pour un mois de 30 jours identiques :

À un million d’utilisateurs par jour, passer de 10 fetchs par utilisateur à 2 fait économiser environ 1 440 $ par mois. Dans l’autre sens, voici combien d’utilisateurs par jour tiennent dans les 100 000 gratuits :

D’où viennent les fetchs en trop, et comment les réduire

Chaque méthode de fetch vérifie d’abord l’intervalle minimal de fetch. Tant qu’il n’est pas écoulé, le SDK renvoie les valeurs qu’il a déjà et aucune requête n’est envoyée. Le nombre de fetchs d’une application dépend donc de la façon dont cet intervalle est réglé, et des quelques éléments qui le contournent. Commencez par trouver chaque endroit où votre code le règle ou le contourne :

grep -rniE "minimumfetchinterval|fetch\(0|expirationduration|timespan\.zero" \
  --exclude-dir={node_modules,build,Pods,.dart_tool,.gradle} .

1. Un intervalle de fetch court resté en production

La valeur par défaut est de 12 heures sur Android, les plateformes Apple, le web et Flutter. Les valeurs plus courtes viennent de configurations de développement et d’exemples : le code de démarrage Flutter de Firebase lui-même fixe une heure « pour permettre des actualisations fréquentes », et beaucoup de tutoriels le recopient. Livrée telle quelle, une heure permet à chaque appareil un fetch par session qui démarre une heure après le dernier fetch, jusqu’à 24 fois par jour. Réservez les valeurs courtes aux builds de débogage :

// Android (Kotlin). On AGP 8+, BuildConfig.DEBUG needs
// buildFeatures { buildConfig = true } in build.gradle.
Firebase.remoteConfig.setConfigSettingsAsync(
    remoteConfigSettings {
        // 12 hours in release builds
        minimumFetchIntervalInSeconds = if (BuildConfig.DEBUG) 60 else 43200
    }
)

// iOS (Swift)
let settings = RemoteConfigSettings()
#if DEBUG
settings.minimumFetchInterval = 60
#else
settings.minimumFetchInterval = 43200 // 12 hours
#endif
RemoteConfig.remoteConfig().configSettings = settings

// Flutter. kDebugMode is in package:flutter/foundation.dart.
await FirebaseRemoteConfig.instance.setConfigSettings(RemoteConfigSettings(
  fetchTimeout: const Duration(minutes: 1),
  minimumFetchInterval:
      kDebugMode ? const Duration(minutes: 1) : const Duration(hours: 12),
));

// Web. 12 hours is the default, so deleting the line does the same.
const remoteConfig = getRemoteConfig(app);
remoteConfig.settings.minimumFetchIntervalMillis = 12 * 60 * 60 * 1000;

Pour les valeurs qui changent rarement, Firebase conseille d’aller plus loin, jusqu’à 24 ou 48 heures. Si vous avez raccourci l’intervalle pour que les modifications atteignent vite les utilisateurs, les mises à jour en temps réel (4) le font avec un fetch par modification au lieu d’un par session.

2. Un fetch(0) issu d’un correctif « Remote Config ne se met pas à jour »

Une réponse fréquente à « mes nouvelles valeurs n’apparaissent pas » consiste à passer un intervalle de zéro à l’appel de fetch. Sur Android et les plateformes Apple, cet argument l’emporte sur les paramètres : l’appel va donc au serveur à chaque fois, quel que soit l’intervalle configuré :

// Each of these ignores the interval and goes to the server on every call:
remoteConfig.fetch(0)                                // Android
remoteConfig.fetch(withExpirationDuration: 0)        // iOS
remoteConfig.FetchAsync(TimeSpan.Zero)               // Unity

Supprimez l’argument et laissez l’intervalle configuré s’appliquer. Les valeurs que voit un utilisateur se mettent toujours à jour dans les 12 heures, ou immédiatement avec un écouteur en temps réel.

3. Un fetch à chaque écran, à chaque reprise ou à chaque réveil en arrière-plan

Un fetch dans la mise en place de chaque écran, dans chaque onResume, à chaque montage de composant, ou dans Application.onCreate, qui s’exécute aussi quand un message push ou une tâche en arrière-plan réveille l’application, multiplie tout ce que l’intervalle permet. Avec 12 heures, cela ajoute peu, puisque la plupart de ces appels reçoivent une réponse sur l’appareil. Avec un intervalle court ou fetch(0), c’est de là que viennent les gros volumes. Faites un seul fetch, quand l’application démarre au premier plan, et lisez les valeurs avec les getters partout ailleurs. Firebase appelle ceux en arrière-plan des « fetchs fantômes » (ghost fetches) et les cite parmi les premières choses à vérifier.

4. Mises à jour en temps réel et publications fréquentes

Un écouteur en temps réel garde une connexion ouverte tant que l’application est au premier plan, et cette connexion est gratuite. Quand vous publiez une nouvelle version du modèle, chaque appareil à l’écoute la télécharge, et chaque téléchargement est un fetch qui ignore l’intervalle. Un appareil qui ouvre l’application plus tard avec une version plus ancienne la reçoit de la même façon. Chaque publication, quoi qu’elle modifie, coûte donc jusqu’à un fetch par appareil qui exécute votre application avant la publication suivante.

200 000 appareils un jour où vous publiez 10 fois, cela fait jusqu’à 2 millions de fetchs rien que pour le temps réel, soit environ 12 $ ce jour-là à 0,06 $ pour 10 000. Regroupez les modifications en une seule publication plutôt qu’en plusieurs petites, et n’ajoutez l’écouteur que là où un changement instantané compte, comme pour un kill switch.

5. Charger le modèle à chaque requête serveur

Remote Config côté serveur, encore en version Preview, télécharge le modèle entier avec un Admin SDK, et chaque téléchargement est un fetch. Appeler getServerTemplate() dans un gestionnaire Cloud Function ou Cloud Run en fait un par requête : un endpoint très sollicité peut ainsi dépasser à lui seul 100 000 par jour. Chargez-le une fois par instance de serveur et actualisez-le avec un minuteur :

import { initializeApp } from "firebase-admin/app";
import { getRemoteConfig } from "firebase-admin/remote-config";

initializeApp();

const DEFAULTS = { welcome_message: "Hello" };
// At most one fetch per server instance every 10 minutes.
const REFRESH_MS = 10 * 60 * 1000;

let templatePromise; // one template per server instance, kept between requests
let loadedAt = 0;

export async function getConfig() {
  if (!templatePromise) {
    loadedAt = Date.now();
    templatePromise = getRemoteConfig()
      .getServerTemplate({ defaultConfig: DEFAULTS })
      .catch((err) => {
        templatePromise = undefined; // try again on the next request
        throw err;
      });
  }

  const template = await templatePromise;

  if (Date.now() - loadedAt > REFRESH_MS) {
    loadedAt = Date.now();
    // Refreshes in the background. Until it lands, requests get the
    // values already loaded.
    template.load().catch((err) => console.error("Refresh failed", err));
  }

  return template.evaluate();
}

Une actualisation toutes les 10 minutes, c’est 144 fetchs par jour pour chaque instance en cours d’exécution, quel que soit le trafic. Les scripts et les jobs de CI qui lisent le modèle via l’API REST comptent aussi, mais rarement assez pour peser.

Configurer une alerte budgétaire en passant à Blaze

Blaze n’a pas de plafond strict. Dans la console Google Cloud, ouvrez Facturation (Billing) > Budgets et alertes (Budgets & alerts) et créez un budget pour le projet, proche de ce que vous donne le calculateur ci-dessus. Par défaut, il envoie un e-mail aux administrateurs de facturation à 50 %, 90 % et 100 % du montant. Il n’arrête pas les dépenses : considérez donc le premier e-mail comme le signal pour regarder le graphique Remote Config de la page Utilisation et facturation (Usage and billing).

Questions fréquentes

Firebase Remote Config est-il toujours gratuit ?

Jusqu’à 100 000 fetchs par jour et par projet, avec Spark comme avec Blaze. La lecture des valeurs sur l’appareil, A/B Testing, les déploiements et la personnalisation ne coûtent rien de plus. Au-delà de 100 000 par jour, les projets Blaze paient 0,06 $ pour 10 000 fetchs et les projets Spark sont limités après une période de grâce de 30 jours.

Quand les projets existants commencent-ils à payer ?

Les projets en formule Blaze, le 1er février 2027. Les projets en formule Spark ne sont pas facturés : la limite de 100 000 s’applique à eux à partir du 1er décembre 2026, sauf s’ils passent à Blaze avant le 15 novembre 2026, auquel cas la facturation commence le 1er février 2027.

La limite de 100 000 fetchs s’applique-t-elle par application ou par projet ?

Par projet. Toutes les applications enregistrées dans un projet Firebase se la partagent.

Dois-je modifier mon code ou mettre à jour le SDK ?

Non. Le comptage se fait sur les serveurs de Firebase, et passer de Spark à Blaze, ou l’inverse, ne demande aucun changement dans l’application. Modifier le code n’a d’intérêt que si vous voulez moins de fetchs.

Remote Config en temps réel coûte-t-il plus cher ?

La connexion ouverte ne compte pas. Chaque téléchargement d’une nouvelle version du modèle après une publication compte, un par appareil, et il ignore l’intervalle minimal de fetch.

Pourquoi mes utilisateurs ne reçoivent-ils pas les nouvelles valeurs Remote Config ?

Le plus souvent à cause de l’intervalle minimal de fetch : un appareil garde ses valeurs jusqu’à 12 heures par défaut, et les valeurs récupérées ne s’appliquent qu’après activate(). Depuis la nouvelle tarification, un projet Spark peut aussi être limité une fois qu’il a dépassé 100 000 fetchs par jour pendant plus de 30 jours. Vérifiez la section Remote Config d’Utilisation et facturation (Usage and billing) avant de raccourcir l’intervalle, ce qui aggraverait la limitation.

Sources

• Tarifs de Remote Config : tarifs, dates de transition, ce qui compte comme un fetch, où voir l’utilisation
• Limitation dans Remote Config et stratégies de chargement : la valeur par défaut de 12 heures et ce qui la remplace
• Remote Config en temps réel : comment les mises à jour sont téléchargées
• Remote Config côté serveur
• Budgets et alertes Cloud Billing