Firebase pour votre app mobile : bonne idée ?

Firebase, c'est la plateforme backend de Google pour les apps mobiles. Authentification, base de données, stockage de fichiers, notifications push, analytics, hosting… Tout est intégré, tout est managé. Pas de serveur à gérer, pas d'infra à configurer. Sur le papier, c'est le rêve. Et dans beaucoup de cas, ça l'est vraiment.

Ce que Firebase fait très bien

L'authentification

C'est probablement le meilleur service de Firebase. En quelques lignes de code, vous avez un système de connexion complet : email/mot de passe, Google, Apple, numéro de téléphone. C'est robuste, sécurisé, et ça gère les cas tordus (vérification d'email, reset de mot de passe, linking de comptes) sans que vous ayez à y penser.

Firestore (la base de données)

Firestore est une base NoSQL temps réel. Le "temps réel" est le mot clé : vos données se synchronisent automatiquement entre le serveur et l'app. Quand un utilisateur modifie quelque chose, les autres le voient instantanément. C'est parfait pour les apps collaboratives, les chats, les dashboards live.

Les notifications push

Firebase Cloud Messaging (FCM) est gratuit et illimité. On envoie des notifs à des millions d'utilisateurs sans payer un centime. L'intégration avec Flutter est simple et bien documentée.

Les limites à connaître

Le coût peut exploser

Firebase est gratuit pour commencer (plan Spark), mais la facturation à l'usage peut surprendre. Firestore facture à la lecture/écriture de document. Si votre app fait beaucoup de requêtes (une liste qui se rafraîchit souvent, des listeners un peu trop gourmands), la facture grimpe vite. On a vu des projets passer de 0 à 500 €/mois en quelques semaines après un lancement réussi.

Le NoSQL n'est pas toujours adapté

Firestore est une base NoSQL. C'est génial pour des structures de données simples et des lectures rapides. Mais si votre app a besoin de jointures complexes, de requêtes avec beaucoup de filtres, ou d'agrégations poussées, vous allez galérer. Dans ces cas, une base SQL classique (PostgreSQL par exemple) est souvent plus adaptée.

Le vendor lock-in

C'est le point qui fait le plus débat. Quand vous construisez sur Firebase, vous êtes dépendant de Google. Migrer vers un autre système plus tard, c'est possible mais c'est un chantier. C'est un compromis à accepter en connaissance de cause.

Quand on le recommande

Chez Alpaga, on utilise Firebase sur la majorité de nos projets. C'est notre stack par défaut pour les apps qui ont besoin d'un backend rapidement, sans infrastructure lourde. Les cas où ça fonctionne le mieux :

Apps avec authentification et données utilisateurs
MVPs et premières versions qui doivent sortir vite
Apps avec des fonctionnalités temps réel (chat, collaboration)
Projets où le budget infra doit rester bas au démarrage

Et Supabase dans tout ça ?

Supabase est souvent présenté comme l'alternative open-source à Firebase. Concrètement, c'est une couche de services (auth, stockage, fonctions) construite autour de PostgreSQL. Et c'est là que ça devient intéressant : vous avez une vraie base SQL, avec des jointures, des vues, des index, des migrations. Tout ce que Firestore ne fait pas bien.

Chez Alpaga, on utilise Supabase quand le projet a besoin de requêtes complexes ou d'un modèle de données relationnel. C'est aussi un bon choix quand le client veut éviter le vendor lock-in de Google, puisque Supabase peut tourner en self-hosted. L'authentification est solide, le dashboard est clair, et l'intégration avec Flutter se fait bien.

En revanche, Supabase n'a pas d'équivalent aux notifications push de Firebase (FCM), et le temps réel est moins mature que Firestore sur les cas d'usage type chat. C'est un outil complémentaire, pas un remplacement universel.

Quand on part sur un backend custom

Pour des apps avec de la logique métier complexe, des calculs côté serveur, ou des besoins très spécifiques, ni Firebase ni Supabase ne suffisent. Dans ces cas, on développe un backend sur-mesure en Go ou en Node.js, selon le contexte.

On peut aussi combiner les approches : Firebase pour l'auth et les notifications push, avec un backend Go pour la logique métier. Ou Supabase pour la base de données, avec des fonctions serverless pour les traitements lourds. L'idée c'est de choisir le bon outil pour chaque besoin, pas de tout faire rentrer dans un seul service.