Firebase Remote Config 2026 : Le Guide Complet (Setup, Conditions, A/B Testing, Personalization, Rollouts)
Remote Config, c'est ce qui te permet de changer le comportement de ton app pour tous ou pour un segment d'utilisateurs, sans passer par un redéploiement ni une mise à jour. Voici le guide complet 2026, gratuit et prod-ready.
Remote Config, c'est la fonctionnalité Firebase la plus sous-estimée — et pourtant, la plus rentable. Elle te permet de changer le comportement et l'apparence de ton app (Android, iOS, Web, Flutter, Unity, backend) sans redéployer, sans mise à jour, sans passer par le Play Store ou l'App Store. Tu peux activer une nouvelle fonctionnalité pour 5 % de tes utilisateurs, tester deux couleurs de bouton en A/B, personnaliser une valeur en fonction du pays, de la version d'app, du profil utilisateur, ou même laisser un modèle de Machine Learning décider automatiquement de la meilleure variante à afficher à chaque utilisateur.
Et cerise sur le gâteau : c'est totalement gratuit, y compris pour un usage à grande échelle. En 2026, ne pas utiliser Remote Config dans une app en production revient à te priver d'un des outils les plus puissants du toolkit mobile moderne.
Ce guide est le plus complet en français en 2026 : concepts, workflow fetch/activate, conditions et ciblage, A/B Testing, Personalization ML, rollouts progressifs, exemples de code sur iOS, Android, Web et Flutter, limites, bonnes pratiques.
Remote Config, c'est quoi exactement ?
Firebase Remote Config est un service cloud qui te permet de définir des paramètres nommés (feature flags, valeurs de configuration, chaînes de texte, JSON complet, etc.) et de modifier leurs valeurs à distance depuis la console Firebase (ou l'API REST), sans que l'utilisateur n'ait besoin de mettre à jour l'application.
Techniquement, ton app :
- Définit des valeurs par défaut in-app (embarquées dans le binaire)
- Récupère régulièrement les valeurs distantes depuis Firebase (via
fetch()) - Décide quand activer ces valeurs (via
activate()) pour éviter de perturber une session en cours
Résultat : ta version d'app compilée reste stable, mais son comportement peut évoluer en temps réel selon ta stratégie produit.
Cas d'usage typiques
- Feature flag : « active la nouvelle homepage pour 20 % des utilisateurs, mesure l'impact sur la rétention »
- Kill switch : « désactive instantanément le module de paiement si un bug critique est détecté »
- Personnalisation géographique : « affiche le prix en FCFA au Sénégal, en EUR en France, en XOF en Côte d'Ivoire »
- Onboarding dynamique : « pour les utilisateurs installés depuis moins de 7 jours, affiche un tutoriel »
- A/B testing : « teste deux couleurs de CTA, garde celle qui convertit le mieux »
- Personalization ML : « laisse Firebase choisir automatiquement la meilleure image de bannière par utilisateur »
- Rollout progressif : « déploie la nouvelle recherche à 5 % → 25 % → 50 % → 100 % en 3 jours »
Plateformes supportées en 2026
Remote Config est disponible officiellement sur 7 plateformes :
| Plateforme | SDK minimum |
|---|---|
| iOS / macOS (Apple platforms) | Firebase SDK for Apple v4.5.0+ (pour A/B) |
| Android | Firebase SDK Android v17.1.1+ |
| Web (JavaScript) | Firebase JavaScript SDK v12.8.0+ |
| Flutter | Package firebase_remote_config |
| C++ | Firebase C++ SDK |
| Unity | Firebase Unity SDK |
| Backend / Server | Firebase Admin SDK (Node, Java, Python, Go, C#) |
Concepts fondamentaux à maîtriser
Paramètre (parameter)
Un paramètre est une clé nommée à laquelle est associée une valeur. Exemples :
welcome_message→"Bienvenue !"enable_new_checkout→truehero_image_url→"https://cdn.example.com/hero_v2.png"promo_config→{"code": "SUMMER26", "discount": 15}
Valeur par défaut (default value)
Chaque paramètre a une valeur par défaut embarquée dans ton app. Elle est utilisée quand :
- La première session (avant le premier fetch)
- Le fetch a échoué (offline, quota atteint…)
- Le paramètre n'existe pas côté serveur
Bonnes pratiques : mets toujours une valeur par défaut sensée. Ne compte jamais sur le fait que le fetch réussira.
Condition (condition)
Une condition cible un sous-ensemble d'utilisateurs. Exemples de critères :
- Version d'app (
iOS >= 3.2.0) - Langue (
fr,en) - Pays (
CI,FR,SN) - Audience Google Analytics
- Premier ouvert (avant/après une date)
- ID utilisateur spécifique
- Random percentage (« 20 % des utilisateurs »)
Un paramètre peut avoir plusieurs conditions, évaluées dans l'ordre. La première qui matche gagne, sinon on retombe sur la valeur par défaut serveur, sinon sur la valeur in-app.
Template (template)
L'ensemble de tes paramètres + conditions constitue un template. Firebase garde un historique des 300 dernières versions du template, ce qui te permet de rollback rapidement en cas de problème.
Workflow fetch → activate : le cœur de Remote Config
C'est le concept le plus important à maîtriser. Récupérer et activer sont deux opérations séparées :
fetch(): ton app télécharge les nouvelles valeurs depuis Firebase et les stocke localement (mais ne les applique pas encore)activate(): ton app applique les valeurs téléchargées (celles-ci deviennent la source de vérité pour tous les prochainsgetValue())
Pourquoi cette séparation ? Pour éviter qu'un changement en cours de session ne perturbe l'expérience utilisateur. Le pattern typique : fetch() en arrière-plan pendant que l'utilisateur utilise l'app, puis activate() au prochain démarrage.
Le SDK expose aussi fetchAndActivate() (combiné) pour les cas où c'est OK d'activer immédiatement.
Real-time Remote Config (2024+)
Depuis fin 2024, Firebase propose un Real-time Remote Config : ton app s'abonne aux mises à jour et est notifiée dès qu'un nouveau template est publié, sans polling. C'est le mode recommandé en 2026 pour les kill switches et les rollouts critiques.
Setup Remote Config : les 5 étapes
Étape 1 : Créer le projet Firebase et enregistrer ton app
- Va sur la console Firebase
- Crée un projet (ou utilise un existant)
- Enregistre ton app (Android, iOS ou Web) et télécharge
google-services.json/GoogleService-Info.plist/ clés Web
Étape 2 : Ajouter le SDK Remote Config
Android (Gradle) :
implementation("com.google.firebase:firebase-config-ktx")
iOS (Swift Package Manager ou CocoaPods) :
pod 'Firebase/RemoteConfig'
Web (JavaScript) :
import { getRemoteConfig, fetchAndActivate, getValue } from "firebase/remote-config";
Flutter (pubspec.yaml) :
dependencies:
firebase_remote_config: ^5.0.0
Étape 3 : Créer les paramètres depuis la console Firebase
- Menu Run → Remote Config → Create configuration
- Ajoute tes paramètres, définis leurs valeurs par défaut et leurs conditions
- Clique sur Publish changes pour publier le template
Étape 4 : Initialiser Remote Config dans ton app
Kotlin (Android) :
val remoteConfig = Firebase.remoteConfig
val configSettings = remoteConfigSettings {
minimumFetchIntervalInSeconds = 3600 // 1h en prod
}
remoteConfig.setConfigSettingsAsync(configSettings)
remoteConfig.setDefaultsAsync(R.xml.remote_config_defaults)
Swift (iOS) :
let remoteConfig = RemoteConfig.remoteConfig()
let settings = RemoteConfigSettings()
settings.minimumFetchInterval = 3600
remoteConfig.configSettings = settings
remoteConfig.setDefaults(fromPlist: "RemoteConfigDefaults")
JavaScript (Web) :
const remoteConfig = getRemoteConfig();
remoteConfig.settings.minimumFetchIntervalMillis = 3600000;
remoteConfig.defaultConfig = {
welcome_message: "Bienvenue !",
enable_new_checkout: false
};
Dart (Flutter) :
final remoteConfig = FirebaseRemoteConfig.instance;
await remoteConfig.setConfigSettings(RemoteConfigSettings(
fetchTimeout: const Duration(minutes: 1),
minimumFetchInterval: const Duration(hours: 1),
));
await remoteConfig.setDefaults({
'welcome_message': 'Bienvenue !',
'enable_new_checkout': false,
});
Étape 5 : Fetch, activate et récupérer les valeurs
Kotlin :
remoteConfig.fetchAndActivate().addOnCompleteListener { task ->
if (task.isSuccessful) {
val updated = task.result
val message = remoteConfig.getString("welcome_message")
// Utilise le message dans ton UI
}
}
Dart :
await remoteConfig.fetchAndActivate();
final message = remoteConfig.getString('welcome_message');
final enableCheckout = remoteConfig.getBool('enable_new_checkout');
Conditions et ciblage : où réside la vraie puissance
Les conditions sont ce qui distingue Remote Config d'un simple fichier de config. Depuis la console, tu peux cibler tes utilisateurs sur :
| Critère | Exemple |
|---|---|
| App | Cible une plateforme spécifique (Android only, iOS only) |
| Version d'app | Cible les utilisateurs sur la v3.5.0+ uniquement |
| Système d'exploitation | Cible Android 13+, iOS 17+ |
| Pays / Région | Cible les utilisateurs en Côte d'Ivoire, Sénégal, France |
| Langue | Cible les utilisateurs en fr, en, ar |
| Audience Analytics | Cible une audience définie dans Google Analytics for Firebase (ex: "gros dépensiers") |
| Propriété utilisateur | Cible par une user property personnalisée |
| Premier ouvert | Cible les nouveaux utilisateurs (installés il y a moins de 7 jours) |
| ID utilisateur | Cible un ou plusieurs UIDs spécifiques (utile pour QA, staff, beta testers) |
| Random percentile | Cible aléatoirement 10 %, 25 %, 50 %... des utilisateurs |
Exemple concret
Tu veux tester une nouvelle homepage :
- Condition :
platform == Android AND app_version >= 3.5.0 AND random_percent <= 20 - Nom :
new_homepage_test - Valeur pour cette condition :
true - Valeur par défaut :
false
Résultat : la nouvelle homepage est active pour 20 % de tes utilisateurs Android sur v3.5.0+, tout le reste voit l'ancienne.
A/B Testing avec Remote Config
Firebase A/B Testing intègre nativement Remote Config pour te permettre de comparer plusieurs variantes et mesurer leur impact sur des métriques business (revenus, rétention, conversion, événements custom).
Création d'un test A/B
- Firebase Console → DevOps & Engagement → A/B Testing
- Clique Create experiment
- Choisis Remote Config
- Définis :
- Nom et description
- Objectif (revenus, rétention, événement custom)
- Ciblage (app, audience, langue, pays)
- Variantes (contrôle + 1 à N variantes, avec les valeurs Remote Config correspondantes)
- Distribution (% par variante)
- Lance l'expérience
Firebase collecte les données via Google Analytics, calcule la significativité statistique et t'indique la variante gagnante avec un intervalle de confiance.
SDK minimum requis pour A/B
- Firebase SDK for Android v17.1.1+
- Firebase SDK for Apple platforms v4.5.0+
- Firebase JavaScript SDK v12.8.0+
Personalization : quand Firebase choisit pour toi
Remote Config Personalization est une des features les plus puissantes de Firebase en 2026. Au lieu de définir toi-même quelle variante afficher à qui, tu laisses un modèle de Machine Learning Firebase optimiser en continu pour maximiser l'objectif que tu choisis.
Concrètement :
- Tu crées un paramètre avec plusieurs variantes possibles (ex : 3 couleurs de bouton, 5 messages d'onboarding)
- Tu actives Personalize
- Tu choisis l'objectif à optimiser (clics, revenus, événement custom)
- Le modèle apprend automatiquement quelle variante fonctionne le mieux pour chaque utilisateur individuellement — un utilisateur A verra la variante 1, un utilisateur B la variante 3, en fonction de leurs profils implicites
C'est comme avoir un A/B test permanent qui s'améliore tout seul. Pas besoin de savoir "qui préfère quoi", le ML s'en charge.
Rollouts progressifs
Depuis 2024, Firebase propose des Rollouts dédiés (distincts de l'A/B Testing) pour déployer un changement progressivement :
- Tu définis un paramètre à activer (ex : nouvelle recherche)
- Tu fixes une progression : 5 % → 25 % → 50 % → 100 %
- Firebase compare automatiquement les métriques (Crashlytics + Analytics) entre le groupe rollout et un groupe contrôle
- Si les crashes ou une métrique clé se dégradent, Firebase te propose de rollback
C'est la vraie release engineering moderne appliquée au mobile — sans downtime, sans redéploiement, avec safety net automatique.
Bonnes pratiques Remote Config en production
- Toujours définir des valeurs par défaut robustes — l'app doit fonctionner même si le fetch échoue à 100 %
- Ne mets jamais de secrets dans Remote Config — les valeurs sont accessibles côté client, tu perds toute confidentialité
minimumFetchIntervaldifférent en dev vs prod — 0 secondes en dev pour tester, 3600 secondes minimum en prod- Utilise Real-time RC pour les kill switches critiques — pas de polling, activation immédiate
- Nomme tes paramètres avec un préfixe (
ux_,feat_,promo_) pour organiser ton template - Documente chaque paramètre dans un README interne — sinon dans 6 mois tu ne sauras plus à quoi sert
param_xyz - Configure des conditions "staff only" ciblant tes UIDs QA pour tester avant rollout
- Publie les changements en tranches — pousse d'abord un paramètre puis un autre, jamais tout à la fois
- Combine avec App Check pour empêcher que des attaquants n'appellent Remote Config depuis des clients non légitimes — cf Firebase App Check + reCAPTCHA
- Utilise les versions du template pour rollback si un déploiement casse quelque chose
Limites et quotas 2026
| Ressource | Limite |
|---|---|
| Paramètres par template | 3 000 |
| Conditions par template | 500 |
| Versions historiques conservées | 300 |
| Expériences A/B + rollouts concurrents | 24 (combinés) |
| Taille max d'une valeur paramètre | 1 000 000 caractères (1 MB) |
| Fréquence minimale de fetch recommandée | 1 fetch / heure en prod |
Si tu approches les 3 000 paramètres, c'est probablement le signe qu'il faut restructurer ta config (regroupe les valeurs proches dans un seul paramètre JSON par exemple).
Prix Remote Config en 2026
Remote Config est totalement gratuit, quelle que soit la taille de ta base utilisateurs. Aucun compteur, aucun palier payant. C'est écrit noir sur blanc dans la doc officielle : « at no cost, for unlimited daily active users ».
Les seuls coûts indirects sont :
- Bande passante côté client (les fetch consomment quelques KB par utilisateur)
- Google Analytics si tu utilises A/B Testing avec des événements custom (mais Analytics reste gratuit dans le plan Spark)
Autrement dit : il n'y a aucune raison légitime de ne pas utiliser Remote Config dans une app en 2026.
Remote Config vs Feature Flags maison (LaunchDarkly, Unleash, etc.)
| Critère | Firebase Remote Config | LaunchDarkly / Unleash |
|---|---|---|
| Prix | Gratuit | $$$$ (LaunchDarkly enterprise) |
| Intégration mobile | Native, très bonne | SDK correct mais plus lourd |
| Personalization ML | Oui, native | Non |
| Rollouts + rollback auto Crashlytics | Oui | Non natif |
| A/B Testing intégré | Oui, avec Analytics | Oui |
| Real-time push updates | Oui | Oui |
| UI console | Firebase Console (grand public) | UI dédiée feature flags |
| Backend / server-side | Oui via Admin SDK | Oui, plus mature |
Verdict : pour 99 % des apps mobiles / web modernes, Remote Config suffit largement et coûte 0 €. LaunchDarkly ne devient intéressant que dans des architectures enterprise complexes avec des besoins gouvernance fine et compliance stricte.
FAQ Firebase Remote Config 2026
Firebase Remote Config est-il vraiment gratuit ?
Oui, totalement. Aucun coût, quel que soit le nombre d'utilisateurs actifs par jour. C'est explicitement écrit dans la documentation officielle Firebase.
Puis-je utiliser Remote Config sans Google Analytics ?
Oui, tu peux utiliser les paramètres et conditions sans Analytics. Mais si tu veux A/B Testing ou Personalization, Analytics est requis (gratuit lui aussi).
Remote Config fonctionne-t-il offline ?
Oui. Les valeurs par défaut in-app + les dernières valeurs cachées assurent que ton app fonctionne même sans réseau. Le prochain fetch dès qu'il y a du réseau met à jour le cache.
Quel est l'intervalle de fetch recommandé en production ?
Minimum 3600 secondes (1h). Un intervalle plus court risque de saturer les quotas et de faire consommer inutilement de la data à tes utilisateurs. En dev, mets 0 pour tester rapidement.
Puis-je stocker des secrets ou tokens API dans Remote Config ?
Non, jamais. Les valeurs sont téléchargeables côté client, donc récupérables par n'importe qui via un reverse engineering de l'app. Utilise Cloud Functions ou Firestore avec des règles pour tout ce qui est sensible.
Comment tester un nouveau paramètre sans impact sur les vrais utilisateurs ?
Crée une condition User ID = [ton UID de test] et applique la nouvelle valeur uniquement à cette condition. Tu vois la modification sur ton compte, personne d'autre.
Puis-je utiliser Remote Config côté backend / server ?
Oui, via Firebase Admin SDK (Node.js, Python, Java, Go, C#). Utile pour Cloud Functions, API personnalisées, jobs cron.
Combien de paramètres puis-je créer maximum ?
3 000 paramètres par template. Si tu dépasses, restructure en regroupant les valeurs dans des paramètres JSON.
Remote Config supporte-t-il le real-time ?
Oui depuis 2024. Ton app peut s'abonner aux mises à jour et être notifiée dès qu'un nouveau template est publié, sans polling. C'est le mode recommandé pour les kill switches critiques.
Firebase Personalization, c'est du no-code ?
Oui. Tu définis les variantes dans la console et Firebase entraîne le modèle ML automatiquement. Aucune ligne de code ML à écrire côté ton app.
Pour aller plus loin
- Firebase : comment ça fonctionne
- Firebase App Check + reCAPTCHA
- Firebase Cloud Functions 2026
- Netlify vs Firebase 2026
- Doc officielle : firebase.google.com/docs/remote-config
- Personalization : firebase.google.com/docs/remote-config/personalization
- A/B Testing : firebase.google.com/docs/ab-testing
Remote Config est la brique manquante de 90 % des apps mobiles en production. Elle transforme ton app d'un binaire figé en un produit vivant qui peut évoluer par heure — sans que tes utilisateurs ne s'en rendent compte, sans stress de release, et sans surcoût. Ajoute la brique aujourd'hui, un paramètre à la fois, et tu ne pourras plus t'en passer. Le vrai luxe en 2026 : c'est totalement gratuit.
Sources : Firebase Remote Config — Doc officielle, Remote Config Parameters and Conditions, Remote Config Personalization, Firebase A/B Testing, A/B Testing avec Remote Config. Données 2026.