Architecture pilotée par les événements : courtiers, médiateurs et flux d’événements

Définition : réagir à ce qui se produit

Dans une architecture pilotée par les événements (EDA), les composants communiquent en produisant des événements et en y réagissant : des enregistrements de faits qui se sont produits dans l’activité, comme une commande a été passée ou un livreur a été affecté. Le composant qui publie un événement n’appelle pas les composants qui y réagissent et, en général, ne sait même pas qu’ils existent. Un courtier de messages (message broker) transporte les événements des producteurs vers les consommateurs, les conserve pendant que les consommateurs sont occupés ou indisponibles, et permet d’ajouter de nouveaux consommateurs sans modifier le producteur.

Les conceptions pilotées par les événements ne sont pas nouvelles : les interfaces graphiques, les systèmes d’exploitation et les systèmes de trading fonctionnent ainsi depuis des décennies, et les produits de messagerie d’entreprise sont antérieurs au web. Ce qui a changé dans les années 2010, c’est l’échelle et la durabilité. Les courtiers fondés sur un journal, comme Apache Kafka, créé chez LinkedIn et publié en open source en 2011, ont rendu possible de conserver chaque événement métier pendant des jours ou des années, et de les rejouer. L’EDA peut être le style principal d’un système ou, plus souvent, la façon dont les services d’un système en microservices ou à base de services communiquent entre eux.

Événements, commandes et messages

Trois mots sont souvent employés de façon approximative, et la différence compte. Un message est l’enveloppe : toute donnée envoyée d’un programme à un autre par un canal. Ce que transporte le message peut être un événement (un fait, nommé au passé), une commande (une demande adressée à un seul gestionnaire, nommée comme une instruction) ou une requête et sa réponse. Enterprise Integration Patterns (2003), de Gregor Hohpe et Bobby Woolf, a catalogué ces types de messages et les canaux qui les transportent, et son vocabulaire reste la référence.

Les messages circulent par deux types de canaux. Une file remet chaque message à l’un de ses consommateurs, ce qui convient aux commandes et à la répartition du travail. Un topic remet une copie de chaque message à chaque abonné : c’est la publication-abonnement (publish-subscribe, ou pub-sub), qui convient aux événements. Une conception qui envoie OrderPlaced à un topic permet à Paiements, Restaurant, Notifications et Analytique de réagir, chacun à son rythme ; ajouter un service de détection de fraude l’an prochain ne demande qu’un nouvel abonnement et aucun changement dans Commandes.

Topologie à courtier et topologie à médiateur

Richards et Ford décrivent deux topologies pour les systèmes pilotés par les événements. Dans la topologie à courtier (broker), il n’y a pas de coordinateur central. Un événement initiateur est publié ; chaque processeur intéressé réagit et peut publier d’autres événements, auxquels d’autres réagissent à leur tour. Le flux de travail n’existe que comme la somme de ces réactions. C’est la chorégraphie : comme des danseurs qui connaissent chacun leurs propres pas, personne ne dirige l’ensemble.

Dans la topologie à médiateur, un médiateur d’événements reçoit l’événement initiateur et dirige le flux de travail, en envoyant des commandes aux processeurs dans un ordre défini et en agissant selon leurs réponses. C’est l’orchestration : un chef d’orchestre connaît la partition. Les médiateurs vont d’un simple service doté d’une machine à états à un moteur de workflow comme Temporal, AWS Step Functions ou un moteur BPMN.

La plupart des systèmes réels mélangent les deux : chorégraphie entre contextes délimités (Commandes annonce des faits et ne se soucie pas de savoir qui écoute) et orchestration à l’intérieur d’un contexte, là où un processus en plusieurs étapes a besoin d’un responsable clair.

Quatre façons d’utiliser les événements

Dans un article de 2017, Martin Fowler a souligné que « piloté par les événements » sert à désigner au moins quatre patrons assez différents, et que les conversations tournent mal quand les interlocuteurs ne parlent pas du même. Savoir les distinguer est l’une des habitudes les plus utiles qu’un architecte puisse avoir.

La notification d’événement et le transfert d’état porté par les événements concernent la communication entre services et ont leur place dans ce chapitre. L’event sourcing et CQRS concernent la façon dont un service stocke ses données ; on les combine souvent avec l’EDA, mais ce sont des choix indépendants, traités au chapitre 7.

Flux d’événements et journaux : comment fonctionne Kafka

Les files de messages traditionnelles suppriment un message dès qu’un consommateur l’a acquitté. Un courtier fondé sur un journal, comme Apache Kafka, stocke au contraire les événements dans un journal en ajout seul (append-only) et les conserve pendant une durée de rétention configurée (ou indéfiniment), qu’ils aient été lus ou non. Plusieurs conséquences découlent de cette conception, et elles expliquent à la fois les forces de Kafka et ses pièges.

Un topic est divisé en partitions, chacune étant un journal ordonné, stocké et répliqué sur plusieurs courtiers. Un producteur choisit la partition, normalement en hachant la clé de l’événement, si bien que tous les événements de même clé (le même identifiant de commande, par exemple) vont dans la même partition. Chaque événement d’une partition a une position séquentielle appelée son offset (décalage). Les consommateurs tirent les événements et enregistrent l’offset qu’ils ont atteint ; ils peuvent aussi revenir en arrière et rejouer.

Les consommateurs rejoignent un groupe de consommateurs. Au sein d’un groupe, chaque partition est lue par un seul consommateur à la fois, si bien que le groupe se partage le travail ; des groupes différents lisent indépendamment, chacun avec ses propres offsets, et c’est ainsi que l’on obtient le pub-sub. Le nombre de partitions limite donc le parallélisme d’un groupe : un topic de 12 partitions peut occuper au plus 12 consommateurs d’un groupe. (Kafka 4.2, publié en 2026, a ajouté les share groups comme alternative de type file : plusieurs consommateurs peuvent se partager une partition et acquitter les messages individuellement, mais l’ordre au sein de la partition n’est alors plus préservé. Cette section décrit les groupes de consommateurs classiques.)

Kafka ne garantit l’ordre qu’au sein d’une partition. Les événements d’une même commande arrivent dans l’ordre où ils ont été écrits s’ils partagent une clé ; les événements de commandes différentes, dans des partitions différentes, n’ont aucun ordre défini les uns par rapport aux autres. Les conceptions qui ont besoin d’un ordre global doivent utiliser une seule partition (en renonçant au parallélisme) ou, mieux, être repensées pour que seul l’ordre par entité compte.

Garanties de livraison, et ce que signifie vraiment « exactement une fois »

Comme les réseaux et les processus tombent en panne (section 6.1), un courtier et ses clients doivent choisir ce qui se passe lorsqu’un plantage ou un délai d’expiration laisse planer un doute sur le traitement d’un message. Il existe trois garanties possibles, et le choix dépend du moment où les acquittements et les offsets sont enregistrés.

« Exactement une fois » demande une définition rigoureuse. La livraison exactement une fois sur un réseau non fiable n’est pas réalisable en général : un expéditeur qui ne reçoit pas d’acquittement ne peut pas savoir s’il doit renvoyer le message. Ce que les systèmes peuvent offrir, c’est un effet exactement une fois à l’intérieur d’une frontière définie. Kafka, par exemple, propose un producteur idempotent et des transactions depuis la version 0.11 (2017), afin qu’un cycle lecture-traitement-écriture allant de topics Kafka vers des topics Kafka valide sa sortie et les offsets de son consommateur de façon atomique. Cette garantie s’arrête à la frontière de Kafka. Si le consommateur débite une carte, envoie un e-mail ou écrit dans une autre base de données, un plantage entre cette action et la validation de l’offset entraînera la répétition de l’action, à moins que le consommateur lui-même soit idempotent ou qu’il stocke ses offsets dans la même transaction que ses résultats.

La règle pratique pour les architectes est donc simple : partez du principe d’une livraison au moins une fois et faites de chaque consommateur un consommateur idempotent. Donnez à chaque événement un identifiant unique ; dans le consommateur, enregistrez les identifiants traités dans la même transaction locale que le changement d’état, et ignorez tout événement déjà enregistré. Dans la mesure du possible, rendez aussi l’opération naturellement idempotente, par exemple « passer le statut à PAID s’il est AWAITING_PAYMENT » plutôt que « ajouter un paiement ».

# Idempotent consumer: processing the same event twice has the effect of once
def handle_payment_authorised(event, db):
    with db.transaction():                       # one local ACID transaction
        inserted = db.execute(
            "INSERT INTO processed_events (event_id) VALUES (%s) "
            "ON CONFLICT (event_id) DO NOTHING",
            [event["event_id"]],
        ).rowcount
        if inserted == 0:
            return                               # seen before: do nothing
        db.execute(
            "UPDATE orders SET status = 'PAID' WHERE order_id = %s "
            "AND status = 'AWAITING_PAYMENT'",
            [event["order_id"]],
        )
    # commit the broker offset only after the transaction has committed

Schémas d’événements et versionnage

Dès que d’autres équipes consomment un événement, sa structure est un contrat publié, exactement comme une API, et elle dure plus longtemps : avec un courtier fondé sur un journal, les consommateurs peuvent lire des événements écrits il y a des mois. Un bon événement comporte un identifiant unique, un type, une version de schéma, l’heure à laquelle il s’est produit, les identifiants des entités concernées et les données métier dont les consommateurs ont besoin. Les montants sont stockés en unités mineures avec une devise, jamais sous forme de nombre à virgule flottante (chapitre 0).

{
  "event_id": "9f1c2e7a-4b0d-4e55-9a51-0c3d8f2b6a10",
  "type": "OrderPlaced",
  "schema_version": 2,
  "occurred_at": "2026-10-22T18:42:07Z",
  "order_id": "ord-4711",
  "customer_id": "cus-208",
  "restaurant_id": "res-31",
  "items": [{"dish_id": "d-5", "qty": 2, "price_minor": 1150}],
  "total_minor": 2450,
  "currency": "GBP"
}

Les schémas doivent évoluer de façon rétrocompatible : ajouter des champs optionnels, ne jamais supprimer ni renommer des champs ni changer leur signification sans nouvelle version, et ne jamais réutiliser un nom de champ pour autre chose. De nombreuses équipes l’imposent avec un format de schéma comme Avro, Protocol Buffers ou JSON Schema et un registre de schémas qui rejette les changements incompatibles au moment de la publication. La spécification CloudEvents, projet de niveau « graduated » de la Cloud Native Computing Foundation, normalise les attributs d’enveloppe courants comme id, source, type et time. Les modes de compatibilité et les techniques de migration sont traités dans évolution des schémas.

Gestion des erreurs : nouvelles tentatives, messages empoisonnés et files de lettres mortes

Les consommateurs échouent pour deux raisons très différentes, qui demandent des traitements différents. Les défaillances transitoires, comme une base de données brièvement indisponible ou un délai d’expiration lors de l’appel d’un autre service, réussissent généralement après une nouvelle tentative ; réessayez quelques fois avec un backoff exponentiel et du jitter (des délais croissants et aléatoires) afin de ne pas submerger une dépendance en difficulté. Les défaillances permanentes, comme un événement mal formé ou qui viole une règle métier, échoueront à chaque fois. Un tel « message empoisonné » (poison message) ne doit pas bloquer le consommateur indéfiniment, ce qui, sur un journal partitionné, bloquerait tous les événements suivants de cette partition.

La réponse standard est une file de lettres mortes (dead-letter queue, DLQ) : après un nombre défini de tentatives, le message est déplacé vers un canal distinct, avec l’erreur enregistrée, et le consommateur passe à la suite. Une DLQ n’est utile que si quelqu’un la surveille : déclenchez des alertes sur sa taille, confiez-en la responsabilité à une équipe nommément désignée, fournissez des outils pour inspecter, corriger et rejouer les messages, et décidez à l’avance quelles garanties d’ordre sont perdues lorsqu’un message est rejoué tardivement. Certaines équipes ajoutent un ou plusieurs topics intermédiaires de nouvelle tentative, avec des délais plus longs, avant la DLQ.

Quand l’utiliser, et erreurs courantes

L’architecture pilotée par les événements convient quand de nombreuses parties d’une activité doivent réagir aux mêmes faits, quand le travail peut se faire après le retour de la requête de l’utilisateur, quand la charge arrive par à-coups et doit être lissée, et quand de nouveaux consommateurs sont attendus au fil du temps. Elle convient moins bien quand un utilisateur a besoin d’une réponse immédiate et définitive qui dépend de plusieurs services (même si un appel synchrone pour la réponse, complété par des événements pour la suite, est un hybride courant), ou quand une forte cohérence entre services est requise.