"Rendez le dashboard temps réel." Cette demande arrive tôt ou tard dans chaque projet. Et immédiatement, l'équipe technique pense WebSockets. C'est devenu un réflexe — parfois justifié, souvent excessif. En 2026, avec l'essor des architectures serverless et edge, le choix de la technologie temps réel mérite une analyse plus nuancée.
Ce guide vous aide à choisir entre WebSockets, Server-Sent Events (SSE) et Polling selon votre contexte réel. Pas de réponse universelle, mais des critères concrets pour une décision éclairée.
Comprendre les trois approches
Polling : la simplicité qui a du sens
Le polling consiste à interroger le serveur à intervalles réguliers. Votre application envoie une requête HTTP toutes les X secondes et récupère les nouvelles données s'il y en a.
Fonctionnement : Le client initie chaque échange. Le serveur répond puis ferme la connexion. Répétition à intervalle fixe.
Avantages :
- Fonctionne partout, aucune infrastructure spéciale
- Compatible avec tous les proxies et load balancers
- Facile à déboguer et monitorer
- Parfait pour les environnements serverless (Vercel, Netlify, AWS Lambda)
Inconvénients :
- Latence minimale égale à l'intervalle de polling
- Consommation de ressources même sans nouvelles données
- Inefficace pour les mises à jour très fréquentes
Cas d'usage idéaux :
- Dashboards avec rafraîchissement toutes les 30 secondes ou plus
- Vérification de statut de commandes
- Synchronisation d'état peu fréquente
Selon une étude de 2025 sur les architectures web, 62% des besoins "temps réel" sont en réalité satisfaits par du polling avec un intervalle de 5-30 secondes.
Server-Sent Events : le juste milieu méconnu
SSE est une technologie standardisée (HTML5) permettant au serveur d'envoyer des données au client via une connexion HTTP persistante. Contrairement aux WebSockets, la communication est unidirectionnelle : serveur vers client uniquement.
Fonctionnement : Le client ouvre une connexion HTTP qui reste ouverte. Le serveur envoie des événements quand il le souhaite. Le client écoute passivement.
Avantages :
- Connexion persistante, latence minimale pour les push serveur
- Fonctionne sur HTTP/1.1 standard, traverse la plupart des proxies
- Reconnexion automatique native dans les navigateurs
- Plus simple à implémenter côté serveur que WebSockets
Inconvénients :
- Unidirectionnel (serveur vers client uniquement)
- Limite de connexions simultanées par domaine (6 en HTTP/1.1)
- Pas supporté par certains anciens navigateurs (IE, Edge Legacy)
Cas d'usage idéaux :
- Notifications push
- Flux d'actualités
- Mises à jour de prix
- Streaming de réponses IA (comme ChatGPT)
Le streaming des réponses LLM a remis SSE sur le devant de la scène : 78% des interfaces d'IA générative utilisent SSE pour afficher les réponses token par token.
WebSockets : la puissance bidirectionnelle
WebSockets établit une connexion TCP bidirectionnelle persistante entre client et serveur. Les deux parties peuvent envoyer des données à tout moment sans initier de nouvelle requête.
Fonctionnement : Handshake HTTP initial, puis upgrade vers le protocole WebSocket. Connexion maintenue ouverte pour communication bidirectionnelle.
Avantages :
- Communication bidirectionnelle vraie
- Latence minimale dans les deux sens
- Protocole binaire efficace
- Idéal pour les interactions intensives
Inconvénients :
- Infrastructure serveur dédiée requise (pas de serverless natif)
- Complexité de scaling horizontal
- Certains proxies et firewalls posent problème
- Gestion d'état connexion à implémenter
Cas d'usage idéaux :
- Chat et messagerie instantanée
- Jeux multijoueurs
- Collaboration temps réel (édition simultanée)
- Trading haute fréquence
Matrice de décision pratique
Question 1 : La communication doit-elle être bidirectionnelle ?
Si votre client a besoin d'envoyer des données fréquemment au serveur (pas juste des requêtes occasionnelles), WebSockets devient pertinent. Exemples : chat, jeux, éditeurs collaboratifs.
Si le serveur pousse des données et le client écoute passivement, SSE suffit. Exemples : notifications, flux de prix, dashboards.
Si le client interroge et le serveur répond ponctuellement, Polling est approprié. Exemples : vérification de statut, synchronisation périodique.
Question 2 : Quelle latence est acceptable ?
- Moins de 100ms : WebSockets obligatoire
- 100ms à 1s : SSE recommandé
- Plus de 1s : Polling suffisant
Pour un tableau de bord de gestion, une latence de 5-10 secondes est souvent acceptable. Pour une application de trading, 100ms est déjà trop.
Question 3 : Quelle est votre infrastructure ?
Si vous utilisez des plateformes serverless (Vercel, Netlify, AWS Lambda), les WebSockets natifs sont compliqués. Des solutions comme Pusher, Ably, ou Socket.io avec adaptateur serverless ajoutent de la complexité et des coûts.
SSE fonctionne sur la plupart des plateformes serverless avec quelques ajustements. Polling fonctionne partout sans exception.
Question 4 : Combien de connexions simultanées ?
| Technologie | Connexions/serveur | Coût scaling | |-------------|-------------------|--------------| | Polling | 10,000+ facile | Faible | | SSE | 1,000-5,000 | Moyen | | WebSockets | 1,000-10,000 | Élevé |
Ces chiffres varient selon l'implémentation, mais l'ordre de grandeur reste valide.
Implémentation pratique : cas du dashboard
Prenons un exemple concret : un dashboard de métriques business pour une PME marocaine. Les données sont mises à jour toutes les minutes par un job backend.
Solution initiale réflexe : WebSockets
L'équipe propose d'implémenter Socket.io pour du "vrai temps réel". Coût estimé : 3 jours de développement, serveur dédié pour la gestion des connexions, infrastructure de pub/sub (Redis) pour le scaling.
Solution appropriée : Polling intelligent
Un polling toutes les 30 secondes avec cache HTTP approprié. Coût : 4 heures de développement, aucune infrastructure supplémentaire, fonctionne sur l'hébergement serverless existant.
Pourquoi ? Les données changent au maximum toutes les minutes. Une latence de 30 secondes est invisible pour l'utilisateur. Le polling avec ETag/Last-Modified minimise le transfert de données.
Quand SSE aurait été le bon choix
Si le dashboard devait afficher des alertes instantanées (stock critique, commande urgente), SSE permettrait de pousser ces événements immédiatement tout en conservant une architecture simple.
Patterns d'architecture hybride
En pratique, les applications modernes combinent souvent plusieurs approches :
Pattern 1 : Polling + SSE pour les alertes
- Polling pour la synchronisation de données régulière
- SSE pour les notifications urgentes
C'est l'approche de nombreuses applications SaaS. Slack, par exemple, utilise WebSockets pour les messages mais du polling pour la synchronisation d'état.
Pattern 2 : Dégradation gracieuse
WebSockets en premier choix, fallback sur SSE si le WebSocket échoue, puis polling si SSE n'est pas supporté. Socket.io implémente cette logique automatiquement.
Pattern 3 : Segmentation par fonctionnalité
- Chat interne : WebSockets
- Tableau de bord : Polling
- Notifications : SSE
Chaque fonctionnalité utilise la technologie optimale pour son cas d'usage, avec un développement sur mesure adapté à chaque besoin.
Coûts et considérations business
Développement
| Technologie | Temps dev initial | Maintenance | |-------------|-------------------|-------------| | Polling | 1x | Faible | | SSE | 1.5x | Moyenne | | WebSockets | 2-3x | Élevée |
Infrastructure
Le polling n'ajoute aucun coût infrastructure. SSE peut nécessiter des ajustements de timeout. WebSockets requiert souvent des serveurs dédiés ou des services managés (150-500 €/mois pour 10,000 connexions).
Scalabilité
Scaling horizontal avec Polling : trivial (load balancer standard). Scaling horizontal avec SSE : modéré (sticky sessions parfois nécessaires). Scaling horizontal avec WebSockets : complexe (pub/sub, Redis, sticky sessions obligatoires).
Recommandations pour les équipes marocaines
Startups en early-stage
Commencez par Polling. Vous pouvez toujours migrer vers SSE ou WebSockets quand le besoin réel se manifeste. L'over-engineering précoce tue plus de startups que le manque de performances.
PME avec équipe technique limitée
SSE offre le meilleur rapport complexité/fonctionnalité. La majorité des cas d'usage "temps réel" sont couverts sans la complexité des WebSockets.
Applications à fort trafic
Investissez dans une architecture WebSockets bien conçue avec un audit technique préalable. Le coût de refactoring ultérieur dépasse souvent l'investissement initial.
Outils et frameworks recommandés
Pour Polling
- SWR (React) : polling intelligent avec cache
- TanStack Query : polling avec déduplication
- Axios avec intercepteurs : polling custom
Pour SSE
- EventSource API (natif navigateur)
- eventsource-polyfill (pour IE/Edge legacy)
- Hono, Express, Fastify côté serveur
Pour WebSockets
- Socket.io : solution complète avec fallbacks
- ws : bibliothèque Node.js légère
- Pusher, Ably : services managés
Related Resources
Comparing providers? Check out our detailed comparison:
FAQ
WebSockets consomme-t-il plus de batterie sur mobile ?
Oui, une connexion WebSocket maintenue consomme de la batterie même inactive. Pour les applications mobiles avec contraintes batterie, Polling ou SSE avec intervalles adaptés sont préférables. Des études montrent une différence de 15-25% de consommation batterie selon l'implémentation.
Comment tester la performance de ma solution temps réel ?
Utilisez des outils comme k6 ou Artillery pour simuler des milliers de connexions simultanées. Mesurez la latence p95 et p99, pas juste la moyenne. Pour WebSockets, testez spécifiquement les reconnexions après perte réseau.
SSE fonctionne-t-il derrière un proxy d'entreprise ?
Généralement oui, car SSE utilise HTTP standard. Cependant, certains proxies ferment les connexions longues après un timeout (souvent 60-120 secondes). Implémentez un heartbeat côté serveur pour maintenir la connexion active.
Puis-je utiliser WebSockets avec Vercel ou Netlify ?
Pas nativement. Ces plateformes serverless ne supportent pas les connexions persistantes. Utilisez des services tiers comme Pusher, Ably, ou Supabase Realtime qui s'intègrent bien avec ces plateformes.
Quelle est la limite de connexions SSE par domaine ?
En HTTP/1.1, les navigateurs limitent à 6 connexions simultanées par domaine. Avec HTTP/2, cette limite disparaît grâce au multiplexage. Assurez-vous que votre serveur et CDN supportent HTTP/2 pour éviter ce problème.