FR
RU
EN
ES
ZH
DE
PT
AR
HI
Que se cache-t-il derrière la mise à jour « en direct » des données ? Décryptage des technologies temps réel
\n\nAvez-vous déjà réfléchi au fonctionnement d'un chat où les messages arrivent instantanément, ou d'un flux de cotations boursières qui se met à jour tout seul ? La requête HTTP classique (où le navigateur frappe à la porte du serveur et le serveur répond) ne convient pas ici – trop lente et inefficace. Il faut la magie du temps réel.
\n\nSur Stack Overflow, la question « What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet? » a recueilli des milliers de vues. Cela signifie que la confusion autour de ces termes est un phénomène normal. Aujourd'hui, nous allons tout clarifier, écrire du vrai code en PHP et comprendre quand utiliser quelle technologie.
\n\nNous n'utiliserons pas de frameworks complexes – seulement du PHP pur et quelques bibliothèques populaires. C'est parti !
\n\n1. HTTP Polling (Interrogation classique) – le grand-père des technologies
\n\nAvant de parler de choses avancées, rappelons le polling de base. Le client (JavaScript) envoie simplement une requête au serveur toutes les N secondes. Le serveur répond : « Pas de nouvelles données » ou « Voici les données ».
\n\nCode en PHP (partie serveur) :
\n<?php\n// polling_server.php\nheader('Content-Type: application/json');\n\n// Simuler la réception de données\n$data = ['message' => 'Bonjour à ' . date('H:i:s')];\necho json_encode($data);\nPartie cliente (JavaScript) :
\nsetInterval(() => {\n fetch('polling_server.php')\n .then(response => response.json())\n .then(data => console.log(data.message));\n}, 3000); // Toutes les 3 secondesAvantages : simplicité. Inconvénients : une multitude de requêtes inutiles, charge sur le serveur, latence jusqu'à N secondes. Pour un chat, c'est la mort.
\n\n2. Long-Polling – une solution de contournement élégante
\n\nLong-Polling est une version améliorée du polling. Le client ouvre une requête HTTP, et le serveur ne répond pas immédiatement s'il n'y a pas de données. Il maintient la connexion ouverte (reste en attente). Dès que les données apparaissent, le serveur envoie la réponse et ferme la connexion. Le client ouvre immédiatement une nouvelle requête.
\n\nDu point de vue du client, c'est un fetch classique. Du point de vue du serveur, il faut savoir « s'endormir » et se réveiller.
\n\nExemple de Long-Polling en PHP
\n<?php\n// long_polling.php\nheader('Content-Type: application/json');\nheader('Cache-Control: no-cache');\n\n// Simuler l'attente de nouveaux messages (par exemple, depuis un fichier ou une BDD)\n$lastCheck = time();\n$timeout = 30; // on attend au maximum 30 secondes\n\nwhile (time() - $lastCheck < $timeout) {\n // Vérifier si de nouvelles données sont apparues\n $newData = checkForNewMessages(); // votre fonction\n if ($newData !== null) {\n echo json_encode(['status' => 'ok', 'data' => $newData]);\n exit;\n }\n // Dormir 1 seconde pour ne pas surcharger le processeur\n sleep(1);\n}\n\n// Si aucune donnée pendant 30 secondes – répondre avec une réponse vide\necho json_encode(['status' => 'timeout', 'data' => null]);\nImportant : Dans un projet réel, remplacez sleep(1) par usleep(500000) (0,5 sec) et utilisez des vérifications non bloquantes (par exemple, filemtime() pour un fichier ou SELECT ... FOR UPDATE avec timeout dans la BDD).
Où est-ce utilisé : anciens chats, notifications sur des sites sans WebSockets. Inconvénient : toujours beaucoup de connexions, le serveur consomme des ressources sur les requêtes « en suspens ».
\n\n3. Server-Sent Events (SSE) – canal unidirectionnel depuis le serveur
\n\nSSE (Server-Sent Events) est une technologie intégrée à HTML5. Le serveur peut envoyer des données au client à tout moment, mais uniquement dans un sens (serveur → client). Le client est un simple EventSource en JavaScript.
\n\nSSE est idéal pour : les flux d'actualités, les cotations, les logs, les notifications.
\n\nCode en PHP (serveur) :
\n<?php\n// sse_server.php\nheader('Content-Type: text/event-stream');\nheader('Cache-Control: no-cache' 
