"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
Checklist de décision avant d'écrire la moindre ligne de code
La plupart des mauvais choix techniques ne viennent pas d'un manque de compétence, mais d'une décision prise trop vite, avant d'avoir clarifié le besoin réel. Avant de trancher entre Polling, SSE et WebSockets, parcourez cette liste de questions dans l'ordre. Chacune élimine des options et vous rapproche du choix le plus sobre possible.
- Quel est le sens réel du flux ? Notez sur papier qui envoie quoi à qui. Si seul le serveur a quelque chose à pousser, vous pouvez déjà rayer WebSockets de la liste dans la majorité des cas.
- À quelle fréquence la donnée change-t-elle vraiment ? Distinguez la fréquence souhaitée par le commanditaire de la fréquence à laquelle la donnée bouge réellement en base. Une donnée qui change une fois par minute ne justifie jamais une connexion permanente.
- Quelle latence l'utilisateur perçoit-il comme acceptable ? Testez-le honnêtement : montrez une maquette qui se rafraîchit à différents intervalles et observez si quelqu'un remarque la différence. Souvent, personne ne la voit.
- Sur quelle infrastructure allez-vous déployer ? Si la réponse est serverless ou edge, partez du principe que Polling ou SSE seront beaucoup moins douloureux que des WebSockets nécessitant un service managé externe.
- Combien de connexions simultanées au pic ? Multipliez par une marge de sécurité, puis confrontez ce chiffre à la matrice plus haut. Le coût d'exploitation grimpe beaucoup plus vite avec les connexions persistantes.
- Qui maintiendra le système dans un an ? Une petite équipe gagnera presque toujours à choisir la solution la plus simple à déboguer un vendredi soir, plutôt que la plus élégante sur le papier.
Si après ces six questions vous hésitez encore, c'est généralement le signe que le besoin est plus modeste que prévu : commencez par l'approche la plus légère et gardez la migration en réserve.
Pièges fréquents et comment les éviter
Au-delà du choix de la technologie, c'est souvent l'implémentation qui décide de la réussite ou de l'échec d'une fonctionnalité temps réel. Voici les écueils que l'on rencontre le plus souvent sur le terrain, et les réflexes qui permettent de les contourner.
Confondre "instantané" et "fréquent"
Beaucoup de demandes "temps réel" sont en réalité des demandes de rafraîchissement plus visible. Un utilisateur qui voit ses chiffres bouger toutes les quelques secondes a déjà l'impression d'un produit vivant. Réservez l'instantanéité stricte aux interactions où l'attente se ressent immédiatement, comme une conversation ou une édition partagée.
Oublier la reconnexion et les coupures réseau
Une connexion persistante finit toujours par tomber : Wi-Fi qui saute, passage en 4G, mise en veille de l'onglet. SSE gère la reconnexion nativement, mais avec WebSockets vous devez prévoir explicitement une logique de reconnexion progressive et une resynchronisation de l'état. Testez votre solution en coupant volontairement le réseau, pas seulement dans des conditions idéales.
Négliger le heartbeat sur les connexions longues
Les proxies, équilibreurs de charge et CDN ferment volontiers les connexions inactives. Sans signal de maintien régulier, vos utilisateurs subiront des déconnexions silencieuses qu'ils interpréteront comme un bug. Un simple message périodique côté serveur évite la grande majorité de ces incidents.
Polluer le client avec des mises à jour inutiles
Pousser chaque micro-changement vers le navigateur peut saturer l'interface et l'autonomie de la batterie. Regroupez les changements, n'envoyez que ce qui est visible à l'écran, et laissez le reste se synchroniser plus tranquillement. La sobriété côté réseau se ressent directement sur la fluidité perçue.
Construire pour une échelle que vous n'avez pas
Mettre en place du pub/sub distribué et des sticky sessions pour quelques dizaines d'utilisateurs revient à louer un camion pour déménager un carton. Dimensionnez pour votre charge actuelle plus une marge raisonnable, et documentez le chemin de migration plutôt que de l'anticiper dans le code dès le premier jour.
Ne pas observer ce qui se passe en production
Une fonctionnalité temps réel sans métriques est une boîte noire. Suivez le nombre de connexions actives, le taux de reconnexion et la latence réelle perçue côté client. Ces indicateurs vous diront, bien mieux qu'une intuition, s'il faut un jour passer à l'échelle supérieure ou si votre approche actuelle tient parfaitement la route.
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.
Faut-il migrer de Polling vers WebSockets dès que le produit grandit ?
Pas automatiquement. La bonne question n'est pas la taille du produit mais la nature du besoin : si le flux reste majoritairement descendant et tolère quelques secondes de latence, le polling bien optimisé peut accompagner une croissance importante sans douleur. Déclenchez la migration quand un besoin précis apparaît (interactions bidirectionnelles intensives, latence sous la seconde réellement perçue), pas par anticipation. Gardez simplement votre couche de récupération de données suffisamment isolée pour pouvoir changer de transport sans réécrire toute l'application.
Peut-on mélanger SSE et WebSockets dans la même application ?
Oui, et c'est même fréquent. Rien n'oblige à choisir une seule technologie pour l'ensemble du produit. Vous pouvez réserver les WebSockets aux fonctionnalités réellement bidirectionnelles (messagerie, édition collaborative) et confier à SSE les flux purement descendants (notifications, mises à jour de statut). L'important est de garder une logique claire : documentez quelle fonctionnalité utilise quel transport, afin que l'équipe ne se perde pas et que le débogage reste simple.