Short Polling : ce que c'est, comment ça fonctionne et où c'est utilisé

Qu'est-ce que le Short Polling

Short Polling est un modèle de communication où le client envoie périodiquement des requêtes HTTP au serveur à un intervalle prédéfini, et le serveur traite chaque requête de manière synchrone et renvoie le résultat immédiatement. L'intervalle de polling est défini côté client à l'aide de minuteurs et varie généralement de 1 à 60 secondes selon les exigences de fraîcheur des données.

Le Short Polling est historiquement le premier mécanisme pour organiser la communication en temps réel dans les applications web. Au début des années 2000, avant la deuxième génération de XMLHttpRequest, les pages web utilisaient <meta http-equiv="refresh"> ou le rechargement périodique d'iframe pour mettre à jour le contenu. Avec l'avènement de la technologie AJAX (Asynchronous JavaScript and XML) en 2005, le Short Polling est devenu l'approche standard pour mettre à jour les données sans recharger complètement la page.

Architecture du Short Polling

L'architecture du Short Polling comprend trois composants : un minuteur client, une requête HTTP et un gestionnaire serveur. Le client démarre un minuteur d'intervalle, et à chaque déclenchement, une requête GET est envoyée au serveur. Le serveur interroge une base de données ou une autre source, forme une réponse et la renvoie immédiatement au client. Le client met à jour l'interface et attend le déclenchement suivant du minuteur. Ce cycle se répète indéfiniment tant que l'application est active.

Le problème des requêtes redondantes

Le principal problème du Short Polling est les inévitables requêtes vides. Si les données changent rarement, la plupart des requêtes renvoient un résultat « sans changement », gaspillant la bande passante réseau et le temps CPU pour le traitement. Avec 10 000 clients avec un intervalle de polling de 5 secondes, le serveur reçoit 2 000 requêtes par seconde — dont une partie significative est inutile si la fréquence de mise à jour est de 1 événement par minute.

Comment fonctionne le Short Polling

Short Polling fonctionne selon un cycle simple : le client définit un minuteur d'intervalle avec une période déterminée (par exemple, 5000 ms). À chaque déclenchement du minuteur, le client forme une requête HTTP GET vers l'endpoint du serveur, généralement avec un paramètre d'horodatage de la dernière mise à jour. Le serveur reçoit la requête, vérifie la présence de nouvelles données après l'horodatage spécifié et renvoie une réponse — soit avec de nouvelles données, soit avec un indicateur d'absence de mises à jour.

Un paramètre critique de configuration du Short Polling est l'intervalle de polling. Un intervalle trop court (moins de 3 secondes) crée une charge élevée sur le serveur et le réseau. Un intervalle trop long (plus de 30 secondes) réduit la fraîcheur des données. L'intervalle optimal dépend du scénario : pour les tableaux de bord de surveillance — 5–15 secondes, pour les flux d'actualités — 30–60 secondes, pour les alertes critiques — 1–3 secondes. Le choix de l'intervalle est toujours un compromis entre la fraîcheur des données et la charge sur l'infrastructure.

Intervalle de polling adaptatif

Pour réduire la charge pendant l'inactivité, on utilise un intervalle adaptatif : si plusieurs requêtes consécutives renvoient un résultat vide, l'intervalle augmente (par exemple, de 5 à 15 secondes). Lorsque de nouvelles données apparaissent, l'intervalle est réinitialisé à la valeur minimale. L'algorithme de backoff exponentiel (exponential backoff) permet de réduire le nombre de requêtes vides de 3 à 5 fois lors de mises à jour peu fréquentes.

Exemple d'implémentation du Short Polling en JavaScript

Examinons une implémentation côté client du Short Polling utilisant setInterval et Fetch API. La fonction prend l'URL de l'endpoint et l'intervalle de polling en millisecondes.

function startPolling(url, intervalMs) {
    const lastTimestamp = new Date().toISOString();

    const timerId = setInterval(async () => {
        try {
            const params = new URLSearchParams({
                since: lastTimestamp
            });
            const response = await fetch(url + "?" + params);
            const data = await response.json();

            if (data.updates && data.updates.length > 0) {
                renderUpdates(data.updates);
                console.log("Reçu", data.updates.length, "updates");
            }
        } catch (error) {
            console.error("Échec du polling :", error);
        }
    }, intervalMs);

    return timerId;
}

const timer = startPolling("/api/updates", 5000);
// clearInterval(timer) pour arrêter

Le code crée un intervalle de polling de 5 secondes et transmet l'horodatage de la dernière mise à jour au serveur. Le serveur peut utiliser ce paramètre pour filtrer les données et ne retourner que les nouveaux enregistrements, réduisant ainsi la quantité d'informations transmises. La fonction retourne l'identifiant du minuteur pour permettre l'arrêt du polling.

Partie serveur du Short Polling

L'implémentation côté serveur pour le Short Polling est extrêmement simple — c'est un endpoint REST ordinaire qui accepte les requêtes GET et retourne une réponse JSON avec l'état actuel ou les données modifiées après l'horodatage spécifié.

const express = require("express");
const app = express();

let items = [];

app.get("/api/updates", (req, res) => {
    const since = req.query.since;
    const filtered = items.filter(item => item.timestamp > since);
    res.json({ updates: filtered });
});

app.listen(3000);

Le serveur reçoit le paramètre since et filtre les enregistrements dont l'horodatage dépasse la valeur spécifiée. Cette approche minimise la quantité de données dans chaque réponse, en ne retournant que les modifications incrémentielles. Lorsqu'il n'y a pas de nouvelles données, le serveur retourne un tableau vide et le client continue le polling selon le calendrier prévu.

Short Polling vs Long Polling

Short Polling et Long Polling résolvent le même problème — la livraison des données du serveur au client — mais diffèrent radicalement en efficacité. Short Polling utilise un intervalle de requête fixe, créant une charge prévisible, tandis que Long Polling maintient la connexion ouverte jusqu'à ce qu'un événement se produise, minimisant le nombre de réponses vides.

Le choix entre les techniques dépend de la fréquence de mise à jour des données. Si les événements se produisent plus d'une fois toutes les 10 secondes — les deux approches génèrent une charge comparable, et Short Polling peut être plus simple. Si les événements sont rares (heures ou minutes entre les changements) — Long Polling est préférable car il ne crée pas de requêtes vides. Pour les scénarios intermédiaires, le choix dépend des contraintes d'infrastructure et de la possibilité d'utiliser WebSocket.

Quand utiliser le Short Polling

Short Polling est utilisé dans les scénarios où les exigences de fraîcheur des données sont faibles et la simplicité d'implémentation a priorité sur l'efficacité. Les cas les plus typiques sont les panneaux d'administration internes, les systèmes de surveillance à faible fréquence d'alertes et les applications où un délai de 15 à 30 secondes est acceptable.

• Tableaux de bord de surveillance — tableaux de bord avec des métriques qui se mettent à jour toutes les 10 à 30 secondes, sans nécessiter de réaction instantanée aux changements.
• Pages de statut — pages de vérification de disponibilité des services où les données se mettent à jour toutes les 30 à 60 secondes et le délai n'est pas critique.
• Rapports analytiques — systèmes d'analyse internes avec collecte périodique de données où une fraîcheur jusqu'à 1 minute est acceptable.
• Jeux simples — jeux multijoueurs au tour par tour sans exigences de temps réel, où le tour se met à jour toutes les quelques secondes.
• Tests — scénarios de test de charge et de débogage où Short Polling est utilisé comme méthode de polling de référence pour comparaison avec d'autres techniques.

Limitation importante — Short Polling n'est pas adapté aux applications critiques en termes de temps (terminaux de trading, systèmes d'alerte d'urgence) où même un délai d'une seconde est inacceptable. Dans de tels scénarios, il est nécessaire d'utiliser WebSocket, Server-Sent Events ou Long Polling. Lors de la conception d'un système avec Short Polling, il faut calculer le budget de requêtes : avec 1 000 clients avec un intervalle de 5 secondes, le serveur traite 12 000 requêtes par minute, ce qui nécessite une base de ressources correspondante.