Analyse en temps réel : traitement des données en streaming pour des informations instantanées

Les décisions commerciales ont toujours eu un problème de latence. Les données des opérations de mardi sont traitées mercredi soir, analysées par l'équipe d'analyse jeudi, examinées lors d'une réunion le vendredi et traitées la semaine suivante, date à laquelle la situation opérationnelle a de nouveau changé. Ce décalage d'une semaine entre l'événement et la réponse constitue un désavantage concurrentiel structurel sur les marchés où les concurrents disposant d'une meilleure infrastructure de données peuvent répondre aux signaux en quelques minutes.

L'analyse en temps réel réduit cette latence de quelques jours à quelques secondes ou, dans les implémentations les plus avancées, à quelques millisecondes. Au lieu d'un traitement par lots du jour au lendemain, le traitement des données en continu analyse les événements au fur et à mesure qu'ils se produisent, met à jour les tableaux de bord en permanence et déclenche des réponses automatisées dès que les conditions le justifient.

La technologie permettant d’y parvenir à l’échelle de l’entreprise a considérablement évolué. Apache Kafka, Apache Flink et les services de streaming cloud modernes ont rendu le traitement des données en temps réel accessible à des organisations autres que Google, LinkedIn ou Netflix. L’avantage concurrentiel des informations en temps réel – qui nécessitait des milliards d’investissements dans les infrastructures il y a dix ans – est désormais à la portée des entreprises de taille moyenne.

Points clés à retenir

L'analyse en temps réel réduit la latence des décisions de quelques jours à quelques secondes, permettant des réponses opérationnelles plus rapides

La pile de traitement des données en streaming comporte trois couches : ingestion (Kafka), traitement (Flink/Spark Streaming) et service (bases de données OLAP en temps réel)

Apache Kafka est le standard de facto pour le streaming d'événements d'entreprise, traitant quotidiennement des milliards d'événements dans le monde.

Les bases de données OLAP en temps réel (Druid, Pinot, ClickHouse) permettent des requêtes inférieures à la seconde sur les données en streaming

L'analyse opérationnelle — surveillance en temps réel des opérations commerciales — offre un retour sur investissement plus rapide que les rapports analytiques

Les ensembles de données de streaming Power BI et Azure Stream Analytics fournissent des tableaux de bord accessibles en temps réel pour les organisations centrées sur Microsoft

L'architecture "lambda" (combinant batch et streaming) est remplacée par "l'architecture kappa" (streaming uniquement)

Cas d'usage : détection de fraude, suivi opérationnel, analyse du comportement client, visibilité de la supply chain, risque marchés financiers

Pourquoi l'analyse en temps réel est importante

La valeur des données diminue rapidement. Un client abandonnant un panier en ce moment est une opportunité d'intervention ; un client qui a abandonné le panier d'hier est une audience de reciblage. Une machine montrant actuellement des signes de panne constitue une opportunité de maintenance prédictive ; une machine qui est tombée en panne ce matin est un incident d'arrêt imprévu.

Le taux de décroissance varie selon le cas d'utilisation :

Fraude financière : la valeur des données diminue en millisecondes – les décisions de fraude doivent être prises en temps réel avant la fin de la transaction
Surveillance de la machine : la valeur des données diminue en secondes ou en minutes – une intervention sur l'équipement doit avoir lieu avant la panne
Comportement des clients : la valeur diminue en quelques minutes ou quelques heures – la récupération après abandon de panier a la conversion la plus élevée en 30 à 60 minutes
Visibilité de la chaîne d'approvisionnement : la valeur diminue en quelques heures — résolution des exceptions de livraison avant l'impact sur le client
Surveillance des performances commerciales : la valeur diminue en quelques heures ou quelques jours – les décisions opérationnelles quotidiennes bénéficient de données le jour même

Différents cas d'utilisation nécessitent différentes cibles de latence, qui conduisent à différents choix architecturaux.

La pile d'architecture de données en streaming

Construire une capacité d’analyse en temps réel nécessite d’assembler une pile de technologies complémentaires :

Couche 1 : Ingestion d'événements – Apache Kafka

Apache Kafka est le standard de facto pour le streaming d'événements d'entreprise. Créé chez LinkedIn en 2011 et open source, Kafka est désormais le système nerveux central pour les données en temps réel de milliers d'entreprises dans le monde, traitant plus de 7 000 milliards de messages par jour rien que sur LinkedIn.

Ce que fait Kafka : Kafka est un système de messagerie de publication-abonnement distribué, durable et à haut débit. Les producteurs publient des événements sur des sujets ; les consommateurs s'abonnent à des sujets et traitent des événements. Les événements sont stockés pendant des périodes de conservation configurables (généralement de 7 à 30 jours), permettant la relecture et plusieurs groupes de consommateurs indépendants.

Pourquoi Kafka : débit (millions d'événements par seconde), durabilité (les événements sont conservés sur le disque, répliqués entre les courtiers), tolérance aux pannes (les groupes de consommateurs se rééquilibrent automatiquement en cas de défaillance d'un consommateur) et découplage qu'il assure entre les producteurs et les consommateurs.

Options Kafka gérées : L'exécution de Kafka nécessite une expertise opérationnelle significative. Les options gérées incluent Confluent Cloud (le Kafka commercial entièrement géré), AWS MSK (Amazon Managed Streaming for Kafka) et Azure Event Hubs (service géré compatible Kafka). Pour les organisations ne disposant pas d’une expertise approfondie de Kafka, les services gérés réduisent considérablement la charge opérationnelle.

Alternatives à Kafka : Amazon Kinesis (AWS natif, plus simple que Kafka, plafond de débit inférieur), Google Pub/Sub (Google Cloud natif, entièrement géré, puissant à l'échelle mondiale), Apache Pulsar (plus récent, débit plus élevé que Kafka dans les benchmarks, moins de maturité de l'écosystème).

Couche 2 : Traitement des flux

Les flux d'événements bruts de Kafka nécessitent un traitement (transformation, enrichissement, agrégation et analyse) avant de produire des informations exploitables.

Apache Flink : le principal framework de traitement de flux pour les charges de travail d'analyse en temps réel. Flink fournit une sémantique de traitement unique, un traitement au moment de l'événement (gestion correcte des événements dans le désordre) et un traitement de flux avec état (maintien de l'état entre les événements). Le framework de traitement de flux le plus sophistiqué ; nécessite une expertise importante pour fonctionner.

Apache Spark Streaming / Structured Streaming : la capacité de streaming de Spark traite des micro-lots de données en streaming. Plus facile à apprendre que Flink (en particulier pour les équipes ayant une expérience Spark par lots) ; latence légèrement supérieure au vrai streaming mais acceptable pour la plupart des cas d'utilisation.

Apache Kafka Streams : bibliothèque permettant de créer des applications de traitement de flux qui s'exécutent au sein des processus consommateur Kafka. Déploiement plus simple que Flink ou Spark (pas de cluster séparé) ; moins capable de traiter des traitements complexes.

Apache Storm : ancien framework de traitement de flux, largement remplacé par Flink et Spark. Maintenu mais non recommandé pour les nouveaux déploiements.

Traitement de flux géré dans le cloud : AWS Kinesis Data Analytics (prend en charge Flink), Azure Stream Analytics (diffusion propriétaire basée sur SQL), Google Dataflow (Apache Beam géré). Ces services gérés réduisent la complexité opérationnelle au prix d’une certaine flexibilité.

Couche 3 : OLAP en temps réel – Servir les requêtes

L'analyse en temps réel nécessite des bases de données optimisées pour des requêtes rapides sur des données fraîchement ingérées — une optimisation différente de celle des bases de données transactionnelles (OLTP) ou des bases de données analytiques traditionnelles (OLAP).

Apache Druid : spécialement conçu pour OLAP en temps réel. Druid ingère les données en streaming de Kafka, les stocke dans un format en colonnes optimisé pour les requêtes analytiques et prend en charge les requêtes inférieures à la seconde sur des milliards de lignes. Utilisé par Netflix, Airbnb, Lyft et des centaines d'autres sociétés pour les tableaux de bord d'analyse en temps réel.

Apache Pinot : développé sur LinkedIn et open source. Capacité similaire à Druid avec de solides performances pour l'analyse orientée utilisateur (fournir des analyses en temps réel aux utilisateurs finaux à grande échelle). Utilisé par LinkedIn (pour les analyses « Qui a consulté votre profil »), Uber et d'autres.

ClickHouse : base de données OLAP en colonnes open source avec des performances de requête extrêmement élevées. Prend en charge l’ingestion de streaming et les requêtes en temps réel. Croissance rapide en tant qu'alternative Druide/Pinot avec des opérations plus simples. Utilisé par Cloudflare, ByteDance et bien d'autres.

Apache Pinot contre Druid contre ClickHouse : ces trois choix sont des choix judicieux ; la décision dépend souvent des préférences opérationnelles, de l’adéquation à l’écosystème et des modèles de requêtes spécifiques. ClickHouse propose les opérations les plus simples ; Druid et Pinot prennent davantage en charge les optimisations spécifiques aux séries chronologiques.

TimescaleDB : extension PostgreSQL optimisée pour les données de séries chronologiques. Débit inférieur à celui de Druid/ClickHouse mais interface SQL et modèle opérationnel familiers. Bon choix pour les analyses en temps réel à échelle modérée.

Modèles d'architecture de streaming

###Architecture Lambda

L'architecture Lambda (inventée par Nathan Marz) relève le défi de combiner l'analyse en temps réel et par lots en exécutant deux chemins de traitement parallèles :

Couche batch : traite périodiquement toutes les données historiques (horaires, quotidiens), produisant des vues précises mais latentes des données.

Couche de vitesse : traite les données de streaming récentes en temps réel, produisant des vues à faible latence mais potentiellement incomplètes ou approximatives.

Couche de service : fusionne les sorties par lots et par couche rapide, offrant une vue complète, approximativement en temps réel.

L'architecture Lambda était l'approche dominante pour 2012-2018. Ses principaux inconvénients : le maintien de deux bases de code de traitement distinctes (batch et streaming) est complexe sur le plan opérationnel, et la logique de fusion dans la couche de service introduit une complexité supplémentaire.

Architecture Kappa

L'architecture Kappa (proposée par Jay Kreps) simplifie lambda en utilisant le streaming pour tout : à la fois le traitement en temps réel et le traitement par lots historique.

Chemin de traitement unique : toutes les données transitent par le pipeline de streaming. Le traitement historique est réalisé en rejouant les événements historiques à partir du stockage durable de Kafka via la tâche de streaming.

Opérations plus simples : un cadre de traitement, une base de code, une infrastructure à exploiter.

L'architecture Kappa nécessite que votre infrastructure de streaming puisse gérer efficacement la relecture complète de l'ensemble de données historiques : la rétention de Kafka et les capacités de Flink rendent cela pratique. La plupart des nouveaux systèmes d'analyse en temps réel reposent sur l'architecture Kappa.

Données en temps réel Lakehouse

Le modèle émergent intègre le streaming en temps réel à l’architecture Data Lakehouse :

Diffusion dans Delta Lake / Apache Iceberg : les flux d'événements sont écrits directement dans les formats de table Lakehouse (Delta Lake, Apache Iceberg, Apache Hudi), qui prennent en charge les transactions ACID, l'évolution des schémas et le traitement incrémentiel efficace.

Lot et streaming unifiés : la même table Lakehouse contient à la fois des données de lot historiques et des données de streaming récentes, interrogeables via une interface unique. Pas de magasins de streaming et de lots séparés à réconcilier.

Databricks Delta Live Tables, AWS Lake Formation + Kinesis et Apache Iceberg + Flink sont les principales implémentations de ce modèle.

Cas d'utilisation par secteur

Services financiers : Détection de fraude

La détection des fraudes en temps réel constitue le cas d’utilisation de l’analyse de streaming aux enjeux les plus élevés. Les décisions en matière de fraude doivent être prises en quelques millisecondes – alors que la transaction est en cours – car l’annulation des transactions terminées est coûteuse et parfois impossible.

Une architecture typique de détection de fraude en temps réel :

Événement de transaction publié sur Kafka lors de son entrée dans le système de paiement
Le travail de streaming Flink traite l'événement en l'enrichissant de l'historique du client, des empreintes digitales de l'appareil et des fonctionnalités comportementales.
Le modèle de notation de fraude ML évalue l'événement enrichi (modèle servi via l'API d'inférence en temps réel)
Décision renvoyée au système de paiement dans un délai de 50 à 200 ms
Événement et décision stockés dans OLAP en temps réel pour la surveillance opérationnelle et le recyclage du modèle

Le système de détection de fraude de Visa traite 65 000 transactions par seconde avec une latence de décision inférieure à 100 ms, évitant ainsi une fraude estimée à 25 milliards de dollars par an.

eCommerce : personnalisation en temps réel

L'analyse comportementale en temps réel permet une personnalisation qui répond à ce que fait actuellement le client, et non à ce qu'il a fait lors de sa dernière session.

Lorsqu'un client parcourt un produit, l'événement est transmis à un processeur de streaming qui :

Met à jour le profil d'intérêt du client en temps réel
Identifie les produits similaires que le client n'a pas vus
Évalue l'éligibilité promotionnelle actuelle
Génère un ensemble de recommandations personnalisées

La recommandation est prête quelques secondes après l'événement de navigation, permettant une personnalisation de la page en temps réel plutôt qu'une personnalisation au démarrage de la session qui devient rapidement obsolète.

Fabrication : Suivi opérationnel

L'analyse en continu en temps réel des opérations de fabrication permet :

Suivi continu de l'OEE (Overall Equipment Effectiveness) mis à jour toutes les minutes à partir des signaux de la machine
Tableaux de bord de gestion des alarmes affichant les états actuels de la machine et l'historique des alarmes en temps réel
Signaux de contrôle qualité — Alertes SPC (Statistical Process Control) hors de contrôle au fur et à mesure qu'elles se produisent
Suivi des performances de production par rapport au calendrier mis à jour en permanence

Cette visibilité opérationnelle en temps réel constitue le fondement de la fonctionnalité MES (Manufacturing Execution System) dans les usines intelligentes modernes.

Supply Chain : visibilité des expéditions

Les données GPS et IoT en temps réel des véhicules, des navires et des installations permettent une visibilité continue de la chaîne d'approvisionnement, indiquant où se trouve chaque expédition en ce moment, avec des prévisions ETA et des alertes d'exception.

La visibilité logistique interne d'Amazon – connaître simultanément l'état en temps réel de millions de colis – est une capacité opérationnelle essentielle permettant l'exactitude de ses promesses de livraison.

Power BI pour l'analyse en temps réel

Pour les organisations déjà investies dans l’écosystème Microsoft, Power BI fournit des fonctionnalités d’analyse en temps réel accessibles sans nécessiter une architecture complète de données en streaming.

Ensembles de données de streaming Power BI

Power BI prend en charge les jeux de données en streaming : des connexions de données qui mettent à jour le rapport en temps réel à mesure que de nouvelles données arrivent. Trois types :

Push streaming : les données sont transmises à Power BI via l'API Push (appel d'API REST au point de terminaison de l'ensemble de données Power BI). Les données sont stockées et peuvent être interrogées historiquement. Convient aux tableaux de bord opérationnels où le contexte historique est important.

Streaming uniquement : flux de données via Power BI sans stockage persistant. Très faible latence ; pas de requête historique. Convient pour surveiller les tableaux de bord où seul l’état actuel compte.

Diffusion PubNub : se connecte aux flux de données en temps réel PubNub. Principalement pour les cas d’utilisation de l’IoT et de la surveillance des médias sociaux.

Azure Stream Analytics + Power BI

Azure Stream Analytics est le service de traitement de flux géré de Microsoft, basé sur SQL, accessible aux analystes sans expertise approfondie des systèmes distribués. L’adaptateur de sortie Power BI natif envoie les résultats agrégés des requêtes de streaming directement aux ensembles de données Power BI.

Architecture :

IoT Hub ou Event Hubs ingère des données en streaming
Azure Stream Analytics exécute des requêtes de fenêtre SQL sur le flux
Les résultats sont transférés vers un ensemble de données Power BI Push
Rapports Power BI sur l'ensemble de données en temps réel avec actualisation automatique

Cette architecture est accessible aux équipes de business intelligence sans nécessiter l'expertise de Kafka ou Flink, ce qui rend les tableaux de bord opérationnels en temps réel réalisables pour les entreprises de taille moyenne.

Exemples de tableaux de bord en temps réel Power BI

Tableau de bord OEE de fabrication : Signaux machine → Azure IoT Hub → Stream Analytics (calcul des composants OEE) → Ensemble de données en temps réel Power BI → Mise à jour du tableau de bord OEE en direct toutes les 30 secondes.

Suivi logistique : événements GPS → Event Hubs → Stream Analytics (calcul de l'état de l'expédition et de l'ETA) → Visualisation de la carte Power BI avec positions des véhicules en direct.

Opérations de commerce électronique : événements de commande → Event Hubs → Stream Analytics (ventes par SKU, région, tendance horaire) → Tableau de bord de surveillance des commandes Power BI pour l'équipe des opérations.

## Guide de mise en œuvre

Quand créer en temps réel, en temps quasi réel ou par lots

Tous les cas d’utilisation de l’analyse ne nécessitent pas un véritable traitement en temps réel. Faire correspondre la latence aux besoins réels de l’entreprise évite une ingénierie excessive :

Véritable temps réel (sous-seconde) : détection de fraude, surveillance de la sécurité industrielle, enchères en temps réel, risque des marchés financiers. Nécessite Kafka + Flink ou équivalent.

En temps quasi réel (1 à 5 minutes) : tableaux de bord de surveillance opérationnelle, files d'attente du service client, alertes d'exception de la chaîne d'approvisionnement. Réalisable avec des architectures de streaming plus simples ou un traitement par micro-lots.

Lot fréquent (horaire) : surveillance quotidienne des activités, analyses intrajournalières, rapports périodiques. ETL par lots standard vers l'entrepôt de données ; plus simple et moins cher que le streaming.

Lot quotidien : la plupart des rapports analytiques, des évaluations de performances et des prévisions. Modèles d'entrepôt de données standard.

Pour commencer : le chemin pratique

Phase 1 : identifiez votre cas d'utilisation en temps réel à plus forte valeur ajoutée. Cartographiez les données nécessaires, la latence requise et les décisions ou actions qu'elles permettent. Validez la valeur commerciale avant d’investir dans l’infrastructure.

Phase 2 : Commencez par les services gérés. Utilisez Confluent Cloud pour Kafka (non autogéré), Azure Stream Analytics ou Kinesis Data Analytics pour le traitement des flux (non autogéré Flink). Streaming Power BI pour les tableaux de bord. Cela réduit considérablement la charge opérationnelle initiale.

Phase 3 : créez le premier cas d'utilisation de bout en bout. Mesurez la latence, le débit et l’impact commercial.

Phase 4 : extension à des cas d'utilisation supplémentaires sur l'infrastructure établie. Le deuxième cas d’utilisation est nettement moins cher que le premier car l’infrastructure existe déjà.

Questions fréquemment posées

Quelle est la différence entre l'analyse en continu et l'analyse en temps réel ?

Les termes sont souvent utilisés de manière interchangeable, bien que techniquement distincts. L'analyse du streaming fait référence au traitement continu de flux de données illimités, c'est-à-dire des données qui arrivent en continu sans fin définie. L'analyse en temps réel fait référence à l'analyse avec une latence très faible, permettant des informations quasi instantanées. L'analyse du streaming est l'approche technique ; l'analyse en temps réel est la caractéristique de latence. Toutes les analyses de streaming ne doivent pas nécessairement être « en temps réel » (les tâches de streaming exécutées toutes les 5 minutes sont diffusées en continu, mais pas en temps réel) ; toutes les analyses en temps réel n'utilisent pas le streaming (les requêtes de base de données peuvent être effectuées en temps réel sur des données statiques). En pratique, la plupart des implémentations d'« analyse en temps réel » d'entreprise utilisent des architectures de streaming.

Comment Kafka se compare-t-il à une file d'attente de messages traditionnelle comme RabbitMQ ?

Les files d'attente de messages traditionnelles (RabbitMQ, ActiveMQ) acheminent les messages des producteurs vers les consommateurs et les suppriment une fois consommés. Kafka est fondamentalement différent : il s'agit d'un journal distribué dans lequel les messages sont stockés pendant des périodes de conservation configurables, et plusieurs groupes de consommateurs peuvent lire les mêmes messages indépendamment. Cela permet : la relecture (retraiter tous les événements à partir d'un point dans le temps), plusieurs consommateurs indépendants (l'analyse, la surveillance et l'archivage peuvent tous consommer les mêmes événements) et un débit élevé (Kafka atteint 100 Mo/seconde sur du matériel standard contre 10 Mo/seconde pour les files d'attente traditionnelles). Utilisez Kafka pour le streaming d'événements à haut débit et les cas d'utilisation analytique ; utilisez RabbitMQ pour les scénarios de routage complexe et de file d'attente de travail à faible volume.

Quels sont les principaux défis opérationnels liés à l'exécution d'Apache Kafka en production ?

Principaux défis opérationnels de Kafka : gestion des partitions (déterminer le nombre approprié de partitions pour chaque sujet, ce qui affecte le débit et le classement), surveillance du décalage des consommateurs (détecter quand les consommateurs sont en retard sur les producteurs, indiquant un goulot d'étranglement de traitement), configuration du facteur de réplication (équilibrer la durabilité et les coûts de stockage), gestion des compensations (garantir que les consommateurs ne perdent pas leur position dans le flux) et évolution des schémas (gérer les modifications des formats de message sans casser les consommateurs). Ces défis expliquent pourquoi les services gérés Kafka (Confluent Cloud, AWS MSK) se sont développés rapidement : ils gèrent la plus grande complexité opérationnelle, permettant aux équipes de se concentrer sur la logique des applications.

Comment garantir un traitement unique dans l'analyse de streaming pour éviter de compter les événements plusieurs fois ?

Le traitement exactement une fois – garantir que chaque événement est traité exactement une fois malgré les échecs – est techniquement difficile. Apache Flink fournit une sémantique native exactement une fois via des points de contrôle et des récepteurs transactionnels. L'API du producteur transactionnel de Kafka fournit une livraison en une seule fois au sein de Kafka. Pour une opération exactement une fois de bout en bout (du système source au traitement jusqu'à la sortie), tous les composants du pipeline doivent prendre en charge la sémantique exactement une fois et l'architecture doit être conçue en conséquence. En pratique, de nombreux systèmes de streaming acceptent le traitement au moins une fois (ils peuvent traiter le même événement plusieurs fois) et rendent le traitement en aval idempotent (le traitement du même événement plusieurs fois produit le même résultat qu'un traitement unique). C'est plus simple et souvent suffisant pour les cas d'utilisation analytiques.

Comment gérer les données arrivant tardivement dans l'analyse de streaming ?

Les données arrivant tardivement (les événements qui arrivent après le traitement de la fenêtre temporelle à laquelle ils appartiennent) constituent un défi fondamental en matière de streaming. Apache Flink et Spark Streaming fournissent tous deux un traitement au moment de l'événement avec des filigranes configurables : un filigrane définit l'heure à laquelle un événement peut arriver tout en étant inclus dans sa fenêtre horaire correcte. Les événements arrivant après le filigrane sont gérés par un gestionnaire de données tardif – généralement écrits sur une sortie secondaire pour un traitement séparé ou supprimés. La valeur du filigrane est un compromis : des filigranes plus larges gèrent correctement les données plus tardives mais augmentent la latence des résultats ; les filigranes plus étroits sont plus rapides mais peuvent manquer certains événements tardifs. La définition de filigranes appropriés nécessite de comprendre les caractéristiques de latence de votre source de données.

Prochaines étapes

L'analyse en temps réel transforme les opérations commerciales de réactives en proactives, permettant ainsi aux organisations de réagir aux événements au fur et à mesure qu'ils se produisent plutôt que quelques jours après qu'ils se produisent. La pile technologique nécessaire à sa mise en œuvre est désormais accessible aux entreprises de taille moyenne désireuses d'investir dans l'architecture et la capacité opérationnelle.

Les services Power BI et d'analyse d'ECOSIRE couvrent l'ensemble du spectre, depuis les tableaux de bord accessibles en temps réel jusqu'à la conception d'architecture de streaming d'entreprise en passant par les ensembles de données de streaming Power BI. Notre équipe peut vous aider à identifier les cas d'utilisation de l'analyse en temps réel à plus forte valeur ajoutée pour votre entreprise et à mettre en œuvre la bonne architecture, du simple streaming Power BI aux déploiements Kafka + Flink d'entreprise.

Contactez notre équipe d'analyse pour discuter de vos besoins en matière d'analyse en temps réel et concevoir la bonne approche de mise en œuvre.

Real-Time Analytics: Processing Streaming Data for Instant Insights