Quand on commence un projet sur FlutterFlow, Firebase s'impose comme la réponse évidente. C'est l'intégration native, bien documentée, et ça marche en dix minutes. Sauf que passé le prototype, Firebase devient vite un problème : coûts imprévisibles, pas de requêtes SQL, impossible de s'auto-héberger, et des règles de sécurité qui deviennent rapidement ingérables.
Supabase règle la plupart de ces problèmes. C'est un backend open source construit sur PostgreSQL, qui donne accès à une vraie base relationnelle, à une authentification complète, à du temps réel et au stockage de fichiers. Plus de 4 millions de développeurs l'utilisent aujourd'hui, dont des entreprises comme PwC, McDonald's et GitHub Next. Sa valorisation a atteint 5 milliards de dollars en octobre 2025 (TechCrunch).
FlutterFlow supporte Supabase nativement. Voilà comment ça fonctionne et pourquoi ça vaut la peine de choisir cette combinaison dès le départ.
Supabase vs Firebase : ce qui change concrètement
Firebase stocke les données dans Firestore, une base de documents NoSQL. Ça fonctionne bien pour les cas simples, mais dès que les données ont des relations, les requêtes deviennent complexes et coûteuses. Supabase utilise PostgreSQL, le moteur de base de données relationnelle le plus utilisé au monde. Vous écrivez du SQL, vous faites des jointures, vous définissez des contraintes de clés étrangères - c'est prévisible.
Autre différence importante : le prix. Firebase facture par lecture, écriture et suppression. Sur une application avec du volume, la facture grimpe vite et devient difficile à anticiper. Supabase facture par instance, avec des paliers fixes. Pour la plupart des projets, le tier gratuit (500 Mo de données, 5 Go de bande passante) suffit pour valider un MVP.
Enfin, Supabase est open source - le code est sur GitHub avec 99 000 étoiles. Vous pouvez l'auto-héberger sur votre propre serveur si nécessaire. Avec Firebase, vous êtes entièrement dépendant de Google.
Ce que l'intégration FlutterFlow-Supabase débloque
FlutterFlow se connecte à Supabase via l'API REST que Supabase génère automatiquement pour chaque table. Une fois le projet configuré, FlutterFlow lit le schéma et propose vos tables directement dans l'éditeur visuel. Concrètement, vous pouvez :
- Lire et écrire des données depuis n'importe quel composant, sans écrire une ligne de code backend
- Activer le temps réel sur une table - les données se mettent à jour dans l'app sans que l'utilisateur recharge
- Utiliser l'authentification Supabase (email/mot de passe, Google, Apple, GitHub) directement dans les flux FlutterFlow
- Stocker et servir des fichiers via Supabase Storage, accessible depuis les widgets image de FlutterFlow
Le temps réel mérite un point particulier. FlutterFlow se connecte aux WebSockets de Supabase et reçoit les changements en push. Pour une app de messagerie, un tableau de bord collaboratif ou un suivi de commandes en direct, c'est du natif sans configuration supplémentaire.
Configuration pas à pas
La connexion prend moins de cinq minutes. Dans FlutterFlow, allez dans Settings & Integrations, puis Supabase. Vous avez besoin de deux informations disponibles dans votre projet Supabase sous Project Settings > API :
- L'URL du projet (format
https://[id].supabase.co) - La clé publique anon (la clé anonyme, sans droits d'administration)
Une fois ces deux valeurs collées dans FlutterFlow, cliquez sur "Get Schema". FlutterFlow lit automatiquement toutes vos tables et leurs colonnes. Chaque table devient une source de données que vous pouvez brancher sur n'importe quel widget ou liste.
Pour l'authentification, activez Supabase Auth dans FlutterFlow et sélectionnez les providers que vous voulez. Supabase gère le token JWT, FlutterFlow stocke la session côté client. Vous n'avez rien de plus à configurer pour que les utilisateurs restent connectés entre les sessions.
Un point pratique : si vous créez de nouvelles tables dans Supabase après la configuration initiale, il suffit de cliquer à nouveau sur "Get Schema" pour synchroniser le schéma. FlutterFlow met à jour sa liste sans toucher aux widgets existants.
La sécurité avec Row Level Security
C'est l'une des fonctionnalités les plus importantes à comprendre avant de mettre une app en production. Par défaut, Supabase donne accès à toutes les données via l'API à quiconque possède votre clé anon. La clé anon est publique - elle est dans votre app FlutterFlow, donc potentiellement visible.
La solution s'appelle Row Level Security (RLS). Vous activez RLS sur une table et définissez des politiques SQL qui contrôlent qui peut lire ou modifier chaque ligne. Par exemple, pour une table orders, une politique simple dit que chaque utilisateur ne voit que ses propres commandes :
CREATE POLICY "users_see_own_orders"
ON orders FOR SELECT
USING (auth.uid() = user_id);Quand un utilisateur fait une requête via FlutterFlow, Supabase vérifie automatiquement cette politique avant de renvoyer les données. L'utilisateur A ne verra jamais les commandes de l'utilisateur B. FlutterFlow respecte ces politiques sans configuration supplémentaire côté front-end.
Activer RLS est obligatoire sur toute table qui contient des données utilisateur. C'est le premier réflexe à avoir avant le premier déploiement.
Les limites à connaître
L'intégration fonctionne bien, mais quelques points méritent attention avant de s'engager.
Les Edge Functions de Supabase (des fonctions serverless écrites en TypeScript) ne sont pas accessibles directement depuis FlutterFlow. Si vous avez besoin de logique métier côté serveur - calculs, webhooks, appels à des APIs tierces - vous devrez passer par les API Routes de FlutterFlow ou par un outil comme n8n en intermédiaire. Ce n'est pas bloquant, mais ça demande une architecture un peu plus réfléchie.
Supabase a aussi annoncé des changements sur les projets gratuits fin 2025 : les projets inactifs sont mis en pause après une semaine. Pour un projet de production, il faut basculer sur un plan payant (minimum 25 dollars par mois). C'est largement raisonnable pour une vraie app, mais à prévoir dans le budget.
Enfin, le temps réel Supabase fonctionne bien pour des volumes modérés. Au-delà de quelques centaines de connexions simultanées, il faut surveiller les limites de connexions PostgreSQL et potentiellement ajuster la configuration. Ce n'est pas un problème pour 90 % des projets FlutterFlow, mais c'est à garder en tête pour une app grand public.
Quel type d'app profite le plus de cette combinaison ?
FlutterFlow + Supabase est particulièrement adapté aux applications qui ont des données relationnelles. Une app de gestion de projets, un marketplace, une plateforme de réservation, un outil CRM mobile : dès que vos entités ont des relations entre elles (un utilisateur a plusieurs projets, chaque projet a plusieurs tâches), PostgreSQL gère ça naturellement. Firestore vous forcerait à dupliquer des données ou à multiplier les lectures.
C'est aussi le bon choix si vous avez des contraintes de souveraineté des données. Supabase propose des régions EU (Francfort, Irlande). Vous restez dans l'espace européen, avec des données soumises au RGPD, sans dépendre de Firebase qui passe par les serveurs de Google aux États-Unis.
Si vous cherchez à créer un MVP rapidement sur Flutter, cette combinaison vous permettra de valider votre idée sans dette technique. Le backend Supabase peut évoluer : vous pouvez ajouter des tables, modifier le schéma, écrire des fonctions SQL avancées sans toucher à votre code FlutterFlow. Quand votre app grandit et que vous décidez d'écrire du Flutter natif, Supabase reste le même backend.
Pour aller plus loin sur FlutterFlow, lisez notre article sur créer une application mobile pour votre entreprise avec FlutterFlow. Si vous hésitez entre Supabase et d'autres options de backend no-code, notre comparatif Xano vs Supabase couvre les deux en détail.
Vous voulez déployer un backend Supabase pour votre app FlutterFlow ? Parlons de votre projet - nos développeurs maîtrisent les deux outils et peuvent vous aider à démarrer ou reprendre un projet en cours.
Questions fréquentes
FlutterFlow peut-il utiliser Supabase à la place de Firebase pour l'authentification ?
Oui, complètement. FlutterFlow supporte nativement l'authentification Supabase : email/mot de passe, magic link, et OAuth via Google, Apple, GitHub et d'autres providers. La session est gérée automatiquement par le SDK Supabase intégré dans le code Flutter généré.
Le temps réel Supabase fonctionne-t-il dans les apps FlutterFlow ?
Oui. FlutterFlow expose une option "Realtime" lors de la configuration d'une query Supabase. Quand elle est activée, l'app ouvre une connexion WebSocket vers Supabase et reçoit les changements en push. Pas besoin de polling ou de timer côté client.
Est-il possible d'auto-héberger Supabase avec FlutterFlow ?
Techniquement oui. Supabase peut être auto-hébergé via Docker, et FlutterFlow se connecte à n'importe quelle URL Supabase. Des utilisateurs de la communauté FlutterFlow ont documenté cette configuration. C'est utile pour des projets avec des contraintes très strictes sur la localisation des données, mais la gestion de l'infrastructure reste à votre charge.
