Firebase équipe des millions d'apps, mais que fait-il vraiment sous le capot ?
Firebase propulse plus de 3 millions d'applications actives dans le monde. Beaucoup d'entrepreneurs signent pour cette plateforme sans savoir ce qu'elle fait exactement, ni combien elle coûtera une fois le trafic monté.
Dans cet article, vous allez découvrir :
- •La définition claire de Firebase, sans jargon technique
- •Le rôle précis de chaque brique (Firestore, Realtime Database, Auth, Hosting, Functions, Storage)
- •Les types d'applications mobiles et web qui utilisent vraiment Firebase
- •Les avantages réels et les limites qui coûtent cher sur le long terme
- •Le moment exact où une alternative open source comme Supabase devient plus maligne
Firebase, c'est un backend prêt à l'emploi. Le revers de la médaille : vous louez l'infrastructure de Google, avec ses règles et sa facture à l'usage.
Firebase, c'est quoi exactement ?
Firebase est une plateforme BaaS (Backend as a Service) rachetée par Google en 2014. En clair, c'est une boîte à outils qui fournit tout ce dont une application a besoin côté serveur, sans que vous ayez à installer ou administrer un seul serveur.
Concrètement, au lieu de développer et d'héberger vous-même une base de données, un système de connexion, une API et un stockage de fichiers, vous branchez votre application (web ou mobile) directement sur les services de Google.
Le développeur se concentre sur l'interface et l'expérience utilisateur. Firebase s'occupe de la plomberie : stockage des données, authentification, montée en charge, sécurité de base.
Cette approche fait partie de la famille plus large du Backend as a Service (BaaS), un modèle qui a explosé avec la demande de développement rapide.
Comment marche Firebase : les briques principales
Firebase n'est pas un produit unique, c'est une suite de services que l'on active à la carte. Voici les briques les plus utilisées.
| Brique | Rôle | Ce qu'elle remplace |
|---|---|---|
| Firestore / Realtime Database | Bases de données NoSQL synchronisées en temps réel | Une base MySQL ou PostgreSQL |
| Authentication | Comptes, connexions, mots de passe | Un système d'auth développé à la main |
| Hosting | Hébergement de sites et apps web | Un serveur web classique |
| Cloud Functions | Code backend serverless | Un serveur d'API |
| Storage | Stockage de fichiers (images, PDF) | Un serveur de fichiers ou Amazon S3 |
| Cloud Messaging | Notifications push | Un service de notifications maison |
Firestore : le cœur du système
Firestore est la base de données phare de Firebase. Elle stocke vos données au format NoSQL (des documents, un peu comme des fiches JSON) et se synchronise en temps réel : quand une donnée change, tous les appareils connectés la voient instantanément.
C'est parfait pour un chat, un tableau de bord live ou une app collaborative. C'est beaucoup moins pratique dès qu'il faut croiser des données ou lancer des requêtes complexes.
Realtime Database ou Firestore : quelle différence ?
Firebase propose deux bases de données. Realtime Database est l'historique : un seul gros arbre JSON, synchronisé en temps réel, très rapide mais difficile à structurer dès que les données grossissent. Firestore est la génération suivante : des documents rangés en collections, des requêtes plus riches, une montée en charge automatique et une facturation par opération plutôt que par bande passante.
Pour un nouveau projet, Google recommande Firestore. Realtime Database reste pertinent pour des flux très simples et très fréquents (présence en ligne, curseurs collaboratifs). Les deux peuvent cohabiter dans la même app.
Authentication, Hosting et le reste
Firebase Authentication gère les inscriptions et les connexions (email, Google, Apple, téléphone) en quelques lignes de code. Hosting sert vos fichiers via un CDN mondial. Cloud Functions exécute du code à la demande, sans serveur à administrer. Storage héberge les fichiers lourds.
L'ensemble forme un backend complet, activable en quelques clics depuis la console Google.
Pourquoi Firebase séduit autant : les avantages
Firebase n'est pas devenu un standard par hasard. Ses atouts sont réels, surtout en début de projet.
- •Vitesse de démarrage : un backend fonctionnel en quelques heures, pas en semaines.
- •Temps réel natif : la synchronisation instantanée est intégrée, sans code complexe.
- •Zéro gestion de serveur : Google s'occupe de la montée en charge et des mises à jour.
- •Écosystème Google : intégration directe avec Analytics, Crashlytics et le cloud de Google.
- •Gratuit pour démarrer : le plan Spark permet de tester sans sortir la carte bleue.
Pour un MVP ou un prototype qu'il faut valider vite, c'est une rampe de lancement redoutable.
Les limites de Firebase à connaître avant de s'engager
C'est là que le bât blesse. Les forces de Firebase deviennent des contraintes dès que le projet grandit.
NoSQL : puissant mais rigide
Firestore stocke des documents, pas des tables reliées. Pour des données très relationnelles (facturation, gestion de stock, reporting croisé), le NoSQL devient vite un casse-tête. On finit par dupliquer des données et complexifier le code.
Le prix à l'usage qui s'emballe
Firebase facture à la lecture, à l'écriture et à la suppression de chaque document. Tant que le trafic est faible, la facture reste douce. Mais une app qui décolle peut voir ses coûts exploser de façon difficile à prévoir. Pour anticiper, comparez avec un modèle de tarification transparent comme celui de Supabase.
Nous avons détaillé le plan Spark, le plan Blaze et les postes qui font déraper la facture dans notre guide Firebase : prix et coûts cachés.
Le lock-in Google
Firebase est propriétaire et fermé. Vos données, votre logique métier et votre authentification vivent dans l'univers Google. Migrer ailleurs demande souvent de tout reconstruire. Vous n'avez aucun accès au code source de la plateforme.
Si vous êtes déjà dans cette situation, la sortie est possible : notre guide de migration de Firebase vers Supabase décrit la méthode étape par étape, de l'export Firestore au schéma PostgreSQL.
Un backend qui vous enferme, c'est une dette technique qui grandit avec votre succès.
Firebase, c'est fait pour qui ?
Firebase reste un excellent choix dans plusieurs cas précis :
- •Vous lancez un MVP et devez valider une idée en quelques semaines.
- •Votre app repose sur du temps réel (messagerie, notifications, live).
- •Vous êtes déjà investi dans l'écosystème Google (Analytics, Ads, Cloud).
- •Votre modèle de données est simple et peu relationnel.
En revanche, dès que le projet vise la durée, la maîtrise des coûts et la portabilité, il faut regarder ailleurs.
Qui utilise Firebase ? Les types d'applications concernées
Firebase est d'abord né pour le mobile : ses SDK Android, iOS et Flutter sont les plus aboutis, et la majorité des apps qui l'utilisent sont des applications mobiles grand public ou des MVP lancés par des startups. On le retrouve typiquement dans :
- •les applications mobiles avec comptes utilisateurs et notifications push (Android, iOS, Flutter, React Native) ;
- •les MVP et prototypes d'entrepreneurs qui veulent tester une idée sans équipe backend ;
- •les apps collaboratives et temps réel : messagerie, tableaux partagés, suivi en direct ;
- •les sites et web apps légers hébergés sur Firebase Hosting, souvent couplés à Google Analytics.
Depuis 2025, Google pousse aussi Firebase Studio, un environnement de prototypage assisté par IA qui génère et déploie une application full stack directement dans l'écosystème Firebase. Pratique pour aller vite, mais le résultat hérite des mêmes limites : NoSQL, facture à l'usage et lock-in.
C'est typiquement le profil d'applications que nous voyons arriver en audit chez ONDEV : une app lancée vite sur Firebase, qui fonctionne, mais dont la facture ou la structure de données devient un frein à mesure que l'usage grandit.
Firebase ou Supabase : quand basculer vers l'open source
Supabase est l'alternative open source la plus citée face à Firebase. La différence de fond : Supabase repose sur PostgreSQL, une base SQL relationnelle, et son code est ouvert. Vous pouvez l'héberger chez Google, ailleurs, ou sur vos propres serveurs.
| Critère | Firebase | Supabase |
|---|---|---|
| Base de données | NoSQL (Firestore) | SQL (PostgreSQL) |
| Open source | Non | Oui |
| Hébergement | Google Cloud uniquement | Cloud ou auto-hébergé |
| Requêtes complexes | Limitées | Complètes (SQL) |
| Portabilité | Faible (lock-in) | Forte |
À lire aussi : Supabase, définition et fonctionnement - notre guide complet sur Supabase, la brique que nous utilisons en production.
Chez ONDEV, nous avons construit Wiloq, un SaaS de vestiaire numérique événementiel, sur Next.js et Supabase : plus de 12 fonctionnalités, 3 interfaces et une base PostgreSQL solide. Découvrez l'étude de cas Wiloq. C'est aussi ce type de stack que déploie notre agence Supabase pour les projets qui doivent durer.
FAQ : Firebase en questions
Firebase est-il vraiment gratuit ?
Firebase, c'est du frontend ou du backend ?
Firebase, c'est pour le mobile ou pour le web ?
Quelle est la différence entre Firebase et Firestore ?
Quelle est la différence entre Firebase Realtime Database et Firestore ?
Qui utilise Firebase et pour quelles applications ?
Faut-il choisir Firebase ou Supabase en 2026 ?
Conclusion : Firebase, un bon départ mais pas une évidence
Firebase est une plateforme BaaS puissante pour démarrer vite : un backend complet, du temps réel natif et zéro serveur à gérer. Mais son modèle NoSQL, sa facturation à l'usage et son lock-in Google en font un pari risqué pour un projet destiné à durer et à grandir.
La vraie question n'est pas de savoir si Firebase fonctionne, mais s'il correspond à votre horizon. Pour un prototype, foncez. Pour un produit pérenne, une alternative open source comme Supabase mérite sérieusement l'examen.
Vous démarrez une application et hésitez entre Firebase, Supabase ou une stack sur-mesure ? Ou vous avez déjà une app Firebase dont la facture grimpe ? Notre équipe conçoit des applications web sur-mesure et audite celles qui existent. Parlons de votre projet : nous vous aidons à déterminer si Firebase est le bon choix pour votre horizon, et sinon par quoi le remplacer.
