FlutterFlow + Firebase : construire une app production-ready

FlutterFlow configure l'auth Firebase en quelques clics. Email/password, Google Sign-In, Apple Sign-In (obligatoire sur iOS si vous proposez un login social), Anonymous Auth pour les onboardings progressifs tout est là.

Ce qui est souvent négligé : la gestion des états d'authentification dans le temps. Un token Firebase expire. La session peut être invalidée (changement de mot de passe, désactivation du compte). Il faut tester ces cas, vérifier que l'app redirige proprement vers la page de login, et ne pas laisser de données sensibles en cache après déconnexion.

Pour les apps avec des niveaux de permission, pensez à stocker le rôle dans un document Firestore users/{uid} plutôt que dans les custom claims Firebase Auth. Et vérifiez ces rôles côté Security Rules, jamais seulement côté client.

Firestore facture à la lecture et à l'écriture de documents. Une mauvaise modélisation peut transformer un bug de pagination en facture inattendue.

Le premier réflexe : éviter les sous-collections trop profondes. Une structure à plus de 3 niveaux est souvent le signe d'un problème de modélisation. Préférez la dénormalisation (dupliquer les données critiques là où elles seront lues) plutôt que les jointures implicites qui multiplient les lectures.

Dans FlutterFlow, faites attention aux queries sans limite. Un List View connecté à une collection sans pagination chargera tous les documents à chaque rebuild. Activez la pagination native dès le départ, avant que votre collection grossisse.

Pour les données temps réel (chat, notifications), les streams Firestore sont parfaits. Pour les données qui changent peu (profil, configurations), un fetch unique avec cache est plus économique.

Les Security Rules Firestore sont la ligne de défense critique entre vos données et n'importe quelle requête malveillante. Par défaut, un nouveau projet Firebase est soit complètement ouvert (test mode), soit complètement fermé.

La règle minimale pour une app authentifiée : les utilisateurs ne peuvent lire et modifier que leurs propres données. Pour les données partagées (feed public, catalogue produit), définissez explicitement les règles de lecture, et sécurisez strictement les écritures. Validez la structure des documents dans vos rules avec request.resource.data ne faites jamais confiance aux données venant du client.

FlutterFlow ne génère pas les Security Rules automatiquement. C'est à vous de les écrire dans la console Firebase. Le simulateur intégré est précieux pour tester vos règles avant de déployer.

Crashlytics est l'outil de remontée de crash de Firebase. Dans FlutterFlow, l'intégration est native et s'active en un toggle. Il capture les exceptions non interceptées avec leur stack trace, et les remonte dans la console avec des informations contextuelles (device, OS, version de l'app, utilisateur si authentifié).

Ce que beaucoup oublient : les erreurs métier non-fatales. Un utilisateur qui tombe sur un écran vide parce que sa collection Firestore est vide, ce n'est pas un crash mais c'est un problème. Loggez ces états explicitement dans vos Custom Actions.

Firebase Analytics permet de suivre les événements utilisateur. Définissez 5 à 10 événements clés dès le lancement (onboarding_completed, first_action, subscription_started) plutôt que de logger tout et n'importe quoi la qualité des données vaut mieux que la quantité.