Accueil › Glossaire › Pub/Sub

Pub/Sub (Publish/Subscribe)

Le Pub/Sub (Publish/Subscribe) est un pattern de communication asynchrone dans lequel des producteurs (publishers) envoient des messages à des topics sans connaître les consommateurs, et des consommateurs (subscribers) s’abonnent à ces topics pour recevoir les messages pertinents, le tout orchestré par un broker intermédiaire qui assure le découplage complet entre émetteurs et récepteurs.

Comment fonctionne le Pub/Sub

Le Pub/Sub repose sur quatre composants fondamentaux. Le publisher est l’application qui crée et envoie des messages. Il les publie sur un topic (un canal nommé qui catégorise les messages) sans savoir qui va les lire. Le broker (intermédiaire) reçoit les messages, les stocke si nécessaire, et les distribue aux abonnés. Le subscriber s’inscrit aux topics qui l’intéressent et reçoit une copie de chaque message publié.

Le point clé : le publisher ne connaît pas les subscribers, et les subscribers ne connaissent pas le publisher. Toute la communication passe par le broker. Cette séparation totale s’appelle le découplage, et c’est ce qui rend le pattern si puissant pour les architectures distribuées.

Le flux d’un message

Voici la séquence complète :

1. Un publisher envoie un message au broker, attaché à un topic (par exemple commandes.nouvelles).
2. Le broker vérifie quels subscribers sont abonnés à ce topic.
3. Le broker transmet une copie du message à chaque subscriber abonné. C’est le fanout : un message publié est distribué à N consommateurs.
4. Chaque subscriber traite le message indépendamment.
5. Le subscriber envoie un accusé de réception (ACK) au broker pour confirmer le traitement.
6. Le broker supprime le message (ou le conserve selon la politique de rétention).

Types de filtrage

Tous les subscribers ne veulent pas tous les messages. Le filtrage se fait de deux manières. Le filtrage par topic est le plus courant : le subscriber s’abonne à un topic spécifique et ne reçoit que les messages de ce topic. Le filtrage par contenu va plus loin : le subscriber définit des contraintes sur les attributs du message (par exemple, ne recevoir que les commandes dont le montant dépasse 1 000 €). Certains systèmes combinent les deux approches.

Pub/Sub vs Message Queue

La confusion entre Pub/Sub et message queue est fréquente, mais la différence est fondamentale.

Dans un système de message queue, un message est consommé par un seul consommateur. Si trois workers écoutent la même queue, chaque message est traité par un seul d’entre eux (distribution de charge). C’est du point-to-point.

En Pub/Sub, un message est distribué à tous les subscribers abonnés au topic. Si trois services écoutent le topic commandes.nouvelles, les trois reçoivent une copie du message. C’est du fanout (one-to-many).

Les principaux outils Pub/Sub

L’écosystème est riche. Voici les solutions les plus utilisées, avec leurs forces respectives.

Apache Kafka

Kafka est le standard de fait pour le streaming d’événements à haute échelle. Ce n’est pas un broker Pub/Sub classique mais un log distribué : les messages sont persistés dans des partitions ordonnées et peuvent être relus. Les consumer groups permettent à la fois du fanout et du load balancing. Kafka gère des millions de messages par seconde et est utilisé par LinkedIn, Netflix, Uber et la plupart des grandes plateformes.

Le point fort de Kafka est la durabilité : les messages sont stockés et rejouables. Son point faible est la complexité opérationnelle, même si des services managés comme Confluent Cloud ou Amazon MSK simplifient le déploiement.

Google Cloud Pub/Sub

Le service managé de Google facture $40 par TiB au-delà d’un palier gratuit de 10 Go par mois. C’est un service serverless : pas de partitions à gérer, pas de capacité à provisionner (contrairement à Kafka). Il supporte les souscriptions push (webhook) et pull, avec livraison at-least-once. Google a arrêté Pub/Sub Lite (la version à coût réduit) le 18 mars 2026, poussant les utilisateurs vers le Pub/Sub standard ou vers Google Cloud Managed Service for Apache Kafka.

Redis Pub/Sub

Redis offre un Pub/Sub intégré, ultra-simple et rapide. Le publisher envoie un message à un channel, tous les subscribers actifs le reçoivent instantanément. Mais attention : c’est du « fire-and-forget ». Si aucun subscriber n’est connecté au moment de la publication, le message est perdu. Pas de persistance, pas d’accusé de réception, pas de consumer groups. Redis Pub/Sub est idéal pour l’invalidation de cache, les notifications en temps réel, ou comme couche de communication entre serveurs dans un cluster de long polling. Pour du traitement fiable, Redis Streams est préférable.

AWS SNS + SQS

Amazon propose SNS (Simple Notification Service) pour le Pub/Sub pur et SQS (Simple Queue Service) pour les message queues. Le pattern classique est de combiner les deux : SNS diffuse un événement à plusieurs queues SQS, chacune traitée par un service différent. C’est le pattern « fanout to queues » qui offre à la fois la diffusion du Pub/Sub et la fiabilité des queues.

RabbitMQ

RabbitMQ est un broker de messages polyvalent qui supporte les deux modèles (queues et Pub/Sub via les exchanges de type « fanout » ou « topic »). Sa force est la flexibilité du routage : les exchanges permettent des patterns de filtrage sophistiqués. RabbitMQ est plus adapté aux architectures de microservices de taille moyenne qu’au streaming massif.

Comparaison rapide

Pub/Sub dans l’écosystème IA

Le Pub/Sub est devenu un composant fondamental des architectures IA modernes, en particulier pour les systèmes multi-agents et les pipelines de machine learning event-driven.

Systèmes multi-agents event-driven

Les frameworks d’agents IA comme AutoGen, CrewAI et LangGraph s’appuient de plus en plus sur des architectures event-driven. Le principe : chaque agent publie des événements sur des topics (par exemple « analyse-terminée », « décision-prise ») et les autres agents s’abonnent aux événements qui les concernent.

Ce modèle résout un problème majeur des systèmes multi-agents : la complexité des connexions. Dans une architecture point-to-point, N agents nécessitent jusqu’à N² connexions. Avec un broker Pub/Sub, chaque agent maintient une seule connexion au broker, réduisant la complexité à O(N). Un nouvel agent peut rejoindre le système en s’abonnant aux topics pertinents sans modifier les agents existants.

Google Cloud recommande explicitement Pub/Sub comme couche de communication pour les systèmes multi-agents, le décrivant comme idéal pour les architectures découplées et les interactions event-driven entre agents.

Pipelines MLOps event-driven

Dans les architectures MLOps, le Pub/Sub orchestre les étapes du cycle de vie des modèles. Un événement « nouvelles-données-disponibles » déclenche le retraining. Un événement « modèle-entraîné » déclenche l’évaluation. Un événement « évaluation-réussie » déclenche le déploiement. Chaque étape est un service indépendant qui réagit aux événements, plutôt qu’un pipeline rigide câblé en dur.

Cette approche est particulièrement adaptée aux architectures sur cloud avec Google Cloud (Pub/Sub + Vertex AI + Dataflow), AWS (SNS/SQS + SageMaker) ou Azure (Event Grid + Azure ML).

Streaming de données pour l’inférence temps réel

Quand un modèle de ML doit traiter des données en flux continu (détection de fraude, recommandation en temps réel, monitoring d’anomalies), le Pub/Sub sert de pont entre les sources de données et le modèle. Les événements arrivent sur un topic, un service d’inférence les consomme et génère des prédictions, qui sont elles-mêmes publiées sur un topic de résultats.

Pub/Sub et le protocole A2A

Le protocole A2A (Agent-to-Agent), initié par Google, standardise la communication entre agents IA de différents frameworks. Il complète le MCP (qui gère la communication agent-outil) en se focalisant sur l’interaction entre agents. Les architectures event-driven avec Pub/Sub sont la fondation naturelle de A2A : les agents publient et consomment des événements via un broker, sans avoir besoin de connaître les détails d’implémentation des autres agents.

Implémentation pratique

Exemple avec Redis Pub/Sub (Python)

Redis Pub/Sub est le moyen le plus rapide de tester le pattern. Voici un publisher et un subscriber minimalistes :

# publisher.py
import redis
import json

r = redis.Redis(host='localhost', port=6379)

event = {
    "type": "ticket.classified",
    "data": {
        "ticket_id": "T-4521",
        "category": "technical",
        "priority": "high"
    }
}

r.publish("support-events", json.dumps(event))
print(f"Événement publié sur 'support-events'")

# subscriber.py
import redis
import json

r = redis.Redis(host='localhost', port=6379)
pubsub = r.pubsub()
pubsub.subscribe("support-events")

print("En attente de messages sur 'support-events'...")
for message in pubsub.listen():
    if message["type"] == "message":
        event = json.loads(message["data"])
        print(f"Reçu : {event['type']} - Ticket {event['data']['ticket_id']}")
        # Traiter l'événement selon son type
        if event["type"] == "ticket.classified":
            print(f"  → Catégorie : {event['data']['category']}")
            print(f"  → Priorité : {event['data']['priority']}")

Exemple avec Google Cloud Pub/Sub (Python)

# Publisher Google Cloud Pub/Sub
from google.cloud import pubsub_v1
import json

publisher = pubsub_v1.PublisherClient()
topic_path = publisher.topic_path("mon-projet", "inference-requests")

message = json.dumps({
    "model": "fraud-detection-v3",
    "input": {"transaction_id": "TX-98765", "amount": 4500}
})

future = publisher.publish(topic_path, message.encode("utf-8"))
print(f"Message publié, ID: {future.result()}")

# Subscriber Google Cloud Pub/Sub
from google.cloud import pubsub_v1
import json

subscriber = pubsub_v1.SubscriberClient()
subscription_path = subscriber.subscription_path(
    "mon-projet", "inference-requests-sub"
)

def callback(message):
    data = json.loads(message.data.decode("utf-8"))
    print(f"Requête d'inférence reçue : modèle={data['model']}")
    # Lancer l'inférence...
    message.ack()  # Confirmer le traitement

streaming_pull = subscriber.subscribe(subscription_path, callback=callback)
print("En écoute...")
streaming_pull.result()  # Bloquant

Avantages et limites du Pub/Sub

Avantages

Le découplage est le bénéfice numéro un. Les publishers et subscribers évoluent indépendamment : vous pouvez ajouter un nouveau subscriber sans modifier le publisher, remplacer un service sans impacter les autres, et scaler chaque composant séparément. C’est exactement ce dont les architectures de microservices ont besoin.

La scalabilité est un autre atout majeur. Un publisher peut diffuser vers des milliers de subscribers sans effort supplémentaire. Le broker gère la distribution, le buffering, et la rétention. Les systèmes comme Kafka gèrent des milliards de messages par jour.

La résilience est intégrée dans le design. Si un subscriber tombe en panne, les messages s’accumulent dans le broker en attendant sa reprise. Les autres subscribers ne sont pas impactés. C’est une isolation des pannes naturelle.

Limites

La livraison « at-least-once » est le standard de la plupart des brokers Pub/Sub. Cela signifie qu’un message peut être livré en double, et vos subscribers doivent être idempotents (capables de traiter deux fois le même message sans effet de bord). Certains brokers offrent la livraison « exactly-once », mais avec un surcoût en performance.

L’ordre des messages n’est pas garanti par défaut dans tous les systèmes. Kafka garantit l’ordre au sein d’une partition, mais pas entre partitions. Google Cloud Pub/Sub propose un ordering par clé. Si l’ordre est critique pour votre cas d’usage, vérifiez les garanties de votre broker.

Le debugging est plus complexe qu’avec des appels synchrones. Tracer un message à travers un système Pub/Sub avec plusieurs subscribers qui publient eux-mêmes des événements nécessite des outils d’observabilité (distributed tracing, corrélation d’identifiants).

Enfin, le Pub/Sub est surdimensionné pour les architectures simples. Si vous avez deux services qui communiquent de manière point-to-point, un appel REST ou un webhook suffit. Le Pub/Sub prend tout son sens à partir de trois ou quatre services qui doivent réagir au même événement.

Bonnes pratiques d’implémentation

Concevoir des subscribers idempotents

Puisque les messages peuvent être livrés en double, chaque subscriber doit pouvoir traiter le même message deux fois sans créer de doublons ou d’incohérences. La technique classique : stocker l’identifiant de chaque message traité et ignorer les doublons.

Configurer des dead letter topics

Quand un subscriber échoue à traiter un message après plusieurs tentatives, celui-ci doit être redirigé vers un « dead letter topic » pour analyse ultérieure plutôt que de bloquer la file. Kafka, Google Cloud Pub/Sub et RabbitMQ supportent tous ce mécanisme.

Gérer l’évolution des schémas

Les messages échangés via Pub/Sub doivent avoir un format défini (JSON Schema, Avro, Protobuf). Quand le format évolue, assurez la compatibilité ascendante pour ne pas casser les subscribers existants. Confluent Schema Registry est la solution de référence pour Kafka.

Monitorer la consommation

Surveillez le « lag » de chaque subscriber (la différence entre le dernier message publié et le dernier message consommé). Un lag croissant indique un subscriber qui ne suit pas le débit. C’est un signal d’alerte pour scaler le service ou optimiser le traitement.

Nommer les topics avec intention

Utilisez une convention de nommage hiérarchique : domaine.entité.action (par exemple ecommerce.commande.créée, ia.inference.terminée, monitoring.alerte.déclenchée). Cela facilite la découverte, le filtrage par pattern, et la gouvernance.

Verdict

Le Pub/Sub est le pattern de communication de référence pour les architectures distribuées modernes. Si vous construisez un système avec plus de deux ou trois services qui doivent réagir aux mêmes événements, vous avez besoin d’un broker Pub/Sub. Pour les systèmes d’agents IA, c’est la fondation qui permet l’autonomie, la scalabilité et le découplage nécessaires à des architectures multi-agents robustes.

Pour un projet en démarrage ou un prototype, Redis Pub/Sub (ou Redis Streams pour la fiabilité) fait le travail. Pour de la production à grande échelle, Kafka (via Confluent Cloud) ou Google Cloud Pub/Sub sont les choix de référence. Et si vous êtes sur AWS, le combo SNS + SQS offre un bon compromis entre simplicité et fiabilité.