Firebase Firestore — ce que c'est, documents et collections NoSQL

Qu'est-ce que Firebase Firestore

Firebase Firestore est une base de données NoSQL cloud lancée par Google en 2019 en tant que successeur de Realtime Database. Firestore est construit sur l'infrastructure de Google Cloud Spanner et Google Cloud Datastore, offrant une forte cohérence des données au sein d'une seule transaction et une réplication multirégionale automatique. Le SDK prend en charge Android, iOS, Web (JavaScript), Flutter, Kotlin Multiplatform et Unity.

Évolution par rapport à Realtime Database

Firestore a été annoncé à Google I/O 2017 sous le nom de « Cloud Firestore » — une solution répondant aux principales limitations de Realtime Database : absence de prise en charge des requêtes complexes, incapacité à mettre à l'échelle les données sur plusieurs nœuds et cohérence faible. Selon Google (2026), Firestore traite plus d'un billion de requêtes par jour et est la base de données par défaut pour 80 % des nouveaux projets Firebase. Cependant, Realtime Database reste pertinente pour les scénarios à latence ultra-faible (jeux, édition collaborative) grâce à sa structure JSON simple.

Limites gratuites de Firestore

Firestore est proposé selon un modèle de paiement à l'utilisation avec une limite gratuite généreuse sur le forfait Spark : 1 Go de stockage, 10 Go de trafic réseau par mois, 50 000 opérations de lecture, 20 000 opérations d'écriture et 20 000 opérations de suppression par jour. Sur le forfait Blaze, tout ce qui précède est gratuit, et les dépassements sont facturés : 0,06 $ pour 100 000 opérations de lecture, 0,18 $ pour 100 000 opérations d'écriture. Selon Google (2026), 90 % des projets restent dans la limite gratuite.

Modèle de données : collections, documents et champs

Le modèle de données de Firestore est organisé hiérarchiquement : la racine contient des collections, chaque collection contient des documents, chaque document contient des champs (types primitifs, tableaux, Map) et des collections imbriquées (sous-collections). La profondeur d'imbrication des collections est illimitée, mais un document ne peut pas contenir directement un autre document — uniquement via une référence (type Reference).

Collections et documents

Une collection est un conteneur de documents avec des identifiants générés automatiquement ou définis par l'utilisateur. Chaque document est un objet de type JSON d'une taille maximale de 1 Mio. Les champs d'un document peuvent être des chaînes, des nombres, des valeurs booléennes, des tableaux, des Map, des horodatages (Timestamp), des points géographiques (GeoPoint) et des références à d'autres documents (Reference). La taille du document est limitée à 1 Mio, y compris tous les noms de champs.

Écriture par lots et transactions

Firestore prend en charge les transactions atomiques au niveau de la base de données. Une transaction peut lire et écrire plusieurs documents — Commit applique atomiquement toutes les modifications ou aucune. Maximum de 500 opérations par transaction, délai d'attente de 60 secondes. L'écriture par lots (batch write) est une opération d'écriture atomique non transactionnelle sans phase de lecture. Les transactions sont essentielles pour les opérations financières, les réservations de places et la gestion des stocks.

Comparaison entre Firestore et Realtime Database

Le choix entre Firestore et Realtime Database dépend des exigences du projet. Les deux bases de données font partie de l'écosystème Firebase, offrent une synchronisation en temps réel et sont disponibles sur toutes les plateformes, mais diffèrent fondamentalement par le modèle de données, la mise à l'échelle et la tarification.

Différences clés

Realtime Database stocke les données dans un seul arbre JSON, ce qui est pratique pour les structures simples mais rend la mise à l'échelle difficile avec une imbrication de plus de 3 niveaux. Firestore utilise un modèle collection-document avec partitionnement automatique, permettant de passer à l'échelle des millions de documents sans dégradation des performances. Selon Google (2026), Firestore prend en charge jusqu'à 10 000 connexions simultanées à une seule collection sans perte de vitesse, tandis que Realtime Database prend en charge jusqu'à 200 000 connexions à une seule instance.

Tarification

Realtime Database est facturée en fonction du volume de données transférées (octets téléchargés) et du nombre de connexions simultanées. Firestore est facturée au nombre d'opérations (lecture, écriture, suppression). Pour les applications avec des mises à jour petites et fréquentes (chat, notifications), Firestore est généralement plus rentable — chaque opération d'écriture a un prix fixe quelle que soit la taille des données. Pour les applications avec des lectures peu fréquentes de grands volumes de données, Realtime Database peut être moins chère.

Recommandation de Google (2026) : utilisez Firestore comme base de données par défaut pour les nouveaux projets, et Realtime Database pour les jeux et applications où la latence minimale (moins de 50 ms) et une structure de données plate sont essentielles. Les deux bases de données peuvent fonctionner simultanément dans le même projet.

Requêtes, index et pagination dans Firestore

Les requêtes Firestore sont exécutées sur des collections ou des groupes de collections avec filtrage, tri et limites. Contrairement à Realtime Database, où chaque requête parcourt l'ensemble de l'arbre JSON avec un filtrage côté client, Firestore exécute toutes les requêtes sur le serveur à l'aide d'index pré-créés. Cela garantit que la complexité de la requête dépend uniquement de la taille du résultat, et non de la taille de la collection.

Types de requêtes

Firestore prend en charge le filtrage par un ou plusieurs champs (égalité, intervalle, in, array-contains, array-contains-any), le tri ascendant et descendant, les limites et les curseurs pour la pagination. Limitations : les requêtes composées avec filtrage sur différents champs (WHERE price > 10 AND WHERE category == « books ») nécessitent un index composé ; les requêtes OR sont interdites (utilisez in et array-contains-any à la place), et les requêtes d'inégalité sur différents champs ne sont pas autorisées.

data class Product(
    val name: String = "",
    val category: String = "",
    val price: Double = 0.0,
    val inStock: Boolean = false
)

suspend fun FirestoreRepository.queryProducts(): List<Product> {
    return firestore
        .collection("products")
        .whereEqualTo("category", "electronics")
        .whereGreaterThanOrEqualTo("price", 100.0)
        .whereLessThan("price", 500.0)
        .orderBy("price")
        .limit(20)
        .get()
        .await()
        .toObjects(Product::class.java)
}

Index automatiques et composés

Firestore crée automatiquement des index pour les champs individuels — les requêtes sur un seul champ fonctionnent sans aucune configuration. Pour les requêtes avec deux champs ou plus (filtrage + tri), des index composés sont nécessaires. Lors de la première soumission d'une requête, Firestore renvoie une erreur avec un lien vers la console où l'index peut être créé en un clic. Maximum de 200 index composés par base de données. Les index peuvent être exportés et importés via Firebase CLI.

Intégration de Firestore dans Android

La connexion de Firestore à une application Android se fait de manière standard via Firebase BOM. Après avoir ajouté la dépendance firebase-firestore-ktx, l'objet FirebaseFirestore est disponible via getInstance() — sans clés ni jetons supplémentaires. Firestore utilise le même projet Firebase que les autres services.

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-firestore-ktx")
}

// Initialisation
val db = FirebaseFirestore.getInstance()

Lecture et écriture de données

Firestore propose deux modes de lecture : unique (get) et en temps réel (addSnapshotListener). La lecture unique récupère un document une fois — utile pour les paramètres et la configuration. Un écouteur s'abonne aux modifications — toute mise à jour d'un document transmet automatiquement les données mises à jour à tous les clients connectés en temps réel. set() crée ou écrase un document, update() modifie uniquement les champs spécifiés sans écraser l'intégralité du document.

Selon Google (2026), les applications de taille moyenne (100 000 DAU) avec Firestore en temps réel consomment environ 5 à 10 Go de trafic sortant par mois. L'utilisation du cache hors ligne (Persistence Cache) réduit les téléchargements répétés de 60 à 70 %, car le SDK ne charge que les documents modifiés lors du rétablissement de la connexion.

Mode hors ligne

Persistence Cache est un mécanisme intégré de Firestore pour fonctionner sans accès Internet. Le SDK met automatiquement en cache tous les documents lus sur l'appareil (jusqu'à 500 Mio sur Android). En cas de perte de connexion, les lectures continuent à partir du cache et les écritures sont mises en file d'attente. Lors du rétablissement de la connexion, toutes les opérations en attente sont envoyées au serveur et le cache est synchronisé avec le serveur. Pour le contrôle des conflits, utilisez snapshot-metadata.hasPendingWrites et setOptions(ServerTimestampBehavior).

Règles de sécurité et validation des données

Security Rules est un langage déclaratif de contrôle d'accès pour Firestore qui s'exécute sur le serveur de Google avant chaque opération de lecture ou d'écriture. Les règles ne nécessitent pas de code côté serveur — elles sont écrites dans la console Firebase ou via Firebase CLI et versionnées via Git. Chaque opération est vérifiée par rapport aux règles, et une violation renvoie une erreur PERMISSION_DENIED.

Structure des règles

Les Firestore Security Rules sont composées de blocs match et d'expressions allow. match définit le chemin vers une collection ou un document, allow spécifie les opérations autorisées (read, write, create, update, delete) et une condition — une expression de type JavaScript renvoyant un booléen. Les règles peuvent vérifier l'authentification (request.auth), les données de la requête (request.resource.data), les données existantes (resource.data), l'heure (request.time) et le chemin (request.path).

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read: if request.auth != null;
      allow write: if request.auth.uid == userId;
    }

    match /products/{productId} {
      allow read: if true;
      allow create: if request.auth.token.role == "admin";
      allow update: if resource.data.authorId == request.auth.uid;
    }
  }
}

Validation des données

Les Security Rules prennent en charge la validation des types et des valeurs côté serveur. Vous pouvez interdire l'écriture si le prix est négatif ou si le nom est vide. Toutes les vérifications sont effectuées sur le serveur de Google avant l'écriture — cela garantit la cohérence des données quel que soit le client (Android, iOS, Web, Admin SDK). Les règles ne protègent pas contre un Admin SDK malveillant — il contourne les règles par conception. Pour une protection complète, utilisez Transaction Functions et Firebase Extensions.