Firebase pour une application mobile, ce qu'il couvre et où il s'arrête
Un prestataire vous propose Firebase et le devis baisse. Le produit est bon, la question n'est pas là : elle est dans ce qu'il prend en charge à votre place, dans ce qu'il vous facturera le jour où l'application marchera, et dans ce qu'il faudra construire à côté de lui. Voici ce que nous en savons pour l'avoir mis en production sur des applications Flutter et React Native.
Firebase, c'est quoi concrètement ?
Firebase est un ensemble de services gérés par Google que votre application appelle directement : identification des utilisateurs, base de données, stockage de fichiers, notifications push, rapports de plantage. Aucun serveur à louer, aucun code de serveur à écrire au départ. L'application parle à Google, et Google facture à l'usage.
Les morceaux portent des noms qui reviennent dans tous les devis. Firebase Authentication pour les comptes, Cloud Firestore pour la base, Cloud Storage pour les fichiers, Cloud Messaging pour les notifications, App Check pour écarter les requêtes qui ne viennent pas de votre application, Crashlytics pour les plantages, Cloud Functions pour le code qui doit tourner ailleurs que sur le téléphone.
Firestore mérite d'être isolé, parce que c'est lui qui commande le reste. C'est une base de documents et non de tables : les données y sont rangées comme les écrans les affichent, l'application reçoit les changements en direct, et elle garde un cache local qui la fait fonctionner sans réseau. Cette dernière propriété pèse lourd sur un métier de terrain.
Les comparatifs français s'arrêtent à peu près là et concluent sur le même couple : développement plus rapide d'un côté, dépendance à Google de l'autre. Les deux sont exacts. Ni l'un ni l'autre ne vous dit quoi signer.
Ce que Firebase couvre sur les applications que nous avons livrées
Daiky est le cas le plus complet de notre portefeuille. L'application est en Flutter, publiée sur l'App Store, et elle rend lisible la composition d'un cosmétique en une trentaine de secondes. Firebase y porte l'authentification, Firestore, le stockage, les notifications et App Check, à côté d'un module caméra et d'une bibliothèque de lecture de codes-barres. Deux décisions y ont été prises au premier jour plutôt qu'au dernier : App Check, parce qu'une application qui expose une analyse attire les usages automatisés et qu'il coûte bien plus cher de fermer la porte après coup, et la double langue française et anglaise, posée avant la première version.
AquaPro Manager montre le cas B2B. Une application Flutter pour les techniciens en tournée, un back-office Next.js pour les gérants, une seule base Firestore dessous. La connexion se fait par code à usage unique, les rôles séparent le gérant du technicien, App Check filtre les requêtes, et la plateforme suit plus de 500 interventions par mois. Le mode hors ligne se synchronise automatiquement au retour du réseau, ce qui est l'argument le plus lourd de Firestore sur ce type de métier.
Voici ce que nous avions tendance à sous-évaluer sur ce montage. Sur une architecture double comme celle-là, un champ renommé dans Firestore se répercute dans l'application Flutter, dans le back-office Next.js et dans les règles de sécurité. Firestore n'impose aucun schéma, donc aucune de ces trois répercussions n'échoue à la compilation. Elles se voient à l'exécution, chez l'utilisateur, ou pas du tout.
Firebase n'est lié à aucun framework mobile, et MamaSafe Food le montre. Cette application est en React Native avec Expo, publiée sur Google Play, et elle utilise Firebase pour l'authentification et le stockage. Le choix du framework et celui du socle de données se prennent séparément, et pas le même jour.
Sur ces trois produits, le partage réel ressemble à ceci.
| Besoin | Service Firebase | Ce que nous avons ajouté |
|---|---|---|
| Comptes et connexion | Firebase Authentication | Rien |
| Base de données, temps réel, hors ligne | Cloud Firestore | Les règles de sécurité, écrites à la main |
| Images et fichiers | Cloud Storage | Rien |
| Notifications push | Cloud Messaging | Rien |
| Filtrage des requêtes illégitimes | App Check | Rien |
| Paiements et abonnements | Aucun | Stripe, sur AquaPro Manager |
| Lecture de codes-barres | Aucun | Module caméra et bibliothèque de lecture |
| Back-office de gestion | Aucun | Web app Next.js, sur AquaPro Manager |
Notre recommandation se lit dans la troisième colonne. Quand l'application est le produit et que les données suivent la forme des écrans, Firebase fait gagner des semaines et nous le prenons sans discuter. Quand l'application n'est qu'une fenêtre sur un système d'information qui existe déjà, il devient un intermédiaire de plus entre vos données et vos utilisateurs, et nous le déconseillons.
Combien coûte Firebase pour une application mobile ?
Rien jusqu'à un seuil, puis à l'usage. Le plan sans frais annonce 1 Gio de données stockées dans Firestore, 50 000 lectures et 20 000 écritures de documents par jour, et 50 000 utilisateurs actifs mensuels sur Authentication (grille tarifaire Firebase). Au-delà, la facture suit les lectures de documents.
L'unité de facturation est la lecture d'un document, et c'est là que les projets dérapent. Un écran qui affiche une liste de quarante interventions coûte quarante lectures chaque fois qu'il s'ouvre, pas une. Dix techniciens qui consultent leur planning quinze fois par jour, cela fait six mille lectures quotidiennes pour un seul écran. Le seuil sans frais tient encore à cette échelle. Il ne tiendra plus quand l'équipe passera à cinquante personnes, ou quand le même écran affichera aussi l'historique du client.
Deux autres lignes surprennent au moment de la première facture. Cloud Functions n'est pas disponible sur le plan sans frais, que la grille donne comme non applicable sur toutes ses métriques : la première fonction serveur fait passer le projet au plan à l'usage. Et la connexion par code à usage unique, celle d'AquaPro Manager, repose sur des SMS facturés au message envoyé, donc sur un coût qui croît avec le nombre de connexions et non avec le nombre de comptes.
C'est le poste que nous écrivons désormais séparément dans un chiffrage, parce qu'il ne se devine pas en regardant des maquettes. Compter les lectures d'un écran avant de le dessiner change le dessin de l'écran, et c'est bien le but.
Où Firebase s'arrête, et ce qu'il faut lui ajouter
Les paiements d'abord. Firebase n'a aucun produit de paiement, et l'abonnement d'AquaPro Manager passe donc par Stripe, avec ses deux plans et les obligations PCI DSS qui vont avec. Cette frontière est nette et connue d'avance, elle ne pose de problème que dans les devis qui l'oublient.
Les règles métier ensuite. Tout ce qui ne doit pas être inspectable depuis un téléphone part dans des Cloud Functions, donc côté serveur, donc sur le plan payant. Une application qui calcule un prix, applique une remise ou vérifie un quota a besoin de ce morceau. Il se conçoit et se teste comme du back-end, parce que c'en est.
Et puis il y a les projets où nous ne prenons pas Firebase. Quand un client a besoin d'une API documentée et versionnée que d'autres outils viendront consommer, avec des droits d'accès fins par rôle, nous écrivons un back-end. Sur Cockpit, un tableau de bord de pilotage marketing, la refonte est partie sur API Platform en Symfony, avec OAuth2 et des objets de contrôle d'accès par rôle utilisateur. Aucun de ces besoins ne se satisfait en assemblant des services gérés.
Reste une limite dont on ne parle jamais avant de signer : un produit Firebase peut fermer. Firebase Dynamic Links, qui fabriquait les liens de partage et de parrainage des applications, s'est arrêté le 25 août 2025, et la page officielle de l'arrêt ne laisse aucune place au doute : « All links served by Firebase Dynamic Links (both hosted on custom domains and page.link subdomains) will stop working » (questions fréquentes sur l'arrêt de Dynamic Links, Firebase). Les sous-domaines page.link ont disparu avec le service. Depuis, nous ne plaçons plus une URL dont dépend l'activité d'un client à l'intérieur d'un produit dont nous ne maîtrisons pas le cycle de vie. C'est la seule chose que nous déconseillons sans nuance dans tout cet ensemble.
Firebase est-il compatible avec le RGPD ?
Oui, à des conditions dont une ne se négocie pas. Vous êtes responsable du traitement, Google est sous-traitant et l'encadrement passe par ses conditions de traitement des données. Firestore, le stockage de fichiers et les fonctions se rattachent à un emplacement que vous choisissez. Firebase Authentication, lui, est traité aux États-Unis, et cela ne se paramètre pas.
La page de Google sur la confidentialité dans Firebase l'écrit en deux phrases : « The Firebase Authentication service is run only from US data centers. As a result, Firebase Authentication processes data exclusively in the United States. » (confidentialité et sécurité dans Firebase, Google). Adresses de courriel, numéros de téléphone : la partie identité de votre application est traitée hors de l'Union. Il faut donc la déclarer comme un transfert et l'encadrer, ce que détaille notre checklist RGPD pour le développement web.
La base de données, elle, se choisit. Firestore propose l'emplacement multirégional eur3, dont les régions d'écriture sont en Belgique et aux Pays-Bas, et des emplacements régionaux parmi lesquels europe-west9 à Paris. La documentation prévient juste en dessous : « once you provision a database instance, you cannot change its location setting » (emplacements Cloud Firestore, Firebase). Une base créée par défaut aux États-Unis ne se déplace donc pas. Elle se recopie dans une base neuve, avec la coupure de service et la reprise de données que cela suppose.
Ce que nous recommandons tient en deux gestes. Créer la base dans eur3 ou à Paris, au premier jour, avant le premier écran. Et ne jamais écrire à un client que ses données sont en Europe quand l'identification de ses utilisateurs, elle, ne l'est pas. Nous ne pouvons pas répondre oui à une entreprise qui exige que toutes les données personnelles de ses utilisateurs soient traitées dans l'Union : avec Firebase Authentication la réponse est non, et nous la donnons avant le devis plutôt qu'à la recette.
Questions fréquentes
Faut-il un développeur back-end sur un projet Firebase ?
Peut-on quitter Firebase plus tard ?
Firebase convient-il à une application métier avec plusieurs rôles ?
Les données de mon application seront-elles en Europe avec Firebase ?
Avant de signer, posez trois questions à l'équipe en face de vous. Combien de lectures de documents coûte l'écran d'accueil de l'application. Dans quelle région la base sera créée. Et ce qui, dans le périmètre annoncé, n'est couvert par aucun service Firebase et devra donc être écrit. Quelqu'un qui a déjà mis Firebase en production répond aux trois sans rouvrir la documentation.
Si la réponse à la deuxième question est « par défaut », faites-la reprendre. C'est le seul paramètre de cette liste qu'on ne corrige pas plus tard, et celui qui vous engage le plus longtemps. Nous arrêtons ces trois choix au cadrage et nous les écrivons dans la proposition, y compris quand le socle retenu est un ensemble de services gérés plutôt qu'un serveur que nous écrivons : c'est le travail que couvre notre service de backend sur-mesure.
