L’architecture événementielle (EDA, pour event-driven architecture) est une manière de concevoir des logiciels dans laquelle les composants d’un système communiquent en annonçant que quelque chose s’est produit, au lieu de s’appeler directement. Un composant publie un événement, par exemple “facture payée” ou “contrat signé”. Tout autre composant concerné y réagit. Aucun des deux côtés n’a besoin de savoir que l’autre existe.

Pour une entreprise SaaS, l’enjeu dépasse largement l’ingénierie. La même idée sous-tend des passages de relais propres entre CRM et finance, une automatisation fiable et des agents IA qui agissent sur des données à jour. Ce guide explique le fonctionnement de l’EDA, la différence entre un bus d’événements et une file d’attente, comment éviter les défaillances courantes, et où elle a sa place ou non.

En bref

Sommaire

Ce qu’est l’architecture événementielle

Les recommandations d’architecture de Microsoft décrivent ce style comme des producteurs d’événements qui génèrent un flux d’événements, des consommateurs d’événements qui les écoutent, et des canaux d’événements qui acheminent les événements des uns aux autres. Ce modèle en trois parties résume toute l’idée. Le reste n’est que détail sur la fiabilité et la rapidité du canal.

Le contraste se fait avec le modèle requête/réponse. Dans une conception requête/réponse, votre service de facturation appelle votre CRM et attend une réponse. Si le CRM est lent ou indisponible, la facturation reste bloquée. Dans une conception événementielle, la facturation publie “paiement reçu” et poursuit son travail. Le CRM, le rapport de revenus et le tableau de bord du customer success récupèrent chacun l’événement quand ils sont prêts.

Deux propriétés en découlent :

Ce qui constitue un événement

Un événement est un énoncé de fait, au passé. Red Hat le décrit comme un enregistrement immuable que quelque chose s’est produit, souvent horodaté, ce qui préserve l’ordre par rapport au système qui l’a produit. On ne modifie pas un événement après coup. Si quelque chose change, un nouvel événement consigne le changement.

AWS souligne que les événements peuvent être un changement d’état ou une mise à jour, et qu’ils peuvent soit porter l’état, soit n’être que des identifiants. Deux exemples :

Style Exemple Ce que reçoit le consommateur
Événement porteur d’état Abonnement mis à niveau, avec offre, prix, date d’effet, identifiant du compte Tout ce qu’il faut pour agir sans seconde consultation
Événement sous forme d’identifiant Commande expédiée, avec uniquement l’identifiant de commande Un signal. Le consommateur récupère les détails auprès du système source

Le premier est pratique, mais il lie les consommateurs à la forme de l’événement. Le second garde des événements légers, mais renvoie les consommateurs vers le système source, ce qui soulève la question de savoir quel système fait autorité. Nous y revenons plus bas, car c’est là que la plupart des environnements d’opérations SaaS rencontrent des difficultés.

Une commande n’est pas un événement. “Envoyer la facture” est une instruction adressée à un destinataire précis. “Facture envoyée” est un fait auquel chacun peut réagir. Mélanger les deux est une erreur de conception courante, et reconstitue discrètement le couplage étroit que vous cherchiez à supprimer.

Comment fonctionne un système événementiel, étape par étape

La documentation de Google Cloud décrit le flux : les producteurs génèrent des événements, un routeur ou un broker les reçoit et les filtre, puis les distribue aux consommateurs selon des abonnements ou des déclencheurs. Concrètement :

  1. Quelque chose se produit. Un deal passe à « Closed Won » dans le CRM.
  2. Le producteur publie un événement. Il énonce le fait et l’enregistrement concerné.
  3. Le broker l’achemine. Il filtre l’événement et le livre à chaque abonné.
  4. Les consommateurs réagissent de façon indépendante. La Finance crée un brouillon de facture. Le Customer Success ouvre un plan d’onboarding. Un processus de provisionnement prépare les accès.
  5. Chaque consommateur accuse réception. Le broker sait que l’événement a été traité et peut réessayer s’il ne l’a pas été.

IBM présente le même modèle comme la publication, la capture, le traitement et le stockage d’événements, et souligne que la valeur d’un événement peut évoluer dans le temps. Un événement « nouveau lead » mérite qu’on agisse en quelques minutes. Un an plus tard, il sert surtout à l’analyse.

Architecture événementielle et microservices

On confond souvent ces deux notions. Elles ne sont pas identiques. Les microservices décrivent la manière de découper une application en petits services déployés indépendamment. L’EDA décrit la manière dont ces services communiquent. Vous pouvez avoir des microservices qui s’appellent de façon synchrone, et un monolithe qui publie des événements en interne.

Les deux fonctionnent bien ensemble. Les recommandations de Google indiquent que les microservices peuvent réagir de façon asynchrone aux événements et n’ont besoin de connaître que le format de l’événement, pas la logique métier des autres. Ce format partagé est le contrat. Tout ce qui se trouve derrière peut changer.

La documentation de Microsoft décrit le modèle typique comme des microservices qui publient un événement lorsqu’un fait notable se produit, d’autres microservices s’y abonnant.

Bus d’événements, file d’attente et flux

Ces trois termes prêtent le plus à confusion, et votre choix change le comportement de votre système.

Bus d’événements (publication/abonnement). Un bus d’événements est un mécanisme dans lequel des éditeurs annoncent des événements et des abonnés les reçoivent. Microsoft explique qu’il peut être mis en œuvre sur une infrastructure de messagerie, comme une file d’attente ou un service bus prenant en charge la publication/abonnement asynchrone. Une file d’attente peut donc être l’un des composants d’un bus. Le bus est l’intention. La file d’attente est une manière de la concrétiser.

File d’attente. Une file d’attente conserve les messages jusqu’à ce qu’un worker les prenne en charge. Chaque message est normalement traité par un seul consommateur. Les files d’attente conviennent pour répartir le travail entre plusieurs workers et absorber les pics de charge. Les recommandations d’intégration d’Azure citent la mise en file d’attente des messages lorsqu’un back end est indisponible comme l’une des raisons d’utiliser un broker.

Flux d’événements. Azure distingue la publication/abonnement du streaming. Avec la publication/abonnement, une fois reçu, un événement n’est pas conservé dans un journal durable, de sorte que les nouveaux abonnés ne voient pas les événements passés. Avec le streaming, les événements sont écrits dans un journal durable et strictement ordonné au sein d’une partition, et les clients lisent le journal, peuvent le rejoindre à tout moment et rejouer les événements.

File d’attente Bus de publication/abonnement Flux d’événements
Livraison Un consommateur par message Chaque abonné Tout lecteur, à partir de n’importe quel point
Événements passés Supprimés après traitement Non disponibles pour les nouveaux abonnés Conservés et rejouables
Usage typique Répartition du travail, mise en tampon Notification de plusieurs systèmes Historique, analyse, reconstruction d’état

Une règle pratique : si plusieurs systèmes doivent réagir au même fait, utilisez la publication/abonnement. Si un seul worker doit exécuter une tâche, utilisez une file d’attente. Si vous avez besoin d’historique ou de la capacité à reconstruire un système en aval, utilisez un flux. Red Hat ajoute qu’il n’existe pas de solution universelle, il faut donc choisir la technologie selon le type d’événement.

Kafka est-il une architecture événementielle ?

Non. Kafka est une technologie qui permet d’en construire une. La documentation d’Apache Kafka la décrit comme une plateforme de streaming d’événements : capturer des événements en temps réel, les stocker durablement, les traiter et les acheminer vers d’autres systèmes. C’est donc un flux d’événements, au sens du tableau ci-dessus.

Une architecture est un ensemble de décisions de conception : quels sont les événements, à qui ils appartiennent, comment les consommateurs sont isolés, ce qui se passe en cas de défaillance. Vous pouvez prendre ces décisions et les exécuter sur un bus cloud managé, un service de files d’attente ou Kafka. Vous pouvez aussi exécuter Kafka et conserver un système fortement couplé si chaque service dépend des événements internes d’un autre service. Choisissez l’outil une fois que vous avez défini les événements et le volume que vous attendez réellement.

Intégration et automatisation événementielles

C’est là que l’EDA devient pertinente pour les responsables opérationnels, et pas seulement pour les ingénieurs.

Intégration

La plupart des entreprises SaaS connectent leurs données CRM, de facturation, de support et produit par des synchronisations point à point. Chaque nouvel outil ajoute une connexion de plus à maintenir. Azure recommande une communication asynchrone via un broker de messages plutôt que des appels synchrones directs, pour quatre raisons qu’il énumère : découpler les applications, diffuser à plusieurs consommateurs, suivre de manière fiable les workflows de longue durée et mettre les messages en file d’attente lorsqu’un back end est indisponible.

L’avantage apparaît lorsque vous ajoutez un système. Avec un service de publication/abonnement, de nouveaux abonnés peuvent être ajoutés sans modifier l’émetteur. Ajouter un nouvel outil d’analyse n’exige aucune modification de votre CRM.

Automatisation

L’automatisation pilotée par les événements signifie qu’un processus métier démarre parce que quelque chose s’est produit, et non parce que quelqu’un a cliqué sur un bouton ou qu’un traitement nocturne s’est exécuté. Le guide des flux de ServiceNow propose une méthode pratique : identifier le déclencheur, planifier la logique, sélectionner les actions et identifier la logique réutilisable. Il recommande aussi de garder des flux ciblés et d’utiliser un verbe par action.

Lorsqu’un processus s’étend sur plusieurs services, Microsoft note que les systèmes pilotés par les événements utilisent couramment des modèles de chorégraphie et d’orchestration de sagas pour coordonner le flux. Dans la chorégraphie, chaque service réagit aux événements et émet les siens. Dans l’orchestration, un coordinateur indique à chaque étape ce qu’elle doit faire et suit l’ensemble du processus. Pour un premier projet, un flux orchestré est généralement plus facile à lire et à auditer.

Un exemple SaaS simple :

Bonnes pratiques et défis courants

Azure énumère les principaux défis : cohérence à terme, gestion asynchrone des erreurs, perte de données, observabilité et tests, événements trop nombreux ou trop consolidés, et évolution des schémas. Chacun a sa bonne pratique correspondante.

  1. Prévoyez la cohérence à terme. Les systèmes seront brièvement en désaccord. Décidez quel système fait autorité pour chaque donnée et laissez les autres le suivre.
  2. Ajoutez un gestionnaire d’erreurs dédié. Les événements en échec ont besoin d’un endroit où aller et de quelqu’un pour les examiner.
  3. Conservez les événements jusqu’à ce que leur réception soit confirmée. Cela protège contre la perte de données lorsqu’un consommateur est hors service.
  4. Utilisez des identifiants de corrélation. Un identifiant unique transmis à chaque étape permet de suivre une action client donnée à travers les systèmes.
  5. Trouvez le bon niveau de granularité des événements. Un événement par modification de champ crée du bruit. Un seul événement géant pour tout recrée du couplage.
  6. Versionnez les schémas dès le début. Les formats d’événements vont changer. Décidez comment avant d’avoir vingt consommateurs.

À cela, nous ajouterions trois habitudes opérationnelles : nommer les événements au passé, attribuer un seul responsable à chaque type d’événement, et consigner par écrit quels consommateurs en dépendent.

Là où la conception événementielle n’a pas sa place

L’EDA n’est pas la réponse à tous les problèmes. Soyez explicite sur ses limites avant de vous engager :

La même logique s’applique à l’IA. Un assistant IA qui lit vos systèmes et agit dessus est à la fois consommateur et producteur d’événements. S’il lit des données incohérentes ou agit sans limite de permissions, vous avez un moyen plus rapide de produire des erreurs.

Où l’on rejoint les agents IA et la conformité

Les agents IA qui récupèrent des données (interroger, produire un rapport, rechercher) et en envoient (mettre à jour un enregistrement, déclencher un processus, attribuer des accès) se comportent comme des participants d’un système événementiel. Ils ont besoin d’une source fiable à lire, d’un ensemble clair d’actions autorisées, d’une approbation pour les étapes sensibles et d’une trace de ce qu’ils ont fait. Un journal d’événements est un endroit naturel pour cette trace.

Opérateur examinant le journal d’événements d’un agent IA

Pour les entreprises européennes, le GDPR, la NIS2 et l’EU AI Act influencent tous la conception de tels systèmes. De manière générale, ils portent sur les données personnelles qui circulent dans les événements, sur l’organisation de la sécurité et de la gestion des incidents, ainsi que sur la gouvernance et la documentation des systèmes d’IA. Traitez-les comme des données d’entrée de la conception dès le départ, et demandez conseil à un juriste sur leur application à votre cas précis. Aucun choix d’architecture ne rend à lui seul un système conforme.

Notre point de vue

La plupart des entreprises SaaS que nous rencontrons n’ont pas un problème d’événements. Elles ont un problème de responsabilité. Plusieurs équipes utilisent l’IA, plusieurs outils détiennent une version du client, et personne n’est responsable de déterminer quelle version est la bonne.

C’est pourquoi nous travaillons dans un ordre précis. D’abord la fondation de données : les données CRM et financières comme source de vérité convenue. Ensuite la couche IA, qui connecte ces données à l’assistant que votre équipe utilise déjà. Puis les agents départementaux pour la Finance, les Ventes et le Customer Success. Les événements sont utiles dans ces trois couches, mais ils n’aident que lorsque les faits qu’ils transportent sont validés.

Nous adoptons aussi un processus à la fois, en commençant par le plus coûteux. Un processus de renouvellement ou un passage de relais de la facture à l’encaissement constitue un meilleur premier projet événementiel qu’une refonte à l’échelle de l’entreprise. Vous voyez le résultat, vos équipes apprennent le schéma, et le processus suivant coûte moins cher.

Comme nous assurons l’exploitation en plus de concevoir les systèmes, nous nous soucions des aspects peu glamour : permissions, approbations, pistes d’audit et une remise où vous êtes propriétaire du code, de la documentation et de l’infrastructure.

Claus Nielsen

Démarrer dans votre propre entreprise

Vous n’avez pas besoin de choisir un broker en premier. Commencez par ces questions :

  1. Quel processus vous coûte le plus en travail manuel, en retards ou en erreurs ?
  2. Quels sont les deux ou trois événements qui le déclenchent (par exemple : affaire conclue, facture en retard, renouvellement proche) ?
  3. Quel système est la source de vérité pour les données de ces événements ?
  4. Qui est responsable de chaque définition d’événement ?
  5. Quelles étapes nécessitent une approbation humaine ?

Si vous ne pouvez pas répondre à la troisième question, la fondation de données passe en premier. Si vous le pouvez, un petit pilote sur un processus vous montrera si une approche événementielle est rentable.

Comment nous pouvons vous aider

Si votre équipe utilise l’IA mais que personne n’en est responsable, nous pouvons vous aider à décider où elle est rentable et à la construire dans le bon ordre. Notre AI Readiness Assessment est disponible à partir de €4,500 et examine vos données, vos systèmes et vos processus avant toute réalisation. Si vous souhaitez un pilotage dans la durée, le contrat de Chief AI Officer à temps partiel démarre à partir de €1,500 par mois.

Les réalisations sont facturées à 30% d’une économie de première année mesurée et prouvée, ou à un prix fixe convenu avant le début des travaux. Vous pouvez aussi réserver un appel de découverte gratuit de 30 minutes via notre site. Nos agents IA pour la Finance, les Ventes et le Customer Success montrent à quoi ressemble la couche départementale une fois la fondation en place.

FAQ

Qu’est-ce que l’architecture événementielle, en termes simples ?

C’est une conception dans laquelle des composants logiciels annoncent que quelque chose s’est produit, et d’autres composants réagissent. L’émetteur ne sait pas qui écoute. Cela permet d’ajouter ou de modifier des systèmes sans réécrire ceux qui produisent les événements.

Quelle est la différence entre un bus d’événements et une file de messages ?

Une file remet généralement chaque message à un seul worker. Un bus d’événements remet chaque événement à tous les abonnés. Un bus peut être construit sur une infrastructure de files, de sorte que la différence tient à l’intention et au mode de distribution, pas toujours au produit.

L’architecture événementielle est-elle la même chose que les microservices ?

Non. Les microservices concernent la manière dont une application est découpée en services. L’architecture événementielle concerne la manière dont les parties communiquent. Elles sont souvent utilisées ensemble, mais chacune peut exister sans l’autre.

Quand une entreprise SaaS doit-elle recourir à l'automatisation pilotée par les événements ?

Recourez-y lorsqu'un processus métier doit démarrer à partir d'un fait, comme un contrat signé ou un renouvellement qui approche, et que plusieurs équipes ou systèmes doivent réagir. Commencez par un seul processus coûteux et assurez-vous d'abord que les données sources font l'objet d'un accord.

Sources