Firebase pour les applis mobiles : retour d'expérience d'un solo dev

En 2023, j'ai lancé ma première app mobile en solo - TaleMe - en misant à fond sur le duo Flutter + Firebase. Deux ans plus tard, le constat est clair : Firebase m'a permis de sortir une V1 à la vitesse de l'éclair, mais avec le recul de 2025, je vois aussi où le bât blesse.

Dans cet article, je partage mon retour d'expérience sincère de solo dev : ce que Firebase fait super bien pour développer une appli mobile, là où j'ai commencé à déchanter, et comment j'aborderais les choses différemment aujourd'hui.

Contexte : pourquoi j'ai choisi Firebase en 2023

Développeur web de formation (front et back), je me suis retrouvé en 2023 à vouloir créer TaleMe, une app mobile autour de l'IA pour raconter des histoires aux enfants. Seul à bord niveau dev, et sans expérience mobile préalable, mon objectif pour la V1 était simple : shipper vite et bien. Il me fallait les features "cœur" de l'app, un système d'authentification utilisateur sécurisé, et un paywall pour l'abonnement (histoire de valider le modèle économique). Pas question de passer des mois à réinventer la roue.

Pourquoi Firebase ? En 2023, c'était un no-brainer pour moi. Firebase cochait toutes les cases : base de données cloud temps réel, auth prête-à-l'emploi, stockage de fichiers, fonctions serveur… le tout "serverless" (zéro serveur à déployer ou maintenir) et intégré nativement avec Flutter via des plugins officiels. En prime, la généreuse offre gratuite permettait de démarrer sans frais immédiats - idéal pour un MVP. Pour la monétisation, j'ai aussi rapidement opté pour un service tiers (RevenueCat) afin d'implémenter les achats in-app sans prise de tête. Bref, avec Flutter pour le front et Firebase pour le back, toutes les briques étaient là pour me lancer à la vitesse grand V.

Spoiler: j'ai bien fait d'insister sur la vitesse : j'ai pu coder et publier une première version en à peine 4 semaines (validation store comprise) malgré mon 0 expérience mobile au départ. Mission accomplie pour la V1 ! Mais qu'en est-il sur la durée ? Entrons dans le vif du sujet : qu'est-ce que Firebase m'a apporté… et à quel prix ?

Ce que Firebase fait très bien pour une app mobile

⏩ Time-to-market imbattable

Le premier atout de Firebase, c'est d'accélérer le développement. En combinant Firebase avec Flutter, j'ai pu "bootstrap" mon appli en un temps record. Google ne survend pas l'affaire : "Integrating Firebase with your Flutter apps lets you get to market and deliver value to your users […] in less time with less effort.". Concrètement, je n'ai quasiment pas eu à coder de backend "classique". Base de données, authentification, hébergement de médias, tout est disponible on demand sous forme de services à activer. En 2023, en solo, c'était clairement le moyen le plus rapide de passer de l'idée à l'appli qui tourne. Sans Firebase (et Flutter) ça aurait pris bien plus longtemps.

🤝 Intégration Flutter et DX au top

Firebase brille aussi par son excellente intégration avec Flutter et son DX (developer experience) soigné. Les plugins officiels FlutterFire couvrent pratiquement tous les produits Firebase, avec une doc souvent bien ficelée et une communauté réactive. Je n'ai pas eu de mal à ajouter Firebase à mon projet Flutter : un coup de CLI FlutterFire, quelques configs, et j'avais accès à toute la gamme de services.

Résultat : j'ai pu me concentrer sur le code métier de mon appli, et non sur le câblage infrastructure. Le fait de rester dans l'écosystème Dart/Flutter côté client rend le dev fluide.

Certes, pour le backend (Cloud Functions), il a fallu écrire en TypeScript (j'y reviendrai), mais côté app Flutter, l'expérience développeur est très agréable. On sent que Firebase a été conçu pour qu'un dev solo ou une petite équipe puisse être productif sans lutter contre l'outil.

🧰 Suite de produits intégrés très pratiques

Autre avantage de Firebase : c'est un écosystème tout-en-un. En ajoutant Firebase, j'ai débloqué toute une panoplie de services annexes hyper utiles pour une app mobile, sans effort d'intégration supplémentaire :

• Crashlytics (rapport de crash) - Inclus d'office. J'ai pu avoir des remontées d'erreurs de prod dès le départ, crucial pour corriger les bugs rapidement. Pas besoin de brancher Sentry ou autre, tout était déjà dans la console Firebase.
• Analytics (Google Analytics for Firebase) - Pour comprendre le comportement des utilisateurs. En quelques clics j'avais des tableaux de bord sur la rétention, les écrans vus, etc. Super utile pour orienter les itérations de produit.
• Cloud Messaging (FCM) - Envoyer des push notifications gratuitement, cross-plateforme. Là encore, quelques lignes de config côté app, une fonction Cloud côté serveur, et j'ai pu notifier mes utilisateurs (par exemple pour les nouveautés).
• Remote Config / A/B Testing - La possibilité d'activer des feature flags à distance ou de tester différentes variantes d'une fonctionnalité. Même si je ne l'ai utilisé qu'à petite échelle, savoir que c'est dispo "out of the box" est rassurant pour faire évoluer l'app sans repush systématique.
• Performance Monitoring, App Distribution, etc. - Firebase offre plein d'outils bonus (perf, bêta-test, etc.) intégrés nativement. Pas tous utilisés au début de TaleMe, mais c'est un vrai confort de savoir qu'on peut les activer au besoin, sans chercher 36 services tiers.

En somme, Firebase a agi comme un « couteau suisse » du dev mobile pour moi. Pour un solo dev qui doit tout gérer, avoir tous ces outils sous la main et intégrés entre eux (ex : les crashs et analytics au même endroit, les notifications reliées à l'auth Firebase, etc.) m'a fait gagner un temps fou. Time-to-market +1, clairement.

Là où ça commence à coincer...

Évidemment, le décor n'est pas tout rose. À mesure que TaleMe est passé du statut de simple POC à celui de produit en production avec de vrais utilisateurs, j'ai découvert certaines limites et écueils de mon choix "tout Firebase". Voici les principaux points de friction rencontrés :

📦 Un POC qui devient prod (aka la dette technique du « tout Firebase »)

Au départ, j'ai structuré mon app assez simplement, façon prototype. Toute la logique tournait autour de Firestore (ma base NoSQL) et de quelques Cloud Functions. Honnêtement, sur le coup, je n'ai pas trop réfléchi architecture : Firebase encourage un peu le "plug and play". Sauf qu'avec le temps, cette approche m'a rattrapé.

Ce qui fonctionnait nickel en mode MVP s'est complexifié à mesure que j'ajoutais des fonctionnalités. La logique métier (génération d'histoires via l'IA, gestion des contenus, etc.) s'est retrouvée éclatée entre le code Flutter côté client et des Cloud Functions côté serveur. C'est le syndrome du "tout dans Firebase" : on démarre vite, mais on peut vite se retrouver avec un mélange de règles de sécurité Firestore, de triggers serverless et de code client pas très modulaire.

Pour donner un exemple concret : initialement, l'upload de fichiers (les images/vidéos générées via l'IA) se faisait direct du client vers Firebase Storage. Simple… mais insuffisant quand j'ai voulu vérifier l'utilisateur, traiter les médias côté serveur (transcription, miniature…) et appeler l'API OpenAI en sécurité. J'ai dû implémenter l'upload via une Cloud Function HTTP qui reçoit le fichier et effectue ces traitements avant de stocker le tout. Techniquement ça marche très bien (j'ai même rédigé un tutoriel à ce sujet), mais ça illustre comment un petit POC front finit par nécessiter un backend conséquent. Je me suis retrouvé à accumuler les Cloud Functions pour pallier les limites du "tout client" (et à jongler entre le code Dart de l'app et le code TypeScript des fonctions).

🔄 Cloud Functions : deux écosystèmes à maintenir

Parlons-en, des Cloud Functions Firebase. C'est une fonctionnalité géniale (déclencher du code backend sans gérer de serveur, un rêve !), mais j'ai découvert en avançant un inconvénient pour un dev Flutter : toutes les fonctions doivent être écrites en JavaScript/TypeScript (ou Python, en bêta) - pas en Dart. En clair, impossible de partager du code entre mon app Flutter et mon backend Firebase, j'ai dû maintenir deux bases de code dans deux langages différents. Quand on bosse seul, ce contexte-switch constant a un coût en vitesse et en fiabilité.

Dans mon cas je maîtrisais JS et TS, mais devoir réécrire certaines structures de données ou règles de validation en TS côté serveur, alors que je les avais en Dart côté client, c'était frustrant. Sans parler des outillages de test différents, du debug moins confortable (les logs Cloud Functions vs le debug direct sur émulateur Flutter, c'est pas la même histoire).

En bref : rajouter des Cloud Functions un peu partout a été nécessaire, mais à la longue j'ai senti poindre une dette technique et une complexité grandissante pour faire évoluer le backend.

Un POC peut devenir une « petite usine à gaz » si on n'y prend pas garde.

🗄️ Modèle NoSQL & vendor lock-in

Firebase = Firestore (NoSQL) et ça, je n'en mesurais pas totalement les impacts au début. J'étais séduit par la flexibilité du NoSQL : pas de schéma fixe, on stocke des documents JSON et on avise.

Très cool tant qu'on prototype.

Mais dès que l'app a mûri, j'ai ressenti les limitations d'une base NoSQL pour des données plus structurées. P ar exemple, j'ai dû faire des requêtes de plus en plus complexes (croiser des collections, filtrer par plusieurs champs, etc.) et Firestore n'est pas tellement fan de ça. On se retrouve à dupliquer de la donnée pour compenser l'absence de vrais joins, à multiplier les petites requêtes côté client et à gérer la cohérence nous-même.

Comme le résume la doc Supabase : « Firestore's schemaless design makes it easy to prototype. As data relationships grow more complex, you must handle joins in the client or denormalize your data. ». Tellement vrai ! Avec le recul, certaines données de TaleMe auraient sans doute mieux vécu dans une base SQL bien classique...

En parlant de Supabase, impossible de ne pas évoquer le vendor lock-in Firebase. Quand on se lance, on n'y pense pas trop ("on verra bien si ça scale").

Mais en 2025, avec une base d'utilisateurs en croissance, je réalise à quel point toute mes données et mon logique sont dépendantes de Google Firebase. Migrer ailleurs (disons vers un serveur custom ou un autre BaaS) serait un chantier colossal. Ce n'est pas qu'une vue de l'esprit : exporter des données Firestore vers une base SQL est loin d'être simple (même s'il existe des outils de migration vers Supabase ou AWS).

La dépendance à l'écosystème Firebase est réelle : API propriétaires (Firestore, FCM, etc.), règles de sécurité spécifiques... Plus le temps passe, plus "sortir" devient compliqué, donc on reste, parfois en subissant certains compromis techniques.

J'y réfléchis sérieusement aujourd'hui (d'où cet article).

💸 Coûts cachés : l'addition côté perf et budget

Dernier point, et pas des moindres : Firebase n'est pas gratuit éternellement, et sa facturation peut devenir un casse-tête mental. Au début, tout roulait dans le cadre du free tier.

Mais qui dit succès (même modeste) dit utilisation qui grimpe, et là on commence à surveiller ses lectures/écritures Firestore, invocations de Cloud Functions, stockage, bande passante, etc.

La facturation à l'usage de Firebase n'est pas toujours prévisible, et certaines mauvaises surprises sont possibles si on n'optimise pas.

Par exemple, une requête mal fichue qui multiplie les lectures de documents peut exploser le compteur. Ou un Cloud Function appelé trop souvent peut dépasser les quotas gratuits. Les retours d'expérience abondent : « Firebase's pricing can become expensive as your application scales, leading some developers to seek more cost-effective alternatives… ».

Dans mon cas, je n'ai pas (encore) explosé le budget, mais la charge mentale de toujours penser "optimisation coût" est bien là. J'ai passé du temps à peaufiner mes règles de cache, à regrouper des writes en batch, à monitorer les dashboards d'usage pour éviter la douche froide en fin de mois. Du temps non passé à développer des features.

Côté performance, j'ai aussi dû composer avec les limites de Firestore (pas de requêtes full-text, index à configurer sous peine de voir certaines queries échouer ou ramer). Et les fameuses cold boot des Cloud Functions ont ajouté de la latence sur certaines pages.

Rien d'insurmontable, mais une accumulation de petits "frottements" qui font qu'en 2025, je suis beaucoup plus conscient des coûts réels de Firebase, autant financiers que cognitifs.

Ce qui change en 2025

Deux années se sont écoulées depuis le lancement initial, et forcément ma perspective a évolué.En 2025 :

• Montée en compétences : Je ne suis plus le même dev qu'en 2023. À force de bricoler du Flutter/Firebase et de faire évoluer TaleMe, j'ai beaucoup appris sur le mobile, l'architecture d'app mobile, etc. J'ai gagné en expertise et en confiance sur des sujets qui me semblaient complexes en 2023.
• L'IA comme co-pilote : Le paysage du dev a lui aussi changé. On vit en pleine révolution AI Copilot & co - ce qui facilite la vie des devs solos. Besoin de générer un bout de code backend en Express, d'écrire un script de migration, de trouver une requête SQL ? Des agents IA peuvent nous mâcher le travail. Ce qui paraissait overkill à coder from scratch en 2023 l'est moins en 2025, parce qu'on est mieux outillés.
• Nouvelles priorités : testabilité, portabilité, robustesse : Avec le recul, j'attache plus d'importance à certains aspects "architecturaux". Par exemple, la testabilité - en 2023 je testais peu mes Cloud Functions (pas simple à mocker le Firestore), maintenant je rêve d'un backend où je peux écrire des tests unitaires et d'intégration facilement. Idem pour la portabilité et la robustesse : j'ai vu les limites du lock-in et des solutions trop propriétaires, donc j'aspire à des choix techniques plus ouverts (base de données SQL standard, possibilité de déployer sur un autre cloud, etc.). En somme, je cherche à construire des bases plus pérennes et maintenables, quitte à sacrifier un peu la rapidité initiale. C'est l'éternel compromis dev : ce qui fait gagner du temps au départ peut en faire perdre plus tard.

En résumé, mon regard a changé : Firebase reste un super outil, mais je le vois désormais comme une brique parmi d'autres, à utiliser sciemment dans une architecture réfléchie, plutôt que comme un package "magique" qui ferait tout tout seul sans conséquences.

À partir de là, quelles sont mes recommandations en 2025 pour un solo dev mobile qui doit choisir sa stack ?

Mes recommandations actuelles (solo dev en 2025)

Si je devais conseiller un développeur indépendant qui se lance aujourd'hui dans une appli mobile, voilà comment j'aborderais la stack backend :

Option 1 : Combo Firebase + backend dédié (meilleur des deux mondes)

C'est probablement l'architecture que j'adopterais pour tout nouveau projet un peu ambitieux. L'idée : utiliser Firebase pour ce qu'il fait de mieux, et déléguer le reste à un backend "maison" (ou un micro-service dédié). En pratique, on peut par exemple garder Firebase Auth (tellement pratique à intégrer et robuste), Cloud Messaging (pour les push) et pourquoi pas Crashlytics/Analytics.

Mais pour la logique métier avancée, les traitements sensibles (appel à des API tierces comme OpenAI, calculs complexes, etc.) et la gestion fine des données, je déploierais un petit backend API REST/GraphQL séparé.

Ça peut être un serveur Node/Express, du NestJS, du Python FastAPI, peu importe - l'important est d'avoir la liberté de coder proprement la logique sans les contraintes des Cloud Functions.

Ce backend pourrait utiliser une base de données SQL classique ou tout autre storage adapté aux besoins.

Firebase et ce backend communiqueraient via des appels HTTPS ou autre. Oui, ça demande un peu plus de travail qu'un full Firebase... mais ça évite de tordre Firebase dans tous les sens pour des choses pour lesquelles il n'est pas optimal.

On garde le time-to-market sur les briques génériques grâce à Firebase, tout en ayant la maîtrise complète sur le cœur métier. En solo en 2025, c'est tout à fait jouable grâce aux outils modernes (on peut prototyper une API en quelques jours maintenant, avec l'aide des AI notamment).

Option 2 : Supabase (ou autre BaaS SQL) pour un backend plus ouvert

Autre choix pertinent en 2025 : se tourner vers un BaaS alternatif à Firebase, basé sur SQL. Le principal candidat est Supabase, qui reproduit l'expérience Firebase (auth, stockage, fonctions serverless, realtime…) mais sur une base PostgreSQL open-source. Supabase offre en gros "les mêmes services - auth, storage, temps réel, functions - mais avec la prévisibilité du SQL et la liberté du self-hosting".

Dit autrement, on bénéficie d'un schéma relationnel classique (donc requêtes puissantes, joints, transactions ACID, etc.), on peut héberger la solution soi-même si on veut (pas de lock-in propriétaire), et on garde des features comparables (abstraction temps réel, API auto-générée, etc.).

Pour un solo dev qui démarre, Supabase peut être un excellent compromis : on retrouve la simplicité d'un BaaS sans certaines limites de Firebase. Bien sûr, il faut être plus à l'aise avec SQL qu'avec NoSQL, et l'écosystème Supabase est un peu moins mature (plus jeune, plus petit que Firebase). Mais honnêtement, la courbe d'apprentissage du SQL/Postgres en vaut la chandelle dès qu'on a des données un tant soit peu structurées.

Il existe d'autres BaaS similaires (Appwrite, PocketBase, Parse... voire les solutions cloud des grands comme AWS Amplify), mais Supabase est celui qui ressort le plus aujourd'hui pour remplacer Firebase dans le cœur des devs. En 2025, je le testerais sérieusement si je repartais de zéro sur TaleMe - ne serait-ce que pour éviter le lock-in et bénéficier d'une base de données relationnelle dès le départ.

Option 3 : Rester sur Firebase, mais découpler proprement

Et si malgré tout vous voulez profiter à fond de Firebase (après tout, son intégration avec Flutter reste excellente, et pour une petite app on peut très bien vivre avec ses contraintes), je conseillerais de le faire en anticipant l'avenir. Cela signifie : découpler au maximum votre code métier de Firebase lui-même.

Concrètement, même en restant sur Firestore et Cloud Functions, on peut adopter des bonnes pratiques d'architecture : utiliser des dépôts/repositories dans l'app Flutter pour isoler les appels Firebase (au lieu de disperser des .doc().get() partout dans le code UI), structurer ses Cloud Functions de manière modulaire (éviter une seule grosse function de 1000 lignes qui fait tout), écrire des tests unitaires avec l'Emulator Suite Firebase pour valider ses règles de sécurité et ses fonctions, etc.

Le but est de rendre possible (ou moins pénible) un éventuel changement plus tard. Par exemple, si votre couche d'accès aux données est bien isolée, migrer de Firestore à Postgres ne demandera de modifier que cette couche, pas toute l'app.

Idem, si votre logique métier est dans des fonctions bien encapsulées, vous pourriez décider de les réimplémenter sur un autre backend sans devoir tout réécrire. En somme, "rester sur Firebase n'implique pas de s'y enfermer". C'est un piège classique de foncer tête baissée et de coller Firebase partout dans son code. En 2025, avec l'expérience, j'essaierais de penser mon architecture propre dès le départ même sur Firebase : un peu de conception aujourd'hui pour beaucoup de liberté demain.

Ce que je ferais différemment pour TaleMe (si c'était à refaire)

Pour être très concret, si je pouvais remonter le temps et conseiller le moi de 2023 sur le projet TaleMe, voici ce que je changerais (et garderais) concernant Firebase :

Ce que je garderais sans hésiter :

• Firebase Authentication - C'est un énorme time-saver et c'est ultra fiable. Gérer l'inscription, la connexion (email, Google, Apple…), la récupération de mot de passe, etc., tout cela moi-même aurait été une perte de temps et une prise de risque en sécurité. Firebase Auth fait le job à la perfection, je le reprendrais en 2025.
• Crashlytics & Analytics - Indispensables pour toute app en prod. Intégrés gratuitement, ces services m'ont permis de détecter les crashes (Crashlytics) et de comprendre l'usage (Analytics) facilement. Je les considérerais comme des must-have quel que soit le backend.
• Flutter + Firebase (intégration client) - Le SDK FlutterFire côté client est bien maintenu et permet d'exploiter la puissance de Firebase avec très peu de code. Si j'ai besoin de temps réel (par ex, synchroniser des données live entre utilisateurs) ou de stocker des données simples, Firestore reste très pratique via Flutter. Idem pour Firebase Cloud Messaging (push notifications) que je n'hésiterais pas à réutiliser via FlutterFire.

Ce que je changerais ou éviterais :

• Éviter de tout baser sur Firestore pour les données structurées : Si c'était à refaire, j'introduirais probablement une base SQL dès que les données de l'app deviennent relationnelles (par ex : les utilisateurs, histoires, chapitres, etc. avec des relations). Quitte à maintenir deux bases (Firestore pour du temps réel sur certaines petites données et Postgres pour le reste), ou à tout mettre sur une base type Supabase. L'objectif : ne pas subir les limitations de requêtage et de structure de Firestore sur le long terme.
• Ne pas mettre toute la logique dans des Cloud Functions : J'opterais pour un backend séparé (même léger) pour codifier la logique métier complexe. Par exemple, la génération d'histoires via l'IA, j'aurais pu la développer dans une petite API Node ou Deno distincte, appelée depuis l'app, plutôt que de la caser dans une Cloud Function Firebase. Ça m'aurait donné plus de contrôle (déploiement indépendant, test unitaire possible, etc.) et évité de mélanger NodeJS et Dart dans le même projet.
• Anticiper l'architecture dès la V1 : En 2023, j'ai un peu fait l'impasse dessus ("YOLO, on ship et on verra plus tard"). En 2025, je me forcerais à définir quelques guidelines d'architecture dès le début : modules clairs, séparation des responsabilités entre frontend et backend, plan de tests, stratégie de sécurité et validations, etc. Pas besoin d'y passer des mois, mais quelques jours de réflexion. En somme : le problème n'était pas Firebase en soi, mais le fait de l'utiliser sans vraie architecture derrière.

Conclusion

En rétrospective, Firebase n'a pas été le « problème »: c'était même la solution idéale pour lancer TaleMe rapidement et valider le concept.

Ses bénéfices (vitesse de développement, services intégrés, scalabilité automatique) ont clairement permis à un solo dev d'atteindre ses objectifs de V1.

Par contre, ce que j'ai appris, c'est que ne pas faire de choix d'architecture est un choix en soi... et souvent le mauvais. En m'abandonnant un peu trop au confort de Firebase, j'ai accumulé de la dette technique et des contraintes qui auraient pu être évitées avec un peu plus de recul.

La bonne nouvelle, c'est qu'en 2025 nous avons plus d'options que jamais pour construire nos backends mobiles : on peut mixer les services Firebase avec du sur-mesure, on peut opter pour des alternatives comme Supabase pour retrouver le contrôle du SQL, on peut profiter de l'IA pour nous aider à coder plus efficacement…

L'important est de garder en tête la pérennité de l'application : Firebase est un excellent accélérateur, à condition de savoir freiner à temps et construire des bases solides autour.

Et vous, quelle est votre expérience avec Firebase (ou ses alternatives) ? Avez-vous aussi connu le syndrome du MVP "100% Firebase" qu'on doit refactorer ensuite, ou au contraire tout s'est bien passé ? Partagez vos retours en commentaire, ça m'intéresse !