Architecture événementielle

L'architecture événementielle est une façon de construire un logiciel où les parties d'un système ne se donnent pas d'ordres. Chaque partie annonce plutôt ce qui vient de se produire, « commande payée », « stock modifié », « client inscrit », et toute autre partie concernée réagit d'elle-même. Cette annonce s'appelle un événement.

Vous êtes concerné quand votre activité repose sur plusieurs outils ou services qui doivent rester synchronisés : une boutique en ligne, un outil d'emailing, un entrepôt, un logiciel de comptabilité. Le sujet revient aussi quand une agence vous propose un système sur mesure ou quand vous comparez des plateformes. Comprendre l'idée permet de savoir pourquoi certaines choses sont instantanées, pourquoi d'autres prennent quelques secondes, et pourquoi un email raté ne doit jamais annuler une commande payée.

Qu'est-ce que l'architecture événementielle ?

L'architecture événementielle (on dit aussi event-driven architecture) est un style de conception dans lequel les composants communiquent en produisant et en consommant des événements. Un événement est la trace d'un fait déjà survenu, formulé au passé, accompagné des détails utiles : quelle commande, quel montant, à quelle heure.

Le vocabulaire tient en quelques mots :

• Producteur : la partie qui constate un fait et publie l'événement. Le checkout publie « commande payée ».
• Consommateur : une partie qui écoute certains événements et réagit. Le service d'emails envoie un reçu, le service de stock décrémente les quantités.
• Broker, ou bus d'événements : le canal qui reçoit les événements et les distribue aux consommateurs. Il les conserve souvent jusqu'à ce que chacun les ait traités.
• Abonnement : la déclaration d'un consommateur qui veut recevoir un type d'événement donné.

La grande différence avec le style classique par requêtes, c'est qui connaît qui. Dans un système par requêtes, le checkout appelle le service d'emails, puis le service de stock, puis la comptabilité, et attend chaque réponse. Dans un système événementiel, le checkout publie un seul événement et passe à la suite. Il ne sait pas, et n'a pas besoin de savoir, combien de parties vont réagir.

Quelques termes voisins. Un webhook est un événement envoyé par le système d'une entreprise à celui d'une autre via le web, une manière courante de faire franchir aux événements la frontière entre deux sociétés. Une requête d'API relève du style opposé, une question directe qui attend une réponse. L'event sourcing est un modèle plus strict où l'historique complet des événements fait foi. L'architecture événementielle va souvent de pair avec les microservices, mais une application unique peut aussi s'en servir en interne.

Pourquoi c'est important

Les événements séparent le moment où le client agit du travail qui suit. Cela protège le chiffre d'affaires pendant les pics et rend l'ajout de nouvelles réactions peu coûteux.

Prenons une créatrice qui vend une formation en ligne à 79 €. Au lancement, 900 personnes achètent dans la première heure. Dans un système par requêtes, chaque paiement déclenche à la suite l'ouverture de l'accès, l'email de reçu, la facture PDF, la mise à jour du CRM et une notification Slack. Si le générateur de factures monte à 8 secondes par appel sous la charge, chaque acheteur patiente au checkout. Si le CRM tombe 10 minutes et que le code n'a pas été écrit avec soin, ces paiements échouent. Perdre seulement 5 % des commandes de l'heure, c'est 45 ventes, soit 3 555 €.

Dans un système événementiel, le checkout confirme le paiement et publie « commande payée ». L'acheteur voit la confirmation tout de suite. L'accès, l'email, la facture et le CRM consomment chacun l'événement à leur rythme. Un CRM en panne signifie des mises à jour avec 10 minutes de retard, pas des ventes perdues.

Le second bénéfice apparaît quelques mois plus tard. Quand la créatrice veut verser une commission à ses affiliés sur chaque vente, le développeur ajoute un nouveau consommateur. Le code du checkout n'est pas touché, donc aucun risque de casser les paiements en pleine promotion.

Comment ça marche

Un parcours type, du clic du client jusqu'à toutes les réactions, se déroule ainsi :

• Un fait se produit. Un client finalise son paiement. Le checkout enregistre la commande dans sa propre base.
• Un événement est publié. Le checkout envoie « commande payée » au broker, avec le numéro de commande, les articles, le montant et le client.
• Le broker stocke et distribue. Il conserve l'événement en sécurité et en remet une copie à chaque consommateur abonné.
• Les consommateurs réagissent chacun de leur côté. Le stock baisse, le reçu part, la préparation reçoit une tâche d'emballage, les statistiques comptent la vente. Chacun travaille à son rythme.
• Les consommateurs confirment. Chacun signale qu'il a traité l'événement. Si l'un plante, le broker le lui renvoie plus tard.
• Les consommateurs peuvent publier à leur tour. La préparation publie « commande expédiée », ce qui déclenche l'email de suivi et met à jour le suivi de commande.

Comme un événement peut être livré plusieurs fois, les consommateurs doivent être idempotents : traiter deux fois le même « commande payée » ne doit ni envoyer deux reçus ni décrémenter deux fois le stock. C'est là que se concentre une bonne partie du vrai travail d'ingénierie.

Repères et exemples

Les systèmes événementiels existent à des échelles très différentes.

• Une petite boutique vit déjà entourée d'événements, souvent sans les voir. Le prestataire de paiement prévient la boutique qu'un paiement a réussi, le transporteur qu'un colis a bougé. La boutique réagit.
• Une marque en croissance, entre 2 000 et 10 000 commandes par mois, relie souvent sa boutique à la comptabilité, à un entrepôt et à l'emailing par des événements ou des webhooks plutôt que par des exports nocturnes.
• Un SaaS ou une marketplace avec de nombreuses équipes indépendantes fait généralement tourner un broker central avec des dizaines de types d'événements.

Quelques repères utiles. Un broker bien exploité livre les événements en bien moins d'une seconde en temps normal. Des consommateurs qui accusent quelques minutes de retard pendant un pic, c'est acceptable pour les emails et les statistiques, pas pour le stock. La plupart des équipes gardent la réservation du stock dans la requête du checkout, de façon synchrone, et réservent les événements à tout ce qui peut attendre quelques secondes. Pour un développement sur mesure, ajouter un broker managé et bien concevoir les événements représente de quelques jours à quelques semaines de travail, selon le nombre de flux concernés.

Erreurs fréquentes

• Utiliser des événements pour ce qui exige une réponse immédiate. « Cet article est-il en stock ? » doit être tranché avant le paiement. C'est une question, pas un événement.
• Ignorer les doublons. Les brokers garantissent en général au moins une livraison, pas exactement une. Sans consommateurs idempotents, les clients reçoivent des emails en double ou le stock dérive.
• Aucune visibilité. Quand dix consommateurs réagissent au même événement, un reçu manquant est difficile à retrouver sans journaux qui suivent chaque événement de bout en bout.
• Des événements flous. Un événement « commande modifiée » sans détail oblige chaque consommateur à interroger la base pour savoir ce qui a changé, ce qui recrée le couplage qu'on voulait supprimer.
• L'adopter trop tôt. Une application unique avec trois réactions à une vente a rarement besoin d'un broker. Un code simple au même endroit est plus facile à exploiter.

Bonnes pratiques

• Nommez les événements comme des faits passés. « Commande payée », « remboursement effectué », « stock épuisé ». Des noms clairs rendent le système lisible même pour les non-développeurs.
• Mettez l'essentiel dans l'événement. Incluez les identifiants et les valeurs dont les consommateurs ont besoin, pour que la plupart n'aient jamais à rappeler.
• Rendez chaque consommateur idempotent. Gardez la liste des événements déjà traités et ignorez les répétitions.
• Gardez les contrôles critiques synchrones. L'autorisation de paiement et la réservation du stock restent dans le parcours principal. Les événements gèrent la suite.
• Prévoyez les échecs. Configurez des nouvelles tentatives espacées et un endroit où garer les événements qui échouent en boucle, souvent appelé file de lettres mortes (dead-letter queue).
• Tracez chaque événement. Donnez un identifiant à chaque événement et journalisez-le à chaque étape, pour répondre en quelques minutes à « pourquoi ce client n'a pas reçu d'email ».

Dans Roctify

Roctify gère pour vous la chaîne de réactions qui suit une vente. Quand un client paie par Stripe ou PayPal, ou choisit le paiement à la livraison, la commande est enregistrée, le stock se met à jour sur tous les canaux à la fois grâce au catalogue partagé, et les produits digitaux, formations et téléchargements sont livrés automatiquement après le paiement. Vous n'avez aucun broker à construire ni à exploiter.

Roctify ne propose pas de webhooks ni d'API publics, vous ne pouvez donc pas abonner vos propres outils à ses événements aujourd'hui. Si votre activité exige des intégrations au-delà des fonctionnalités incluses, par exemple avec un entrepôt ou un logiciel comptable précis, elles se discutent dans le plan Enterprise. En attendant, les rapports et exports du plan Pro couvrent la plupart des besoins de comptabilité et d'analyse.

FAQ

Architecture événementielle veut-elle dire temps réel ?

Pas exactement. Les événements arrivent en général en moins d'une seconde, mais la conception accepte que certains consommateurs prennent du retard. Elle privilégie la résilience à la cohérence instantanée. Pour ce qui doit être immédiat et exact, comme le stock au checkout, les équipes gardent un contrôle direct.

Ma boutique a-t-elle besoin d'une architecture événementielle ?

Probablement pas comme choix de conception de votre part. Votre prestataire de paiement et votre plateforme utilisent déjà des événements en coulisses. La question devient réelle quand vous faites développer un système sur mesure avec de nombreux services connectés.

Quelle différence entre un événement et un webhook ?

Un événement, c'est l'idée générale d'annoncer un fait. Un webhook est un mode de livraison parmi d'autres, un appel HTTP d'un système vers l'adresse web d'un autre quand l'événement survient. Beaucoup d'événements restent à l'intérieur d'un même système, les webhooks les transportent vers celui d'une autre entreprise.