Passer à une architecture orientée événements se justifie lorsque plusieurs systèmes doivent réagir au même fait métier, lorsque les chaînes d'appels synchrones rendent le SI fragile, ou lorsque l'on a besoin d'un historique des changements que l'on peut rejouer. Elle ne se justifie pas pour un échange simple entre deux applications qui attendent une réponse immédiate : un appel d'API reste alors plus lisible.
Le « comment » est aussi important que le « quand ». Une architecture orientée événements réussie ne commence pas par l'installation d'un broker, mais par la définition d'événements métier clairs, de contrats versionnés et de règles de cohérence explicites. La migration se fait domaine par domaine, en faisant coexister l'existant et le nouveau.
Cet article propose une grille de lecture pour décider, puis une méthode pour avancer sans créer un nouveau plat de spaghettis, asynchrone cette fois.
Ce que recouvre vraiment une architecture orientée événements
Le terme « événementiel » recouvre des réalités très différentes, ce qui alimente nombre de malentendus entre équipes. Martin Fowler en a proposé dès 2017 une clarification utile, en distinguant quatre patterns souvent confondus 1.
- Notification d'événement : la source signale qu'un fait s'est produit et ne se soucie pas de la réponse. Le couplage est faible, mais un processus réparti sur plusieurs notifications devient difficile à suivre 1.
- Transfert d'état porté par l'événement : l'événement contient les données modifiées, ce qui permet aux destinataires de tenir une copie locale et de fonctionner même si la source est indisponible, au prix de données dupliquées 1.
- Event sourcing : chaque changement d'état est enregistré comme un événement et l'état courant est dérivé de ce journal, ce qui offre une piste d'audit complète mais complique l'évolution des schémas 1.
- CQRS : séparation des modèles d'écriture et de lecture, souvent combinée aux patterns précédents, dont le gain doit être mis en balance avec la complexité ajoutée 1.
Dans la plupart des SI d'entreprise, les deux premiers patterns couvrent l'essentiel des besoins. L'event sourcing et le CQRS sont des choix d'architecture applicative lourds, à réserver aux domaines où l'historique fait partie du métier, comme certains registres financiers.
Quand passer à l'architecture orientée événements : signaux favorables et contre-indications
Les signaux favorables
- Un même fait métier, par exemple une commande validée, doit déclencher des actions dans quatre ou cinq applications, et chaque nouvel abonné impose aujourd'hui une modification de la source.
- Une panne d'un service secondaire bloque un parcours critique parce que tout est enchaîné en appels synchrones.
- Les équipes ont besoin de connaître l'historique des changements, pas seulement l'état courant.
- Des pics de charge ponctuels saturent des systèmes qui pourraient absorber le travail en différé.
- Les données doivent alimenter des usages analytiques ou d'IA avec une fraîcheur de l'ordre de la seconde ou de la minute.
Les contre-indications
L'événementiel est mal adapté quand l'utilisateur attend une réponse immédiate et cohérente, par exemple la confirmation d'un solde, ou quand une transaction doit être atomique sur plusieurs systèmes. Il l'est aussi lorsque l'organisation ne dispose pas des compétences pour exploiter un broker, tracer des flux asynchrones et diagnostiquer des incohérences temporaires. Dans ces cas, mieux vaut commencer par un périmètre restreint.
Il faut enfin mesurer l'impact organisationnel. Dans un modèle événementiel, l'équipe émettrice ne connaît plus forcément tous ses consommateurs : elle s'engage sur un contrat, pas sur une intégration. Cela suppose une gouvernance transverse, un catalogue partagé et une capacité à arbitrer les évolutions de schéma entre équipes. Sans ce cadre, le découplage technique se paie d'un couplage implicite bien plus difficile à détecter, révélé seulement lors de la première modification d'un champ.
Un événement décrit un fait qui s'est produit ; une commande exprime une intention. Les confondre est la première source de couplage caché.
Concevoir les événements : contrats, métadonnées et documentation
Un événement est un contrat public. Il doit être nommé au passé (CommandeValidée plutôt que ValiderCommande), décrire un fait métier compréhensible hors de l'application émettrice et ne pas exposer la structure interne des tables. Son schéma doit être versionné, avec une règle de compatibilité explicite : ajout de champs optionnels autorisé, suppression ou renommage interdits sans nouvelle version.
Deux standards ouverts aident à industrialiser cette discipline. CloudEvents, projet diplômé de la CNCF depuis janvier 2024, normalise les métadonnées communes d'un événement pour faciliter l'interopérabilité entre services et plateformes 2. AsyncAPI, dans sa version 3.0, décrit dans un format lisible par machine les canaux, les opérations d'envoi et de réception et les messages d'une API asynchrone, quel que soit le protocole, Kafka compris 3.
- Adopter une enveloppe commune (identifiant, source, type, horodatage) inspirée de CloudEvents 2.
- Documenter chaque flux dans un fichier AsyncAPI versionné avec le code 3.
- Désigner un propriétaire par événement, responsable de son schéma et de ses évolutions.
- Publier un catalogue des événements consultable par toutes les équipes.
Garanties de livraison et cohérence à terme
Le passage à l'asynchrone impose d'accepter que les systèmes ne soient pas tous à jour au même instant. Il faut aussi comprendre les garanties réelles du broker. Par défaut, Kafka offre une livraison « au moins une fois » : un message n'est pas perdu mais peut être reçu plusieurs fois 4. Le producteur idempotent évite les doublons à l'écriture et les transactions permettent un traitement « exactement une fois », mais ces garanties s'appliquent surtout aux traitements de Kafka vers Kafka ; dès qu'un système externe intervient, la coordination redevient difficile 4.
En pratique, trois règles de conception s'imposent. Les consommateurs doivent être idempotents, par exemple en mémorisant les identifiants d'événements déjà traités. L'ordre n'est garanti qu'au sein d'une partition : tous les événements d'une même entité doivent donc porter la même clé. Enfin, la publication d'un événement et la mise à jour de la base de l'émetteur doivent être cohérentes, ce que résout le pattern outbox transactionnel 5, que nous détaillons dans l'article consacré au Change Data Capture.
Pour les processus métier qui traversent plusieurs services, les transactions distribuées sont remplacées par des sagas : une suite d'étapes locales, chacune publiant un événement, avec des actions de compensation en cas d'échec. Le processus doit être modélisé explicitement, faute de quoi il devient invisible, ce que Fowler signale comme le principal risque de la notification d'événement 1.
Flux d'événements ou file de travail : choisir le bon modèle
Toutes les communications asynchrones ne sont pas des événements. Une file de travail distribue des tâches à des exécutants : chaque tâche doit être traitée une fois, par un seul d'entre eux. Un flux d'événements, lui, est un journal que plusieurs consommateurs lisent indépendamment, chacun à son rythme, avec la possibilité de rejouer l'historique.
Kafka couvrait historiquement le second modèle. Depuis Kafka 4.2, les share groups permettent aussi une consommation de type file, avec acquittement enregistrement par enregistrement et sans affectation fixe des partitions aux consommateurs 6. Cela permet d'unifier l'infrastructure, mais ne dispense pas de nommer clairement chaque usage : un topic d'événements métier et une file de tâches techniques n'ont ni le même contrat, ni la même rétention, ni les mêmes consommateurs.
Une trajectoire de migration en six étapes
Une bascule globale vers l'événementiel est rarement soutenable. La trajectoire suivante permet d'apprendre sur un périmètre limité et de faire coexister l'ancien et le nouveau.
- Cartographier un domaine métier et ses événements clés lors d'ateliers réunissant métier et architectes.
- Choisir un premier flux à forte valeur et faible risque, avec plusieurs consommateurs identifiés.
- Publier les événements depuis le système source, via outbox ou capture de changements, sans modifier les consommateurs existants.
- Brancher les nouveaux consommateurs sur le flux, puis migrer progressivement les intégrations point à point.
- Mettre en place l'observabilité de bout en bout : identifiant de corrélation, retard des consommateurs, files d'erreurs.
- Formaliser la gouvernance (catalogue, propriétaires, règles de compatibilité) avant d'étendre à d'autres domaines.
Conclusion
Une architecture orientée événements apporte découplage, résilience et réactivité, à condition de la traiter comme une discipline de conception plutôt que comme un choix d'outil. Les décisions déterminantes portent sur la nature des événements, leurs contrats, la cohérence acceptable et la gouvernance. DATASWING accompagne les équipes d'architecture SI dans ce cadrage et dans la mise en œuvre progressive des premiers domaines.
— Questions fréquentes
Ce qu'on nous demande souvent
Quelle différence entre architecture orientée événements et microservices ?+
Les microservices désignent un découpage applicatif en services autonomes ; l'architecture orientée événements désigne un mode de communication où les systèmes publient et consomment des faits métier de façon asynchrone. On peut avoir des microservices qui communiquent uniquement par API synchrones, et inversement des applications monolithiques qui publient des événements. Les deux approches se combinent souvent mais restent indépendantes.
Kafka garantit-il qu'un message n'est traité qu'une seule fois ?+
Pas par défaut. Kafka assure une livraison au moins une fois, ce qui peut produire des doublons. Le producteur idempotent et les transactions permettent un traitement exactement une fois, mais surtout pour les traitements internes à Kafka. Dès qu'une base ou une API externe intervient, il faut concevoir des consommateurs idempotents, par exemple en mémorisant les identifiants d'événements déjà traités.
Comment documenter des API événementielles ?+
La spécification AsyncAPI, aujourd'hui en version 3.0, permet de décrire de façon lisible par machine les canaux, les opérations et les messages d'une API asynchrone, quel que soit le protocole. Elle se combine avec CloudEvents pour les métadonnées communes et avec un registre de schémas pour versionner le contenu des événements et contrôler leur compatibilité.
Faut-il faire de l'event sourcing pour passer à l'événementiel ?+
Non. L'event sourcing, qui consiste à dériver l'état d'une application de son journal d'événements, est un choix applicatif exigeant. La plupart des SI tirent l'essentiel de la valeur de la notification d'événements et du transfert d'état porté par l'événement, plus simples à adopter. L'event sourcing se réserve aux domaines où l'historique fait partie du métier.
— Sources
Références citées
Les textes réglementaires et documentations évoluent : vérifiez la version en vigueur avant toute décision. Cet article n'est pas un avis juridique.
-
[1]
What do you mean by “Event-Driven”? ↗Martin Fowler (martinfowler.com) · 2017-02
-
[2]
Cloud Native Computing Foundation Announces the Graduation of CloudEvents ↗Cloud Native Computing Foundation · 2024-01
-
[3]
AsyncAPI Specification 3.0.0 ↗AsyncAPI Initiative · 2023-12
-
[4]
Kafka Message Delivery Guarantees ↗Confluent Documentation · 2026
-
[5]
Pattern: Transactional outbox ↗microservices.io (Chris Richardson) · 2026
-
[6]
Apache Kafka 4.2.0 Release Announcement ↗Apache Software Foundation · 2026-02
