Batch ou streaming : la décision qui pèse le plus sur l’architecture de données
Avant de concevoir une architecture de données, il faut répondre à une question fondamentale : à quelle fréquence les données doivent-elles être mises à jour pour être utiles ? La réponse détermine si l’architecture doit être en batch (traitement périodique) ou en streaming (traitement continu en temps réel).
Le traitement par lots (batch) applique des transformations à un ensemble de données accumulées à intervalles définis : chaque nuit, chaque heure, chaque semaine. Il est simple, prévisible et économique. Pour la plupart des rapports de gestion, la comptabilité et les analyses historiques, le batch est le bon choix.
Le traitement en streaming traite chaque événement au moment où il se produit et met à jour les systèmes en aval avec des latences de quelques millisecondes à quelques secondes. Il est plus complexe et plus coûteux, mais pour certains cas d’usage il n’existe pas d’alternative valable.
Quand le temps réel est indispensable
Détection de fraude : un modèle qui évalue si une transaction bancaire ou un paiement par carte est frauduleux dispose de quelques secondes pour agir, pas de quelques heures. Le batch ne convient pas à ce cas d’usage.
Tarification dynamique : dans des secteurs comme le tourisme, l’énergie ou le transport, les prix optimaux varient en fonction de la demande du moment, des disponibilités et des actions de la concurrence. Une information qui arrive des heures plus tard n’est plus exploitable.
Surveillance industrielle : une usine qui détecte des anomalies sur ses capteurs doit réagir avant que le problème ne devienne une panne. Un système batch qui examine les données toutes les heures peut laisser passer le moment d’intervenir.
Tableaux de bord opérationnels en temps réel : les équipes d’exploitation des centres d’appels, de la logistique ou de la production ont besoin d’une visibilité immédiate sur l’état du système, pas d’une photo vieille de plusieurs heures.
Apache Kafka, infrastructure de streaming
Apache Kafka est le système de messagerie distribuée de référence pour les architectures de données en temps réel. Il fait office de bus d’événements qui découple les systèmes producteurs des systèmes consommateurs, ce qui permet à plusieurs applications de traiter les mêmes événements de façon indépendante et dans le bon ordre.
Plusieurs caractéristiques en font le choix standard du secteur : haute disponibilité et tolérance aux pannes, durée de rétention des messages configurable (les consommateurs peuvent relire des événements passés), débit extrêmement élevé (des millions d’événements par seconde sur des clusters bien configurés) et un écosystème mature de connecteurs vers pratiquement tous les systèmes de données.
Alternatives managées : Confluent Cloud (Kafka managé), Amazon Kinesis, Azure Event Hubs et Google Pub/Sub sont des alternatives cloud qui allègent la charge d’exploitation d’un cluster Kafka propre.
Architectures de référence pour le streaming
Architecture lambda : elle maintient deux couches parallèles, une couche batch pour l’historique complet et une couche de vitesse (speed layer) pour les données les plus récentes en temps réel. Les deux couches sont interrogées de façon unifiée. Elle garantit la cohérence mais oblige à dupliquer la logique de traitement.
Architecture kappa : elle réunit batch et streaming dans un pipeline de streaming unique, en traitant l’historique comme un flux très long. Plus simple à maintenir, elle est plus exigeante en capacité de flux.
Streaming moderne avec un lakehouse : les plateformes lakehouse actuelles (Databricks, Microsoft Fabric) permettent d’ingérer des flux Kafka directement dans des tables Delta Lake avec des garanties ACID, ce qui simplifie l’architecture et supprime la séparation entre batch et streaming.
Quand le temps réel est superflu
Tout n’a pas besoin de temps réel. Mettre en place du streaming là où le batch suffit ajoute de la complexité, des coûts et des risques sans bénéfice réel. Si la direction financière a besoin d’un rapport de ventes mensuel consolidé, le traiter en temps réel n’apporte rien. La décision doit toujours partir du cas d’usage métier et de la latence dont il a réellement besoin, et non de la technologie la plus avancée disponible.
Chez AIRES, nous évaluons les besoins réels de latence de chaque cas d’usage avant de proposer une architecture de streaming, afin d’éviter toute complexité inutile.
Questions fréquentes
Combien coûte une architecture de streaming par rapport au batch ? Une architecture de streaming bien conçue peut coûter plusieurs fois plus cher que son équivalent en batch, si l’on tient compte de l’infrastructure, de la complexité de développement et de la maintenance. Ce coût ne se justifie que si le cas d’usage a de réelles exigences de faible latence. L’évaluation doit comparer le coût de l’architecture à la valeur métier de la latence réduite.
Kafka est-il difficile à administrer ? Un cluster Kafka sur site présente une complexité d’exploitation importante : configuration des partitions, réplication, rétention, suivi du retard des consommateurs (consumer lag). Les versions managées dans le cloud (Confluent Cloud, Amazon MSK, Azure Event Hubs) suppriment une grande partie de cette complexité, en contrepartie d’un coût plus élevé. Pour la plupart des entreprises, commencer par une solution managée est la bonne décision.
Peut-on combiner le streaming avec les modèles d’IA existants ? Oui, et c’est l’un des cas d’usage les plus intéressants. Un modèle de ML entraîné hors ligne peut fournir des prédictions en temps réel s’il est intégré au pipeline de streaming : chaque événement (transaction, signal de capteur, visite web) est envoyé au modèle pour inférence, et le résultat est republié dans le flux. Cette architecture est à la base des systèmes de recommandation en temps réel, de la détection de fraude et des alertes prédictives.