Trois outils, trois cas d'usage
La question revient souvent lors des phases de cadrage : "Pourquoi Firebase et pas autre chose ?" La réponse n'est pas dogmatique. Elle dépend du projet, du profil du client, des contraintes de déploiement et du budget de maintenance.
Voici comment je raisonne.
Firebase : mon choix par défaut pour les TPE et PME
Firebase est une plateforme Google qui regroupe plusieurs services : Firestore (base de données NoSQL temps réel), Authentication, Hosting, Storage, Cloud Functions. L'ensemble est géré : pas de serveur à maintenir, pas de mise à jour d'infrastructure, pas de sauvegarde manuelle.
Pour une TPE, c'est un avantage décisif. Le gérant d'une onglerie ou d'un salon ne veut pas qu'on lui appelle à 23h parce que le serveur est tombé. Firebase gère ça pour lui, avec un uptime garanti par Google.
Autres points forts concrets :
- Mode hors-ligne natif : l'application fonctionne même sans connexion et synchronise dès que le réseau revient. Utile pour des agents sur le terrain ou des zones avec couverture variable.
- Synchronisation temps réel : un tableau de bord admin voit les données se mettre à jour sans recharger la page. Utile pour le suivi de commandes ou de disponibilités.
- Authentication intégrée : gestion des comptes, réinitialisation de mot de passe, connexion Google ou Apple, sans développer de système maison.
- Pricing à l'usage : le plan gratuit couvre largement les besoins d'une application jusqu'à quelques centaines d'utilisateurs actifs par mois. La montée en charge se paye à l'usage, sans migration d'infrastructure.
Les limites existent : le modèle NoSQL de Firestore impose de structurer les données différemment d'une base relationnelle. Les requêtes complexes (jointures, agrégations avancées) sont plus difficiles à écrire. Et si Google décidait de fermer Firebase (peu probable mais théorique), la migration serait coûteuse.
Supabase : quand j'ai besoin de SQL et d'open source
Supabase est souvent présenté comme "le Firebase open source". La comparaison est partiellement juste. Supabase repose sur PostgreSQL, offre une API REST auto-générée, un système d'authentification, du stockage de fichiers et des fonctions edge.
Je choisis Supabase dans deux cas principaux :
- Le projet requiert des requêtes SQL complexes : rapports financiers, croisements de données, exports structurés. PostgreSQL est ici bien supérieur à Firestore.
- Le client tient à l'open source et veut pouvoir s'auto-héberger. Supabase peut tourner sur un VPS Hetzner ou OVH, ce qui élimine la dépendance à Google.
La contrepartie : Supabase auto-hébergé demande une gestion d'infrastructure. Mises à jour, sauvegardes, supervision : c'est un travail qui s'ajoute. Pour un client sans équipe technique, c'est un risque. Pour un client avec un développeur interne ou une tolérance aux coûts de maintenance, ça peut valoir le coup.
PostgreSQL sur VPS : pour les projets avec des exigences spécifiques
Un Postgres géré directement sur un VPS (Hetzner, OVH, Scaleway), combiné à un backend Node.js ou Python, c'est la solution la plus flexible et souvent la moins chère à long terme. Aucune dépendance à un service tiers, contrôle total sur le modèle de données, performances prévisibles.
Je recommande cette stack dans des cas précis :
- Un projet avec des volumes de données importants et des besoins de performance fine.
- Un client qui a déjà une équipe ou un DevOps capable de gérer l'infrastructure.
- Un projet qui doit s'intégrer dans un système d'information existant (ERP, logiciel métier sur serveur interne).
Ce n'est pas la bonne option pour une TPE qui n'a pas de ressource technique interne. Le coût de maintenance d'une infrastructure maison dépasse rapidement les économies réalisées sur la licence.
Le tableau de décision que j'applique
Voici la grille de lecture que j'utilise en phase de cadrage :
- Pas de ressource technique en interne, projet standard : Firebase.
- Besoin de SQL, client sensible à l'open source, tolérance à l'infrastructure : Supabase.
- Volume de données important, équipe technique, intégration SI existant : PostgreSQL sur VPS.
- Prototypage rapide, budget très contraint : Firebase sur plan gratuit, avec possibilité de migrer ensuite.
Ce que le client retient
La plupart des clients ne veulent pas choisir la base de données. Ils veulent une application qui fonctionne, qui ne tombe pas, dont les données sont sécurisées et sauvegardées. C'est le bon état d'esprit.
Mon rôle est de faire ce choix à leur place, en le justifiant clairement, et en leur expliquant les implications concrètes pour la maintenance et l'évolution future du projet. Le choix technique n'est pas une fin en soi, c'est un moyen au service de l'objectif métier.