Une application mobile ou web a presque toujours besoin des mêmes briques côté serveur : une base de données, des comptes utilisateurs, un hébergement, des tâches qui s’exécutent en arrière-plan et un moyen de savoir quand l’appli plante. Firebase regroupe ces briques dans une seule console, gérée par Google. Le catalogue compte aujourd’hui une vingtaine de produits, de la base temps réel Realtime Database à Firebase AI Logic.
Quel problème Firebase règle, et pour qui
Sans plateforme de ce type, une équipe qui lance une appli doit choisir un hébergeur, installer une base, coder un système d’inscription, gérer les mots de passe et brancher un outil de suivi des erreurs. Firebase remplace ce travail par des SDK à intégrer dans le code de l’appli : le client parle directement aux services, sans serveur intermédiaire à maintenir. Pour situer cette approche parmi les autres façons de concevoir une appli, notre guide pour créer une application mobile pose le décor.
Le public visé est technique : développeurs iOS, Android, web, Flutter, Unity ou C++, seuls ou en petite équipe produit. Firebase n’est pas un outil sans code. Il faut écrire l’appli, définir ses règles de sécurité et comprendre ce que consomme chaque requête.
Firebase et Firebase Studio : deux choses différentes
Cette fiche porte sur la plateforme Firebase, c’est-à-dire les services de backend, d’hébergement et de suivi des applis. Firebase Studio, qui a sa propre fiche dans l’annuaire, était un environnement de développement dans le navigateur, assisté par Gemini. Google a annoncé le 19 mars 2026 son arrêt pour le 22 mars 2027 ; les inscriptions et la création d’espaces de travail sont fermées depuis le 22 juin 2026, avec une migration conseillée vers Google AI Studio ou Google Antigravity. Google précise que les produits Firebase comme Cloud Firestore, Authentication ou App Hosting ne sont pas touchés et que les applis déjà déployées continuent de tourner.
Comment s’organise un projet Firebase
Tout part d’un projet, qui est en réalité un projet Google Cloud doté de réglages propres à Firebase : droits d’accès, facturation et identifiants sont partagés entre les deux consoles. Un même projet peut accueillir jusqu’à 30 applications, par exemple la version iOS, la version Android et le site web d’un même service. La documentation recommande donc de raisonner par projet pour le forfait et le budget, puisque toutes les applis consomment les mêmes quotas.
Les produits se rangent en deux familles dans la documentation officielle :
- Construire : Cloud Firestore (base NoSQL synchronisée en temps réel, utilisable hors connexion), Realtime Database, SQL Connect (base PostgreSQL gérée via Cloud SQL, anciennement Data Connect), Authentication, Cloud Storage, Cloud Functions, Hosting pour les sites statiques et App Hosting pour les applis Next.js ou Angular.
- Exécuter : Crashlytics pour les plantages, Performance Monitoring, Remote Config, A/B Testing, Cloud Messaging pour les notifications, In-App Messaging, App Distribution pour envoyer des versions de test et Test Lab pour tester sur des appareils hébergés.
S’y ajoutent les outils d’IA générative : Firebase AI Logic donne accès aux modèles Gemini depuis l’appli cliente, en Swift, Kotlin, JavaScript, Dart ou Unity, et Genkit sert à construire des fonctions d’IA côté serveur. Notre article sur l’arrivée de Gemini dans Firebase revient sur cette évolution.
Côté sécurité, l’accès direct du client à la base repose sur les règles de sécurité Firebase, écrites dans un langage dédié et testables dans un simulateur de la console avant publication. C’est le point qui demande le plus d’attention au départ : une règle trop permissive expose toutes les données.
Cas d’usage concrets selon votre profil
- Développeur indépendant : lancer une appli de prise de rendez-vous avec connexion Google, données dans Firestore et site vitrine sur Hosting, sans carte bancaire tant que les quotas du forfait Spark suffisent.
- Studio mobile : intégrer Crashlytics et Performance Monitoring dans chaque appli client, recevoir une alerte quand un plantage s’aggrave après une mise à jour, et distribuer les versions de test aux testeurs avec App Distribution.
- Équipe produit et growth : changer un texte d’écran ou un parcours d’inscription pour un segment d’utilisateurs via Remote Config, puis mesurer l’effet avec A/B Testing, sans attendre la validation d’une nouvelle version sur les stores. Nous avions détaillé l’ouverture de Firebase A/B Testing au web.
- Équipe web : connecter un dépôt GitHub à App Hosting pour publier une appli Next.js à chaque commit sur la branche principale, avec domaine personnalisé et clés d’API rangées dans Cloud Secret Manager.
Firebase face à Supabase, AWS Amplify et Appwrite
Supabase est l’alternative la plus citée. Elle part d’une base PostgreSQL relationnelle et d’un code open source que l’on peut auto-héberger, là où Firebase repose d’abord sur une base NoSQL et reste un service exclusivement hébergé par Google. Firebase garde l’avantage sur les outils dédiés au mobile : suivi des plantages, notifications, tests A/B et distribution des versions de test, qui n’ont pas d’équivalent aussi complet chez Supabase.
AWS Amplify joue le même rôle dans l’écosystème Amazon et se justifie surtout si votre infrastructure y est déjà. Appwrite, open source lui aussi, vise les équipes qui veulent un backend comparable sur leurs propres serveurs. Pour comparer d’autres outils de production, consultez notre catégorie logiciels de développement web.
Les limites à connaître avant de vous lancer
- Les alertes budgétaires préviennent sans bloquer la consommation. Seuls Cloud Functions, App Hosting, AI Logic et Extensions acceptent un plafond de dépenses qui met le service en pause.
- Sur le forfait Spark, dépasser un quota désactive le produit concerné pour toutes les applis du projet jusqu’à la fin du mois.
- Cloud Storage, Cloud Functions et App Hosting ne sont pas accessibles sur Spark : il faut associer un compte de facturation.
- Les quotas gratuits de Cloud Storage ne valent que pour trois régions américaines, un point à peser si vos données doivent rester en Europe.
- Le site et la page tarifs sont en anglais ; la documentation est disponible en français, traduite par IA selon Google.
Comment choisir votre forfait
Le forfait Spark suffit pour un prototype, une appli interne ou une appli en production qui n’utilise que les produits sans frais comme Crashlytics ou Cloud Messaging. Il ne demande aucun moyen de paiement, ce qui élimine tout risque de facture.
Le forfait Blaze devient nécessaire dès que vous stockez des fichiers, exécutez des fonctions serveur ou déployez sur App Hosting. Il conserve les quotas gratuits de Spark et ne facture que la consommation au-delà. Les nouveaux comptes Google Cloud peuvent tester les services payants pendant 90 jours avec 300 dollars de crédits ; tant que le compte d’essai n’est pas converti, rien n’est facturé au-delà des crédits. Avant de passer en production, configurez une alerte budgétaire et un plafond de dépenses sur les produits qui l’acceptent, puis estimez votre trafic avec le calculateur de la page tarifs.