Pusher — qu'est-ce que c'est, plateforme temps réel et intégration dans les applications

Qu'est-ce que Pusher ?

Pusher est un service cloud pour la communication bidirectionnelle en temps réel, fondé en 2011. Il fournit une infrastructure prête à l'emploi pour envoyer et recevoir des messages en temps réel sans avoir à gérer votre propre serveur WebSocket. Pusher est utilisé pour construire des chats, des notifications en direct, l'édition collaborative et des classements de jeux.

Contrairement aux bibliothèques comme Socket.IO, qui nécessitent le déploiement et la maintenance de votre propre serveur, Pusher fonctionne selon un modèle SaaS (Software as a Service). Le développeur s'inscrit, obtient des clés (app_id, key, secret) et utilise l'API REST de Pusher pour publier des événements. L'infrastructure serveur est entièrement gérée par la plateforme Pusher.

Selon le blog officiel de Pusher (2025), la plateforme dessert plus de 250 000 projets actifs dans le monde. Parmi les clients connus figurent GitHub (notifications en temps réel), Trello (synchronisation de tableaux) et Intercom (chat de support). Pusher dispose de centres de données aux États-Unis, en Europe et en Asie pour minimiser la latence.

Historique du développement de Pusher

Pusher a été lancé en 2011 comme l'un des premiers services hébergés pour WebSocket. En 2014, l'entreprise a présenté Pusher Channels — l'architecture actuelle avec prise en charge des canaux private et presence. En 2017, la prise en charge des webhooks pour les événements côté serveur a été ajoutée. En 2022, Pusher a lancé Pusher Beams, un service de notifications push pour les plateformes mobiles.

L'architecture de Pusher diffère des solutions auto-hébergées car tout le traitement des abonnements, la gestion des connexions et le routage des événements se font du côté de Pusher Cloud. Le développeur gère uniquement l'authentification des canaux private via son backend.

Comment fonctionne Pusher

L'architecture de Pusher est basée sur le modèle Publisher-Subscriber. Les applications serveur publient des événements via l'API REST de Pusher, et les applications client les reçoivent via une connexion WebSocket persistante. Pusher agit comme intermédiaire entre les éditeurs et les abonnés.

Lorsque le serveur envoie un événement via une requête POST à l'API Pusher, la plateforme détermine le canal cible et distribue le message à tous les clients abonnés à ce canal. Les clients reçoivent l'événement via une connexion WebSocket déjà ouverte, offrant une latence de 50 à 100 ms selon l'emplacement géographique.

Chaque client établit une connexion via le Pusher Client SDK, qui sélectionne automatiquement le transport (WebSocket — priorité, HTTP long-polling — repli). Le SDK gère la reconnexion, la sérialisation des données et la gestion des erreurs sans intervention du développeur. Selon la documentation technique de Pusher (2025), le temps de reconnexion après une interruption réseau est inférieur à 1 seconde.

Composants de Pusher

Le système se compose de trois composants : Pusher Server API (points de terminaison REST pour publier des événements), Pusher Client SDK (bibliothèques pour s'abonner aux événements) et Pusher WebHook (notifications au serveur des événements de connexion/déconnexion). Tous les composants fonctionnent de manière asynchrone et indépendante.

Types de canaux Pusher

Pusher Channels prend en charge trois types de canaux, chacun conçu pour différents cas d'utilisation. Le type de canal détermine le niveau d'accès, le mécanisme d'authentification et les capacités disponibles.

Les canaux Public sont disponibles pour tous les clients sans authentification et conviennent aux données de diffusion. Les canaux Private nécessitent une authentification via le serveur du développeur : le client envoie une requête à son backend avec socket_id et channel_name, le serveur signe la requête avec la clé secrète Pusher et retourne un jeton d'authentification. Les canaux Presence transmettent en plus les informations utilisateur (user_id, user_info) et permettent de savoir qui est actuellement en ligne.

Selon la documentation Pusher (2025), le nombre maximum de clients connectés simultanément par canal est de 10 000 pour les canaux public et private. Pour les canaux presence, la limite est de 10 000 utilisateurs par canal avec prise en charge jusqu'à 100 000 utilisateurs par application.

Événements et déclencheurs Pusher

Le modèle d'événements Pusher est basé sur des événements nommés publiés dans un canal. Chaque événement a un nom (200 caractères maximum), des données au format JSON et un socket_id optionnel pour éviter l'envoi en double à l'initiateur de l'événement.

Les déclencheurs sont des requêtes HTTP POST à l'API Pusher qui publient un événement dans un canal. Format de requête : POST /apps/{app_id}/events avec un corps contenant channel, name et data. L'API serveur Pusher prend en charge les déclencheurs depuis n'importe quel environnement serveur via des bibliothèques officielles (PHP, Ruby, Python, Go, Java, Node.js).

Pusher prend en charge les déclencheurs par lots — publication d'un événement dans plusieurs canaux avec une seule requête. C'est plus efficace que les appels séquentiels et garantit une livraison atomique. Selon les tests de performance Pusher (2024), un déclencheur par lots sur 100 canaux prend 30 à 50 ms, tandis que les appels séquentiels prennent 2 à 5 secondes.

Intégration Webhook

Pusher WebHook permet à votre serveur de recevoir des notifications sur les événements d'infrastructure : connexion client, déconnexion, occurrence d'erreur. Les requêtes Webhook sont signées avec HMAC-SHA256 pour vérification. C'est essentiel pour la journalisation, l'analyse et la synchronisation d'état.

Comment intégrer Pusher dans un projet

L'intégration de Pusher se compose de deux parties : côté serveur (publication d'événements) et côté client (abonnement aux événements). Voyons un exemple utilisant Node.js pour la partie serveur et JavaScript pour la partie client. Tout d'abord, vous devez créer une application dans le tableau de bord Pusher et obtenir des identifiants.

Selon la documentation Pusher (2025), le plan de base (Sandbox) comprend jusqu'à 100 connexions simultanées et 200 000 messages par jour — suffisant pour le développement et les tests. Les plans de production commencent à 49 $/mois pour 1000 connexions.

Code serveur : publication d'un événement

const Pusher = require('pusher');

const pusher = new Pusher({
    appId: 'YOUR_APP_ID',
    key: 'YOUR_KEY',
    secret: 'YOUR_SECRET',
    cluster: 'eu',
    useTLS: true
});

pusher.trigger('my-channel', 'my-event', {
    message: 'Hello from server',
    timestamp: Date.now()
}).then(() => {
    console.log('Événement publié');
}).catch(console.error);

Code client : abonnement aux événements

import Pusher from 'pusher-js';

const pusher = new Pusher('YOUR_KEY', {
    cluster: 'eu',
    forceTLS: true
});

const channel = pusher.subscribe('my-channel');

channel.bind('my-event', (data) => {
    console.log('Événement reçu :', data);
    displayNotification(data.message);
});

Pusher dans les applications mobiles

Pusher fournit des SDK pour iOS (Swift) et Android (Java/Kotlin) qui reproduisent entièrement les fonctionnalités du client JavaScript. Les SDK mobiles prennent en charge les mêmes types de canaux, mécanisme d'authentification et modèle d'événements. Pour React Native, le package pusher-js est disponible, fonctionnant via le pont JavaScript.

Sur les appareils mobiles, le SDK Pusher gère automatiquement la commutation entre le Wi-Fi et les réseaux mobiles en utilisant un mécanisme de reconnexion avec backoff exponentiel. C'est particulièrement important pour les applications iOS, où iOS peut fermer de force les connexions WebSocket en fonctionnement en arrière-plan.

Selon le blog technique de Pusher (2024), la consommation moyenne de trafic d'une connexion Pusher est de 1 à 2 Ko par minute en l'absence d'événements actifs. Ceci est réalisé grâce à un protocole heartbeat optimisé avec un intervalle de 30 secondes. Une application de taille moyenne peut supporter jusqu'à 1000 connexions Pusher simultanées sans impact significatif sur l'autonomie de la batterie.

Pusher Beams pour les notifications push

Pusher Beams est un service supplémentaire pour envoyer des notifications push aux appareils mobiles via APNs (iOS) et FCM (Android). Beams s'intègre à Pusher Channels : un événement d'un canal peut automatiquement déclencher une notification push si le client est hors ligne. Cela résout le problème de livraison des messages lorsque l'application est fermée.

Sécurité et authentification Pusher

La sécurité de Pusher est implémentée à plusieurs niveaux. Chaque requête à l'API Pusher est signée avec HMAC-SHA256 en utilisant app_secret. Cela garantit que seul un serveur autorisé peut publier des événements. Les SDK clients utilisent app_key pour l'identification de l'application, mais l'accès aux canaux private et presence nécessite une authentification supplémentaire.

L'authentification des canaux private se fait en trois étapes : le client appelle pusher.subscribe('private-channel'), le Pusher Client SDK envoie une requête HTTP à votre point de terminaison backend (/pusher/auth), le serveur vérifie les droits de l'utilisateur et retourne un jeton d'authentification signé avec la clé secrète. Pusher vérifie la signature et autorise l'abonnement.

Il est recommandé d'utiliser des connexions TLS pour toutes les requêtes (paramètre useTLS: true dans le SDK). Pusher prend également en charge les restrictions d'accès par adresse IP pour les requêtes serveur à l'API REST. Pour les plans entreprise, le support VPC (Virtual Private Cloud) et des clusters dédiés avec infrastructure isolée sont disponibles.