---
term: 'Live Queries en Temps Réel'
seoTitle: 'Live Queries : les abonnements aux requêtes de base de données en temps réel'
headline: 'Que sont les Live Queries en temps réel ?'
slug: live-queries-temps-reel
category: api-realtime
shortDefinition: "Une live query est un abonnement à une requête de base de données : le serveur pousse les événements create, update et delete des lignes correspondantes."
relatedTerms:
  - websockets-real-time-sync
  - event-driven-architecture
  - push-notifications-apns-fcm
  - database-triggers-beforesave-aftersave
contrastsWith:
  - websockets-real-time-sync
faq:
  - question: "Qu'est-ce qu'une live query ?"
    answer: "Un abonnement permanent à une requête de base de données : au lieu de demander une fois et d'obtenir un instantané, vous vous abonnez à la requête et le serveur pousse un événement chaque fois que son ensemble de résultats change — un enregistrement correspondant créé, mis à jour, supprimé, ou modifié de façon à entrer dans les résultats ou à en sortir. Votre écran cesse de faire du polling et se met à écouter."
  - question: "En quoi une live query diffère-t-elle d'une requête normale ?"
    answer: "Par la durée de vie. Une requête normale s'exécute, renvoie, et c'est fini — sa réponse commence à vieillir immédiatement. Une live query reste enregistrée sur le serveur : les résultats initiaux arrivent de la même manière, puis des événements de changement ciblés les tiennent à jour jusqu'à ce que vous vous désabonniez. Le même langage de prédicats, la relation inverse avec le temps."
  - question: 'Comment fonctionnent les live queries sous le capot ?'
    answer: "Deux moitiés jointes : une source de changements et un transport. La base de données émet son flux d'écritures — via des change streams, des logs de réplication ou des triggers — et un serveur d'abonnements confronte chaque changement aux prédicats de requête enregistrés, en poussant les événements pertinents vers les abonnés par WebSockets. Le SDK client encapsule le cycle de vie du socket pour que votre code ne voie que des événements typés."
  - question: 'Que sont les événements enter et leave ?'
    answer: "La paire subtile qui rend les abonnements aux requêtes précis. Enter se déclenche quand un enregistrement existant est modifié et se met à correspondre à votre prédicat ; leave, quand une modification le fait cesser de correspondre. Une tâche qui vous est réattribuée entre dans votre abonnement « assignées à moi » sans avoir été créée ; réattribuée à quelqu'un d'autre, elle en sort sans avoir été supprimée. Create, update et delete couvrent le reste."
  - question: 'Pourquoi les live queries valent-elles mieux que le polling ?'
    answer: "De trois façons à la fois : la latence — les changements arrivent en temps réel au lieu du prochain poll ; la bande passante — les événements ne transportent que ce qui a changé au lieu de tout re-télécharger ; et la charge — le serveur fait un matching par changement au lieu d'exécuter des requêtes complètes par client et par intervalle. Faire du polling toutes les quelques secondes est une simulation ; les abonnements, c'est le vrai temps réel."
  - question: "Qu'apportent les live queries par rapport à des WebSockets bruts ?"
    answer: "Le cerveau de requêtes. Un socket brut déplace des messages ; tout le reste — quels clients s'intéressent à quels changements, ce que les événements signifient, qui a le droit de voir quoi, le rattrapage après reconnexion — est du code que vous écrivez. Une couche de live queries fait le matching de prédicats côté serveur, type les événements, applique les permissions par abonné et gère le cycle de vie du socket. C'est la différence entre un transport et une fonctionnalité."
  - question: 'Les subscriptions GraphQL sont-elles la même chose que les live queries ?'
    answer: "Même famille, déclencheur différent. Les subscriptions GraphQL se déclenchent sur des événements nommés que vous définissez — une mutation publie, les abonnés reçoivent. Les live queries se déclenchent sur les changements de l'ensemble de résultats d'une requête — aucun câblage d'événements, le prédicat est l'abonnement. Les deux circulent sur WebSockets ; les live queries échangent la conception explicite des événements contre une couverture automatique de tous les chemins d'écriture."
  - question: "Comment les live queries passent-elles à l'échelle ?"
    answer: "Sur deux axes : les connexions — des milliers de sockets ouverts répartis entre des serveurs d'abonnements derrière un backplane pub/sub — et le matching — chaque écriture confrontée aux prédicats enregistrés, ce qui explique pourquoi des abonnements sélectifs sur des champs indexés comptent. Les plateformes gérées exploitent les deux axes pour vous ; la discipline côté client consiste à s'abonner étroitement et à se désabonner quand les écrans se ferment."
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'LiveQuery documentation'
    url: 'https://docs.parseplatform.org/parse-server/guide/#live-queries'
  - name: 'MongoDB change streams documentation'
    url: 'https://www.mongodb.com/docs/manual/changestreams/'
  - name: 'LiveQuery protocol specification'
    url: 'https://github.com/parse-community/parse-server/wiki/Parse-LiveQuery-Protocol-Specification'
  - name: 'Back4app Live Query example'
    url: 'https://www.back4app.com/docs/platform/parse-server-live-query-example'
cta:
  title: 'Abonnez-vous aux données, pas à la tuyauterie'
  text: "Les Live Queries de Back4app transforment n'importe quelle requête en abonnement : cinq événements typés, des ACL appliquées par abonné et la flotte de WebSockets gérée par la plateforme. Des fonctionnalités temps réel dans le temps qu'il faut pour écrire la requête que vous aviez déjà."
  linkText: 'Commencez gratuitement'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-10'
translationKey: real-time-live-queries
---

**Une live query est un abonnement à une requête de base de données : le serveur pousse les événements create, update et delete des lignes correspondantes.** C'est le temps verbal qui manquait à l'accès aux données : les requêtes normales parlent au passé (« ce qui correspondait quand j'ai demandé »), les live queries parlent au présent continu (« ce qui correspond, au fur et à mesure que ça change »). L'écran cesse de demander et se met à rester à jour.

## Points clés

| Question | Réponse |
| --- | --- |
| Ce que c'est | Une requête permanente — abonnez-vous une fois, recevez chaque changement de ses résultats |
| Les cinq événements | create · update · delete · **enter** · **leave** |
| Sous le capot | Change stream de la base de données → matching de prédicats → push WebSocket |
| vs. le polling | Latence temps réel, payloads de la taille du delta, aucune charge de requête par intervalle |
| vs. les sockets bruts | La couche de requêtes : matching, événements typés, permissions, reconnexions |

## L'abonnement, en code

Le geste qui définit tout — prenez la requête que vous aviez déjà, et abonnez-vous à elle :

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// A live query: subscribe to a QUERY and receive its changes as events
const query = new Parse.Query('Task');
query.equalTo('assignee', currentUser);

const sub = await query.subscribe();
sub.on('create', (t) => addRow(t));       // new match appeared
sub.on('update', (t) => refreshRow(t));   // a match changed
sub.on('enter',  (t) => addRow(t));       // edited INTO the result set
sub.on('leave',  (t) => removeRow(t));    // edited OUT of the result set
sub.on('delete', (t) => removeRow(t));    // a match was deleted
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// A live query: subscribe to a QUERY and receive its changes as events
final liveQuery = LiveQuery();
final query = QueryBuilder<ParseObject>(ParseObject('Task'))
  ..whereEqualTo('assignee', currentUser);

final sub = await liveQuery.client.subscribe(query);
sub.on(LiveQueryEvent.create, (t) => addRow(t));     // new match
sub.on(LiveQueryEvent.update, (t) => refreshRow(t)); // match changed
sub.on(LiveQueryEvent.enter, (t) => addRow(t));      // edited into the set
sub.on(LiveQueryEvent.leave, (t) => removeRow(t));   // edited out of the set
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// A live query: subscribe to a QUERY and receive its changes as events
let query = Task.query("assignee" == currentUser)

let subscription = query.subscribeCallback
subscription?.handleEvent { _, event in
  switch event {
  case .created(let t):  addRow(t)        // new match appeared
  case .updated(let t):  refreshRow(t)    // a match changed
  case .entered(let t):  addRow(t)        // edited INTO the result set
  case .left(let t):     removeRow(t)     // edited OUT of the result set
  case .deleted(let t):  removeRow(t)
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// A live query: subscribe to a QUERY and receive its changes as events
val client = ParseLiveQueryClient.Factory.getClient()
val query = ParseQuery.getQuery<ParseObject>("Task")
query.whereEqualTo("assignee", currentUser)

val sub = client.subscribe(query)
sub.handleEvent(SubscriptionHandling.Event.CREATE) { _, t -> addRow(t) }
sub.handleEvent(SubscriptionHandling.Event.UPDATE) { _, t -> refreshRow(t) }
sub.handleEvent(SubscriptionHandling.Event.ENTER)  { _, t -> addRow(t) }
sub.handleEvent(SubscriptionHandling.Event.LEAVE)  { _, t -> removeRow(t) }
```

Le vocabulaire des événements mérite son tableau, car **enter** et **leave** sont ce qui fait de ceci un abonnement à une *requête* plutôt qu'une notification de table :

| Événement | Se déclenche quand… | Exemple (abonné à « tâches qui me sont assignées ») |
| --- | --- | --- |
| create | Un nouvel enregistrement correspond | Une tâche est créée pour vous |
| update | Un enregistrement correspondant change | Le statut de votre tâche bascule |
| **enter** | Une modification fait correspondre un enregistrement existant | Une tâche vous est *réattribuée* |
| **leave** | Une modification fait cesser une correspondance | Votre tâche est réattribuée à quelqu'un d'autre |
| delete | Un enregistrement correspondant est supprimé | La tâche est supprimée |

## Le pipeline derrière le push

```mermaid
flowchart LR
  accTitle: Comment fonctionnent les live queries de bout en bout
  accDescr: Les écritures de la base de données alimentent un change stream ; un serveur d'abonnements confronte chaque changement aux prédicats de requête enregistrés et pousse des événements typés par WebSockets vers les clients abonnés, avec des permissions vérifiées par abonné.
  W["Écritures<br/>(n'importe quel client, n'importe quelle API)"] --> DB[("Base de données")]
  DB --> CS["Change stream<br/>(oplog / WAL / triggers)"]
  CS --> M["Serveur d'abonnements<br/>matching de prédicats + vérification ACL"]
  M -->|"push WebSocket"| C1["Abonné A"]
  M -->|"push WebSocket"| C2["Abonné B"]
```

Deux moitiés, proprement séparables : la **source de changements** — le flux d'écritures de la base de données elle-même ([change streams](https://www.mongodb.com/docs/manual/changestreams/) dans les stores documentaires, logs de réplication ailleurs) — et la **couche de matching**, qui confronte chaque changement à chaque prédicat enregistré et pousse vers exactement les abonnés dont les résultats ont changé, permissions appliquées par abonné. Le [protocole ouvert LiveQuery](https://github.com/parse-community/parse-server/wiki/Parse-LiveQuery-Protocol-Specification) est une implémentation de référence lisible de toute cette forme.

## Live queries vs. polling vs. SSE vs. WebSockets

| Approche | Latence | Payload | Coût serveur | Ce que vous construisez |
| --- | --- | --- | --- | --- |
| Polling | Intervalle de poll | Re-téléchargement complet à chaque fois | Requêtes × clients × fréquence | Timers, diffing |
| Long polling | Quasi temps réel | Réponse complète par événement | Connexions maintenues | Tuyauterie de repli |
| SSE | Temps réel | Delta | Flux, à sens unique | Conception des événements |
| WebSockets bruts | Temps réel | Ce que vous définissez | Connexions + votre fan-out | **Tout** |
| **Live queries** | **Temps réel** | **Événements par changement** | **Matching + connexions (géré)** | **La requête** |

La dernière colonne est l'argument : avec des [sockets bruts](/glossary/fr/websockets/) vous construisez le protocole de messages, le routage, les vérifications de permissions et le rattrapage après reconnexion ; avec les live queries, le *prédicat est le protocole* et la plateforme possède le reste.

## Cas d'usage courants

- **Chat et boîtes de réception** — abonnez-vous aux messages de la conversation ; l'arrivée est un événement, pas un rafraîchissement.
- **Dashboards en direct** — commandes, métriques, flottes : la requête définit la vue, les événements la maintiennent vraie.
- **Applications collaboratives** — tableaux de tâches et documents partagés où les modifications de cinq personnes s'entremêlent en quelques secondes.
- **Présence et statut** — qui est en ligne, ce qui est en cours — enter/leave font là leur travail de précision.
- **Écrans opérationnels** — consoles de support et vues d'administration qui doivent refléter la production *maintenant*, pas au dernier rafraîchissement.

## Poller, pousser ou s'abonner ? Matrice de décision

| Choisissez les live queries quand… | Des outils plus simples suffisent quand… |
| --- | --- |
| Les utilisateurs regardent des données partagées et changeantes | Les données changent rarement — pollez doucement ou rechargez au retour de focus |
| Les changements viennent de nombreux auteurs et chemins | Un seul auteur pourrait simplement pousser via SSE |
| La vue est naturellement une requête | Le message n'a pas la forme de données (utilisez les sockets directement) |
| Les permissions doivent filtrer ce que chaque spectateur voit | Tout est diffusion publique |
| Vous préféreriez ne pas posséder l'infrastructure de fan-out | Vous exploitez déjà une plateforme temps réel |

La discipline côté client qui garde les abonnements en bonne santé, quel que soit votre choix : abonnez-vous *étroitement* (des prédicats sélectifs sur des champs indexés), et désabonnez-vous quand l'écran se ferme — les requêtes permanentes sont de l'état serveur, et les écrans qui les laissent fuir accumulent un coût invisible.

## Limites et trade-offs

- **Le matching est une vraie charge de travail.** Chaque écriture est confrontée aux prédicats enregistrés ; des milliers d'abonnements larges sur des classes très sollicitées le multiplient — la sélectivité est le levier.
- **Les connexions sont de l'état.** La flotte de sockets a besoin d'affinité, de heartbeats et de backplanes de fan-out — les plateformes gérées existent précisément parce que c'est du travail lourd et indifférencié.
- **Les reconnexions exigent un rattrapage.** Un client qui était hors ligne a manqué des événements ; les flux robustes ré-exécutent la requête de base au réabonnement au lieu de supposer que rien ne s'est passé pendant la coupure.
- **L'ordre et la livraison relèvent de l'at-least-once.** Des handlers d'événements idempotents (appliquer par ID d'objet, pas par ajout) absorbent élégamment le doublon occasionnel.
- **Tout ne réclame pas un abonnement.** Des données rarement consultées et rarement modifiées sont le territoire du polling ; les live queries méritent leur coût là où les regards et les écritures sont tous deux fréquents.

## Live queries sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l'authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. [Live Query](https://www.back4app.com/docs/platform/parse-server-live-query-example) en est la couche temps réel, et les onglets de code ci-dessus sont toute l'histoire côté client : le même query builder que vous utilisez déjà, un seul appel d'abonnement, cinq événements typés — avec des ACL vérifiées par abonné pour que le temps réel ne contourne jamais le modèle de permissions, et la flotte de WebSockets, les change streams et le fan-out qui tournent comme une infrastructure gérée. Activez Live Query sur une classe dans le dashboard, abonnez-vous depuis n'importe quel SDK, et le présent continu devient une fonctionnalité, pas un projet.