Polling
Le polling est une technique de communication client-serveur où le client envoie des requêtes HTTP à intervalles réguliers pour vérifier si de nouvelles données sont disponibles, simulant une mise à jour en temps réel par des interrogations répétées.
Le polling, c’est vérifier votre boîte aux lettres toutes les 5 minutes. La plupart du temps, elle est vide. Vous avez fait le déplacement pour rien. Mais c’est simple, ça ne nécessite aucune infrastructure spéciale, et ça fonctionne partout. C’est la technique la plus primitive pour obtenir des mises à jour, et paradoxalement, elle reste pertinente en 2026 pour les cas où la simplicité prime sur l’efficacité.
Short polling
Le short polling est la forme la plus simple : le client envoie une requête HTTP à intervalle fixe (par exemple toutes les 5 secondes), le serveur répond immédiatement avec les données actuelles (ou une réponse vide s’il n’y a rien de nouveau), puis la connexion se ferme.
// Short polling : vérifier toutes les 5 secondes
async function pollForUpdates() {
while (true) {
try {
const response = await fetch("/api/notifications?since=" + lastTimestamp);
const data = await response.json();
if (data.notifications.length > 0) {
// Nouvelles notifications disponibles
handleNotifications(data.notifications);
lastTimestamp = data.notifications.at(-1).timestamp;
}
// Sinon : rien de nouveau, requête "gaspillée"
} catch (error) {
console.error("Erreur polling:", error);
}
await new Promise(resolve => setTimeout(resolve, 5000)); // 5s
}
}Le problème du short polling est double. Côté efficacité : si rien ne change, chaque requête est inutile, gaspillant de la bande passante et des ressources serveur. Avec 10 000 clients qui polled toutes les 5 secondes, le serveur reçoit 2 000 requêtes par seconde, dont la majorité retournent « pas de changement ». Côté latence : dans le pire cas, un événement qui se produit juste après un poll ne sera détecté qu’au poll suivant (5 secondes de délai).
Long polling
Le long polling améliore le short polling en gardant la connexion ouverte jusqu’à ce qu’il y ait quelque chose à retourner. Le client envoie une requête, le serveur la maintient ouverte (pendant 30 secondes typiquement). Si un événement se produit pendant cette période, le serveur répond immédiatement. Si rien ne se passe, le serveur envoie une réponse vide à l’expiration du timeout, et le client renvoie immédiatement une nouvelle requête.
# Serveur long polling (FastAPI)
from fastapi import FastAPI
import asyncio
app = FastAPI()
event_queue = asyncio.Queue()
@app.get("/api/events")
async def long_poll():
try:
# Attendre un événement pendant max 30 secondes
event = await asyncio.wait_for(event_queue.get(), timeout=30.0)
return {"event": event}
except asyncio.TimeoutError:
# Rien de nouveau, le client va re-pollier
return {"event": None}Le long polling réduit le nombre de requêtes inutiles et améliore la latence (l’événement est retourné dès qu’il se produit). Mais il garde les connexions serveur ouvertes, consomme des threads/connexions, et peut poser des problèmes avec les proxies et load balancers qui ont des timeouts de connexion.
Polling vs les alternatives temps réel
| Critère | Short polling | Long polling | SSE | WebSocket |
|---|---|---|---|---|
| Latence | Haute (intervalle) | Faible | Très faible | Très faible |
| Efficacité | Faible (requêtes inutiles) | Moyenne | Élevée | Élevée |
| Complexité serveur | Très faible | Moyenne | Faible | Moyenne |
| Bidirectionnel | Non (requêtes séparées) | Non | Non | Oui |
| Reconnexion | Implicite | Implicite | Automatique | Manuelle |
| Compatibilité | Universelle | Universelle | Tous navigateurs modernes | Tous navigateurs modernes |
| Charge serveur | Élevée (requêtes continues) | Moyenne (connexions ouvertes) | Faible | Faible |
Quand le polling reste pertinent
Malgré ses limites, le polling a des cas d’usage légitimes en 2026 :
Quand SSE et WebSocket ne sont pas disponibles. Certains environnements d’entreprise (firewalls restrictifs, proxies anciens) bloquent WebSocket et ne supportent pas correctement SSE. Le polling HTTP standard passe partout.
Quand la fraîcheur n’est pas critique. Un dashboard interne qui se met à jour toutes les 30 secondes n’a pas besoin de SSE. Un poll toutes les 30 secondes est plus simple à implémenter et à maintenir.
Pour les API qui ne supportent pas le push. Si l’API tierce que vous consommez ne fournit ni webhooks ni streaming, le polling est votre seule option. Beaucoup d’API héritées ne supportent que le modèle request-response.
Comme fallback. Les architectures robustes implémentent SSE ou WebSocket comme protocole principal, avec un fallback vers le long polling si la connexion persistante échoue. Socket.io (bibliothèque JavaScript populaire) fait exactement cela : WebSocket par défaut, long polling en fallback.
Pour les vérifications peu fréquentes. Vérifier si un entraînement ML est terminé toutes les 60 secondes est parfaitement acceptable avec du short polling. La complexité de SSE ou WebSocket n’est pas justifiée pour un check toutes les minutes.
since ou etag pour ne retourner que les données modifiées depuis le dernier poll. Ajustez l’intervalle dynamiquement (plus fréquent pendant l’activité, moins fréquent au repos). Utilisez les headers HTTP 304 Not Modified pour les réponses sans changement (économise la bande passante).
Polling dans le MLOps
Le polling reste courant dans les workflows MLOps :
Vérification de l’état des jobs d’entraînement. La plupart des plateformes cloud (SageMaker, Vertex AI) exposent un endpoint de statut que vous pollez pour savoir quand l’entraînement est terminé. Intervalle typique : 30-60 secondes.
Monitoring du drift. Les pipelines de monitoring interrogent périodiquement les métriques du modèle en production pour détecter les dérives. Intervalle typique : toutes les heures ou tous les jours.
Synchronisation de données. Les pipelines d’ingestion vérifient périodiquement si de nouvelles données sont disponibles dans un bucket S3, une base de données ou un data pipeline. Quand les webhooks ne sont pas disponibles, le polling est le fallback naturel.
Erreurs courantes
Intervalle trop court. Poller toutes les secondes quand les données changent toutes les minutes gaspille 60x les ressources. Ajustez l’intervalle à la fréquence réelle des changements. Si la fréquence est inconnue, commencez avec un intervalle conservateur et ajustez.
Pas de backoff en cas d’erreur. Si le serveur retourne une erreur 500, un poll qui continue au même rythme aggrave le problème (thundering herd). Implémentez un backoff exponentiel : en cas d’erreur, doublez l’intervalle (5s, 10s, 20s, 40s) jusqu’à ce que le serveur réponde normalement.
Utiliser le polling quand SSE ou WebSocket sont disponibles. Si le serveur supporte SSE ou WebSocket, les utiliser est presque toujours préférable : moins de requêtes, moins de latence, moins de charge serveur. Le polling ne devrait être un choix que quand les alternatives ne sont pas viables.
Polling depuis le navigateur sans limite. 10 000 utilisateurs qui polled toutes les 5 secondes = 2 000 requêtes/seconde sur votre serveur, la plupart inutiles. Considérez SSE pour les cas temps réel côté navigateur.
Pas de déduplication. Si le serveur retourne les mêmes données à chaque poll, le client doit détecter qu’il n’y a rien de nouveau. Utilisez des timestamps, des ETags ou des identifiants de version pour ne traiter que les données effectivement nouvelles.
Questions fréquentes sur le polling
Quelle est la différence entre short polling et long polling ?
En short polling, le client envoie une requête à intervalle fixe (par exemple toutes les 5 secondes) et le serveur répond immédiatement, qu’il y ait des données ou non. En long polling, le serveur maintient la connexion ouverte jusqu’à ce qu’il ait des données à retourner (ou jusqu’à un timeout, typiquement 30 secondes). Le long polling réduit les requêtes inutiles et améliore la latence, mais consomme des connexions serveur ouvertes.
Pourquoi ne pas toujours utiliser WebSocket ou SSE à la place du polling ?
Le polling reste pertinent quand : l’environnement réseau bloque WebSocket/SSE (certains firewalls d’entreprise), l’API tierce ne supporte que le request-response, la fréquence de mise à jour est faible (un check par minute), ou la simplicité d’implémentation prime. Le polling fonctionne avec n’importe quel serveur HTTP, sans configuration spéciale. SSE et WebSocket sont préférables dès que la fraîcheur des données et l’efficacité importent.
Comment réduire la charge serveur du polling ?
Quatre techniques : (1) augmenter l’intervalle entre les polls quand il n’y a pas de changement (adaptive polling), (2) utiliser les headers HTTP 304 Not Modified et ETag pour éviter de transférer des données identiques, (3) supporter un paramètre since ou after qui ne retourne que les données nouvelles depuis le dernier poll, (4) implémenter un backoff exponentiel en cas d’erreur serveur.
Le polling est-il encore utilisé en 2026 ?
Oui, mais son usage diminue au profit de SSE et WebSocket. Le polling reste courant pour les jobs asynchrones (vérification de statut d’entraînement ML), les intégrations avec des API legacy sans webhook, et comme mécanisme de fallback quand les connexions persistantes échouent. Socket.io utilise le long polling comme fallback automatique si WebSocket n’est pas disponible.
Quel intervalle de polling choisir ?
L’intervalle optimal dépend de la fraîcheur nécessaire et de la fréquence des changements. Pour du monitoring système : 10-30 secondes. Pour des mises à jour de statut de jobs : 30-60 secondes. Pour de la synchronisation de données quotidienne : quelques minutes. Règle pratique : l’intervalle devrait être au maximum la moitié de la latence acceptable (si vous tolérez 10 secondes de retard, pollez toutes les 5 secondes). Au-delà de 1 poll par seconde, passez à SSE ou WebSocket.