Architecture event-driven et plateformes de streaming

En 2017, un distributeur organisé en batch a découvert que son « système de détection de fraude » repérait les fraudes en moyenne neuf heures après la validation de la transaction. Le modèle était excellent. Le problème venait du pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → : les signaux de fraude dormaient dans un job ETLETLL'ETL (Extract, Transform, Load) est un processus d'intégration de données qui extrait les données de sources multiples, les remet en forme dans un format cohérent et les écrit dans un système cible.Voir la définition complète → nocturne, en attendant l'exécution de 2 h du matin. Quand l'alerte se déclenchait, la marchandise était expédiée et la carte plafonnée. Le correctif n'était pas un meilleur modèle. C'était une autre *forme* de circulation des données, une forme où la transaction annonce elle-même son existence à l'instant où elle se produit, et où un nombre quelconque de systèmes peut réagir en quelques millisecondes.

Ce basculement, qui consiste à ne plus demander aux systèmes « quel est le dernier état ? » mais à les laisser *annoncer que quelque chose a changé*, c'est toute l'architecture event-driven. En tant que CDO, vous détenez déjà la stratégie data et la gouvernance qui l'entoure. Ce que la plupart des data leaders sous-estiment, c'est que **l'*architecture de circulation des données* est un levier stratégique, pas un détail de plomberie**. Ratez-la et toutes les ambitions temps réel de votre CEO, personnalisation, pricing dynamique, IA opérationnelle, meurent dans une fenêtre de batch nocturne.

Ce qu'est réellement un événement (et pourquoi cela change tout)

Un événement est un fait immuable à propos de quelque chose qui s'est produit, horodaté. OrderPlaced. PaymentFailed. SensorReadingExceededThreshold. CustomerLoggedIn. Notez le passé, ce n'est pas un hasard. Un événement n'est pas une commande (« débite cette carte ») ni une requête (« quel est le solde ? »). **C'est l'enregistrement du fait que *le monde a bougé*, et cela ne peut pas être dé-produit.**

Cette distinction compte plus qu'il n'y paraît. Dans votre monde traditionnel, la source de vérité est une table, un instantané de l'état *courant*. L'adresse d'un client est ce que dit la ligne aujourd'hui. Dans un monde event-driven, la source de vérité devient le *journal de tout ce qui s'est jamais produit*, et l'état courant n'est qu'une projection que vous calculez à partir de ce journal. L'adresse du client est le résultat du rejeu de tous les événements AddressChanged.

C'est le changement de modèle mental que la plupart des dirigeants manquent, alors rendons-le concret par ses conséquences pratiques :

• L'état devient reconstructible. Si un système en aval corrompt ses données, vous rejouez le journal d'événements et vous le reconstruisez. Les pipelines batch ne peuvent pas le faire ; les lignes sources ont déjà été écrasées.
• De nouveaux consommateurs peuvent arriver tard et récupérer tout l'historique. Une équipe monte un feature storefeature storeRéférentiel centralisé qui gère les features de ML et garantit la cohérence entre les environnements d'entraînement et de production.Voir la définition complète → ML six mois après le lancement et rejoue deux ans d'événements pour faire le backfill. Pas de ticket data engineering, pas de charge sur le système source.
• Le temps devient un citoyen de première classe. Vous pouvez demander « que savions-nous à 15 h 14 ? », ce qui est critique pour l'audit, le debug de modèles et la reconstitution réglementaire.

Le problème de fraude du distributeur venait, au fond, de ce qu'**ils traitaient les transactions comme un *état à interroger plus tard* plutôt que comme des *événements auxquels réagir maintenant***.

L'événement comme contrat

C'est ici que les réflexes de gouvernance du CDO doivent s'étendre à l'architecture. Un événement est un contrat publié entre celui qui le produit et tous ceux qui le consomment. Le schéma de `OrderPlaced`, ses champs, ses types et leur signification, devient une API partagée à l'échelle de l'entreprise. Modifiez-le sans précaution et vous cassez des systèmes dont vous n'avez jamais entendu parler.

C'est pourquoi les organisations matures en streaming exploitent un schema registry avec des règles de compatibilité imposées. Vous n'avez pas le droit de renommer un champ parce que c'était pratique pour votre équipe. Les événements sont des actifs stratégiques gouvernés exactement comme les data products de votre portefeuille de monétisation : versionnés, avec un owner, documentés et rétrocompatibles par principe.

Pourquoi découpler les producteurs des consommateurs est le vrai gain

L'avantage technique que tout le monde cite est le « scale ». C'est vrai mais superficiel. Le gain plus profond est le *découplage organisationnel*, et c'est bien un sujet de CDO, parce que votre goulot d'étranglement n'est presque jamais le compute. C'est la coordination entre équipes.

Dans un monde piloté par la requête, l'intégration est point-à-point. Le système de commandes appelle le système de stock, qui appelle le système de fidélité, qui appelle le système analytique. Chaque nouveau consommateur signifie une nouvelle intégration, une nouvelle dépendance, une nouvelle réunion. Avec *N* systèmes vous marchez vers *N²* connexions, et chacune est un endroit où votre architecture peut se bloquer. C'est le « spaghetti d'intégration » qui consomme silencieusement 40 % de votre capacité d'ingénierie.

L'architecture event-driven inverse cela. Le producteur publie OrderPlaced dans un stream et ne sait pas, ni ne se soucie de savoir, qui le consomme. L'équipe stock s'abonne. Plus tard l'équipe fidélité s'abonne. Plus tard encore, une équipe data science s'abonne pour construire une feature de churn, sans jamais parler à l'équipe commandes. Le travail du producteur s'est terminé quand il a publié le fait.

Producer  →  [ OrderPlaced topic ]  →  Inventory service
                                    →  Loyalty service
                                    →  Fraud scoring
                                    →  Analytics / feature store

Le bénéfice organisationnel est le suivant : les équipes livrent sans négociation inter-équipes. Votre plateforme data cesse d'être une file de demandes d'intégration et devient une place de marché où les équipes publient et s'abonnent à leur propre rythme. Pour un CDO qui cherche à passer à l'échelle l'usage de la data dans une entreprise que votre équipe centrale ne peut plus suivre, c'est le seul modèle qui fonctionne. L'intégration centralisée point-à-point ne passe pas une certaine taille d'organisation, elle transforme simplement vos meilleurs ingénieurs en courtiers d'intégration à plein temps.

Les compromis qui vous appartiennent, et qui ne se délèguent pas

Le découplage n'est pas gratuit, et ses coûts sont précisément ceux qu'un CDO doit arbitrer parce qu'ils traversent les frontières d'équipes :

• La cohérence à terme. Les consommateurs traitent à leur propre rythme. Pendant quelques centaines de millisecondes, parfois quelques secondes, le compteur de stock et le compteur de commandes se contredisent. Vos partenaires métier doivent comprendre que « temps réel » signifie « à terme, rapidement et de façon asynchrone », pas « instantanément cohérent partout ». C'est une conversation business, pas technique.
• Le debug devient distribué. Quand quelque chose dérape, l'histoire est éparpillée sur une douzaine de consommateurs qui avancent indépendamment. Il vous faut du tracing distribué et une observabilité solide *dès le premier jour*, pas ajoutés après le premier incident.
• Ordonnancement et doublons. Les plateformes de streaming garantissent généralement une livraison *at-least-once*, ce qui veut dire qu'un consommateur peut voir deux fois le même événement. Chaque consommateur doit être idempotent : traiter deux fois le même événement produit le même résultat. C'est une discipline de conception que vous devez imposer comme règle, parce qu'un seul consommateur non idempotent qui double-facture un client devient *votre* titre de presse.

Les plateformes : kafka vs. cloud pub/sub, et comment choisir

Vous n'avez pas besoin de configurer un broker. Vous avez besoin de prendre correctement la *décision* de plateforme, parce que c'est un engagement de cinq à dix ans avec de vraies implications de coût et de lock-in.

Apache Kafka (et ses formes managées, Confluent Cloud, AWS MSK) est un *log distribué et durable*. Les événements sont écrits dans des topics, partitionnés pour le parallélisme et, point critique, *conservés*. Kafka garde les événements pendant des jours, des semaines, ou pour toujours. C'est ce qui permet le replay, le backfill et le traitement du log comme source de vérité. Les consommateurs suivent leur propre position (l'« offset ») et peuvent revenir en arrière. Kafka est le bon choix par défaut quand vous voulez que le journal d'événements soit un actif durable, quand vous avez besoin d'un très haut débit et quand le replay est central dans vos cas d'usage (feature stores, event sourcing, audit).

Cloud Pub/Sub (Google Pub/Sub, AWS SNS/SQS, Azure Service Bus) est un *service de messagerie*. Son modèle mental est « livre ce message aux abonnés, puis passe à la suite ». La rétention est plus courte et le replay plus limité. En échange, c'est bien plus simple à exploiter : entièrement serverless, charge d'ops quasi nulle, scalabilité élastique sans que vous ayez à penser aux partitions. C'est le bon choix quand vous voulez le découplage event-driven *sans* exploiter une plateforme, et quand rejouer un historique profond n'est pas une exigence centrale.

Voici le cadre de décision que je mettrais sur une seule slide :

L'erreur que je vois sans cesse : des équipes adoptent Kafka pour son prestige, puis passent un an à se construire un muscle opérationnel dont elles n'avaient pas besoin pour ce qui était en réalité un problème de notification. Alignez la plateforme sur *le besoin d'historique et de débit du cas d'usage*, pas sur du résume-driven development.

Une idée de configuration à intégrer

Vous ne l'écrivez pas, mais vous devriez reconnaître ce que cela signifie quand vos architectes en débattent. Dans Kafka, le nombre de partitions d'un topic fixe le plafond de la consommation parallèle :

partitions = 12       # jusqu'à 12 consumers traitent ce topic en parallèle
retention.ms = 604800000   # conserver chaque événement 7 jours pour le replay

Le jugement contenu là-dedans : les partitions sont difficiles à augmenter plus tard sans casser les garanties d'ordonnancement. Sous-dimensionnez et vous bridez le débit ; surdimensionnez et vous gaspillez des ressources et compliquez le rebalancing. Quand votre équipe vous demande une décision sur la stratégie de partitionnement, elle vous demande en réalité de chiffrer l'arbitrage entre le scale futur et la simplicité présente. C'est un appel de CDO, pas d'un ingénieur junior.

Où un CDO applique concrètement cela lundi matin

Les frameworks ne valent rien sans application. Voici où l'architecture event-driven justifie son coût, et **comment décider *si elle est justifiée du tout***.

1. Analytique opérationnelle et IA en temps réel. Votre exemple de fraude, le pricing dynamique, les moteurs de recommandation, la réallocation de stock, la maintenance prédictive. Toute décision dont la valeur *décrocroLe Conversion Rate Optimization (CRO) est la pratique systématique visant à augmenter le pourcentage d'utilisateurs qui réalisent une action souhaitée, en s'appuyant sur la data, les tests et la recherche utilisateur.Voir la définition complète →ît avec le temps* est un candidat. Le test : une décision prise en 200 millisecondes bat-elle la même décision prise en six heures ? Si oui, le batch laisse de l'argent sur la table.

2. Alimenter le feature store. C'est l'application la plus à fort effet de levier et la plus sous-estimée. Si vos fondamentaux ML sont déjà en place, le prochain saut de maturité, ce sont les *features fraîches*. Un modèle qui score sur des features vieilles de 24 heures devine. Streamer les événements vers votre feature store signifie que le même événement qui pilote les opérations pilote aussi le modèle, éliminant le fameux training-serving skew où votre pipeline batch et votre pipeline live calculent les features différemment.

3. Le Change Data Capture (CDC) comme voie d'accès. Vous n'avez pas à refaire le monde. Les outils CDCCDCTechnique qui détecte et transmet uniquement les données modifiées d'un système source, gardant les systèmes en aval à jour sans tout recharger.Voir la définition complète → (Debezium est le plus courant) lisent le journal de transactions de vos bases existantes et *émettent chaque changement de ligne comme un événement*, sans toucher à l'application source. C'est le point d'entrée pragmatique : vous obtenez un stream d'événements depuis un système legacy qui n'a aucune notion d'événement, et vous vous achetez du temps pour moderniser progressivement. C'est ainsi que la plupart des entreprises démarrent réellement.

4. Casser le monolithe sans réécriture. Quand vous avez besoin d'une capacité nouvelle qui exigerait sinon de modifier un système central fragile, vous vous abonnez à ses événements au lieu de toucher à son code. L'architecture event-driven est souvent la façon *la moins invasive* d'ajouter de la valeur au-dessus de systèmes que vous ne pouvez pas vous payer de remplacer.

Les anti-patterns qui vous coûteront cher

Dites non au streaming quand :

• La donnée est par nature batch. Clôture financière mensuelle, reporting trimestriel, réentraînement de modèle hebdomadaire : forcer cela dans du streaming ajoute coût et complexité pour zéro gain de latence. Tout n'a pas besoin d'être en temps réel ; le « temps réel partout » est une odeur d'architecture.
• Vous manquez de maturité opérationnelle. Les plateformes de streaming exigent de l'observabilité, une discipline d'astreinte et une rigueur d'idempotence. Adopter Kafka avant d'avoir cela produit un système fragile qui échoue silencieusement et érode la confiance dans la data, le seul actif que vous ne pouvez pas vous permettre de perdre.
• Il n'y aura jamais qu'un seul consommateur. Toute la valeur réside dans la multiplicité de consommateurs indépendants. Un producteur, un consommateur, pour toujours ? Une intégration directe est plus simple et c'est celle qu'il faut utiliser.

Le cadrage stratégique à porter devant vos pairs du comité : **l'architecture event-driven est un investissement dans l'*optionalité***. Vous payez aujourd'hui une prime de complexité pour rendre les cas d'usage futurs peu coûteux à ajouter. C'est justifié quand vous avez une roadmap d'ambitions temps réel et IA. C'est du sur-dimensionnement quand vous n'en avez pas.

Points clés

1. Traitez les événements comme des contrats gouvernés, pas comme des messages. Étendez votre discipline de gouvernance existante à un schemaschemaUn schema est le plan formel qui définit comment les données sont structurées, nommées, typées et reliées entre elles au sein d'une base de données, d'un fichier ou d'un message.Voir la définition complète → registry avec rétrocompatibilité imposée. Un changement de schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → cassant est un changement d'API cassant, et le rayon d'explosion vous appartient.

1. Achetez du découplage, pas seulement de la vitesse. Le gain stratégique, c'est que les équipes publient et s'abonnent sans négociation inter-équipes. Si votre plateforme data est une file de demandes d'intégration, l'architecture event-driven est le moyen de dissoudre ce goulot d'étranglement quand l'organisation grandit.

1. Choisissez la plateforme selon son besoin d'historique. Par défaut Kafka quand le replay, le backfill et le log comme source de vérité comptent ; par défaut cloud Pub/Sub quand vous voulez du découplage event-driven avec une charge opérationnelle quasi nulle. Refusez l'adoption de Kafka par résume-driven development pour des problèmes de forme « notification ».

1. Commencez par le CDC, pas par une réécriture. Émettez des événements depuis vos bases existantes via le change data capture pour tirer une valeur d'entrée de systèmes legacy sans toucher à leur code, puis modernisez de façon incrémentale.

1. Imposez l'idempotence et l'observabilité comme règle dès le premier jour. La livraison at-least-once implique que chaque consommateur gère les doublons sans risque, et le debug distribué exige du tracing avant votre premier incident, pas après.