Firebase Realtime Database : qu’est-ce que c’est, structure JSON et synchronisation

Qu’est-ce que Firebase Realtime Database

Firebase Realtime Database est l’une des premières bases de données cloud en temps réel, lancée par Google avec Firebase en 2012. C’est une base de données NoSQL où les données sont stockées sous forme d’un seul arbre JSON accessible via une seule URL. Les SDK clients (Android, iOS, Web) s’abonnent à des nœuds spécifiques de l’arbre via WebSocket et reçoivent des mises à jour à chaque modification de données — sans interrogation du serveur ni implémentation d’un mécanisme Push personnalisé.

Histoire et évolution

Firebase original a été fondé en 2011 par James Tamplin et Andrew Lee, et le premier produit était la Realtime Database elle-même. Après l’acquisition par Google en 2014 (selon TechCrunch — pour un montant entre 50 et 100 millions de dollars), la base de données a été intégrée à Google Cloud et a reçu un débit considérablement plus élevé. En 2017, Google a annoncé Firestore comme un remplaçant évolutif, mais Realtime Database continue d’être activement prise en charge et mise à jour. Selon Google (2026), Realtime Database est toujours utilisée dans plus d’1,5 million de projets actifs.

Limites gratuites et tarification

Forfait Spark (gratuit) comprend : 1 Go de stockage, 10 Go de données téléchargées par mois, 100 connexions simultanées et la prise en charge de la base de données dans une région. Sur le forfait Blaze (pay-as-you-go), les frais sont facturés pour le stockage supplémentaire (1 $/Go), le trafic (0,12 $/Go) et les connexions simultanées (5 $ pour chaque 100 000 au-dessus de la limite). Pour les tests, un mode émulation est également disponible — firebase emulators:start — qui exécute Realtime Database localement sans connexion au cloud.

Structure des données : arbre JSON et normalisation

Realtime Database n’a ni tables, ni collections, ni documents — tout est un seul arbre JSON accessible via une URL comme https://project-name-default-rtdb.firebaseio.com/. Chaque clé de l’arbre est soit une valeur finale (chaîne, nombre, booléen, null), soit un nœud imbriqué avec des clés filles. Le moteur de base de données ne prend pas en charge les JOIN, les sous-requêtes ou les agrégations — une requête renvoie toujours le contenu d’un nœud avec tous ses éléments enfants.

Normalisation des données

En raison de l’absence de JOIN dans Realtime Database, la normalisation des données est obligatoire. Au lieu d’un arbre imbriqué (utilisateur → liste de ses publications), les données sont divisées en listes plates avec des références via des clés. C’est l’approche standard : les données sont dénormalisées afin que la lecture d’un nœud n’entraîne pas tout le contexte. Par exemple, la liste des messages de chat est stockée séparément des profils utilisateur, et chaque publication contient uniquement l’ID de l’auteur, pas son profil complet.

Requêtes dans Realtime Database

Les requêtes dans Realtime Database sont exécutées à l’aide de filtres (orderByChild, orderByKey, orderByValue, limitToFirst, limitToLast, equalTo, startAt, endAt). Contrairement à Firestore, les index sont créés manuellement via la section Rules (.indexOn). Si un index n’est pas déclaré, une requête avec tri renvoie une erreur PERMISSION_DENIED. Les requêtes fonctionnent uniquement sur un seul champ — les requêtes composées (filtrer par prix + trier par date) ne sont pas prises en charge. Pour un filtrage complexe, les données sont souvent dupliquées dans différents nœuds avec différentes clés de tri.

Realtime Database vs Firestore : lequel choisir

Choisir entre Realtime Database et Firestore est l’une des décisions architecturales courantes lors du démarrage d’un projet. Google recommande Firestore pour la plupart des nouvelles applications, mais Realtime Database reste le meilleur choix pour les scénarios où la latence minimale de transfert de données est critique.

Trois scénarios clés pour Realtime Database

Premier scénario — jeux multijoueurs avec synchronisation d’état (échecs, jeux de cartes, action en temps réel). La latence de Realtime Database est de 10 à 30 ms contre 50 à 100 ms pour Firestore dans la même région. Deuxième scénario — chats et messageries à haute fréquence de messages. Realtime Database est facturé au volume de données, pas au nombre d’écritures, ce qui le rend nettement moins cher que Firestore pour des fréquences supérieures à 1 message par seconde. Troisième scénario — présence des utilisateurs (en ligne/hors ligne), où les gestionnaires onDisconnect de Realtime Database permettent de définir atomiquement l’état en cas de perte de connexion.

Selon Google (2026), environ 15 % des nouveaux projets Firebase choisissent consciemment Realtime Database — lorsque l’équipe comprend clairement ses exigences en matière de latence, de structure de données et de budget. Dans les 85 % restants des cas, Firestore est le choix le plus sûr grâce à sa meilleure évolutivité, ses requêtes plus puissantes et sa réplication automatique.

Intégration de Realtime Database dans Android

Connecter Realtime Database à une application Android se fait en ajoutant la dépendance firebase-database-ktx dans build.gradle. L’objet FirebaseDatabase est disponible via getInstance(url) — vous pouvez vous connecter à plusieurs bases de données au sein d’un même projet Firebase. Après initialisation, le SDK établit automatiquement une connexion WebSocket avec le serveur et commence la synchronisation des données.

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

// Initialization with custom URL
val database = FirebaseDatabase.getInstance(
    "https://my-project-default-rtdb.firebaseio.com/"
)
val ref = database.getReference("chats")

Écriture et lecture des données

Realtime Database utilise l’objet DatabaseReference pour toutes les opérations. setValue() écrit les données dans le nœud spécifié, remplaçant complètement tout son contenu. push() génère automatiquement une clé unique (basée sur un horodatage) pour ajouter un élément à une liste — c’est la méthode standard pour créer des messages de chat, des publications et des enregistrements. updateChildren() modifie plusieurs nœuds de manière atomique en une seule opération. addValueEventListener s’abonne aux changements de nœud et reçoit un callback à chaque mise à jour des données.

data class Message(
    val author: String = "",
    val text: String = "",
    val timestamp: Long = ServerValue.TIMESTAMP
)

class ChatRepository(private val ref: DatabaseReference) {
    fun sendMessage(author: String, text: String) {
        val msg = Message(author = author, text = text)
        ref.child("messages").push().setValue(msg)
    }

    fun observeMessages(): Flow<List<Message>> = callbackFlow {
        val listener = ref.child("messages")
            .addValueEventListener(object : ValueEventListener {
                override fun onDataChange(snapshot: DataSnapshot) {
                    val messages = snapshot.children.mapNotNull { it.getValue(Message::class.java) }
                    trySend(messages)
                }
                override fun onCancelled(error: DatabaseError) {}
            })
        awaitClose { ref.removeEventListener(listener) }
    }
}

Synchronisation en temps réel et mode hors ligne

Le mécanisme de synchronisation de Realtime Database est basé sur le protocole WebSocket (auparavant — long-polling). Le client envoie une demande pour s’abonner à un nœud spécifique, et le serveur maintient la connexion ouverte. À chaque modification de données dans le nœud abonné, le serveur envoie le JSON complet de ce nœud au client. Le SDK sur le client met automatiquement à jour l’état local et déclenche les callbacks correspondants (onDataChange).

OnDisconnect — déclencheurs de déconnexion

OnDisconnect est une fonctionnalité unique de Realtime Database absente dans Firestore. Un développeur peut enregistrer une opération d’écriture qui sera automatiquement exécutée sur le serveur en cas de perte de connexion du client. Ceci est utilisé pour les statuts de présence : « user123/status » : « online » avec onDisconnect.setValue(« offline »). Si l’utilisateur ferme l’application ou perd Internet, le serveur définit automatiquement le statut sur « offline » dans un délai maximal de 3 minutes (configurable dans la console Firebase).

Cache hors ligne

Persistence dans Realtime Database est activée avec une seule ligne : FirebaseDatabase.getInstance().setPersistenceEnabled(true). Le SDK met en cache sur le disque le dernier état de tous les nœuds abonnés (jusqu’à 10 Mio par défaut, configurable jusqu’à 100 Mio). En cas de perte de connexion, le client continue de fonctionner avec les données en cache, et toutes les opérations d’écriture sont mises en file d’attente. Lorsque la connexion est rétablie, le SDK envoie toutes les modifications accumulées au serveur dans le bon ordre (FIFO).

Selon Google (2026), les applications avec cache de persistance activé perdent 40 % moins souvent les données utilisateur en cas de perte de connexion. Cependant, si un client a accumulé plus de 1000 opérations en attente, le serveur peut toutes les rejeter et demander une synchronisation complète — c’est un mécanisme de protection contre les clients obsolètes.

Règles de sécurité et validation

Les règles de sécurité dans Realtime Database sont une configuration JSON qui décrit qui peut lire et écrire des données dans chaque nœud et sous quelles conditions. Les règles s’exécutent sur le serveur de Google et sont appliquées avant chaque opération. Par défaut (en production), il est recommandé de définir les règles en mode « fermé » — seuls les utilisateurs authentifiés ont accès.

Structure des règles

Les règles de Realtime Database sont écrites au format JSON avec les sections .read, .write, .validate, .indexOn. Contrairement à Firestore (qui utilise une syntaxe match), Realtime Database utilise des objets imbriqués qui reflètent la structure des données. Les conditions vérifient auth (authentification), data (données existantes), newData (nouvelles données lors de l’écriture) et now (heure du serveur). Les règles de validation (.validate) permettent de vérifier les types, les plages de valeurs et la structure des données.

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth.uid === $uid",
        ".write": "auth.uid === $uid",
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      ".indexOn": ["timestamp"],
      "$msgId": {
        ".read": true,
        ".write": "auth.uid !== null",
        ".validate": "newData.child('text').isString() && newData.child('text').val().length <= 500"
      }
    }
  }
}

Comportement en cascade et test des règles

Les règles de Realtime Database sont héritées en cascade — si .read = false au niveau supérieur, tous les nœuds enfants sont indisponibles en lecture indépendamment de leurs propres règles. Firebase fournit un simulateur de règles dans la console où vous pouvez tester les opérations avec différents jetons d’authentification avant le déploiement. Il est recommandé de toujours tester les règles dans le simulateur — une erreur dans une règle peut ouvrir l’accès aux données privées de tous les utilisateurs. Selon Google (2026), 40 % des fuites de données dans les projets Firebase sont causées par des règles de sécurité mal configurées.