Blog / General

IREX - Apache Kafka : comprendre le streaming d’événements et son fonctionnement

Découvrez Apache Kafka, ses concepts fondamentaux et son rôle dans le streaming d’événements, ainsi que son utilisation dans une architecture d’observabilité.

August 31, 2026 · 6 min read

SOMMAIRE :
1. Introduction
2. Apache Kafka et le streaming d’événements
3. Comment circule un événement dans Kafka ?
4. Topics et partitions : comment Kafka organise les événements
5.Brokers, réplication et tolérance aux pannes
6. Conservation et relecture des événements
7. Les APIs de Kafka
8. Kafka dans une architecture orientée événements
9. Conclusion
10. Voir aussi

1. Introduction

Les systèmes informatiques modernes sont constitués de nombreuses applications et services qui doivent continuellement échanger des informations. Lorsque ces composants communiquent directement entre eux, les dépendances peuvent rapidement se multiplier et complexifier l’architecture.

Apache Kafka apporte une approche différente en permettant aux applications d’échanger des informations sous forme d’événements. Les systèmes producteurs publient leurs événements dans Kafka, tandis que les systèmes intéressés peuvent les récupérer indépendamment.

Cet article présente les concepts fondamentaux d’Apache Kafka afin de comprendre son fonctionnement et de préparer l’étude de son intégration avec des composants d’observabilité tels que Thanos, Grafana et Alertmanager.

2. Apache Kafka et le streaming d’événements

Apache Kafka est une plateforme distribuée de streaming d’événements (event streaming).

Un événement représente un fait qui s’est produit dans un système : création ou modification d’une donnée, réception d’une métrique, déclenchement d’une alerte ou action réalisée par un utilisateur. Le streaming d’événements permet notamment de :

capturer les événements lorsqu’ils sont produits;
les transporter entre différents systèmes;
les stocker durablement ;
les traiter immédiatement ou ultérieurement ;
les transmettre aux applications intéressées.

Kafka peut ainsi jouer le rôle de bus d’événements central. Un service publie ses événements dans Kafka et les applications intéressées peuvent ensuite les récupérer sans communiquer directement avec lui.

Cette organisation réduit les dépendances entre les composants et facilite l’évolution de l’architecture.

3.Comment circule un événement dans Kafka ?

Le fonctionnement de Kafka repose principalement sur deux types de clients:

les Producers
les Consumers.

Un Producer est une application qui produit et publie des événements dans Kafka. Un Consumer est une application qui s’abonne à un ou plusieurs flux afin de lire et de traiter les événements qui l’intéressent.

Le principe général est donc :

Producer → Kafka → Consumer

Producer et Consumer sont découplés : ils n’ont pas besoin de communiquer directement entre eux.

Un événement Kafka contient généralement plusieurs informations:

Key (clé) : permet notamment d’identifier ou de regrouper certains événements ;
Value(valeur) : contient les données principales de l’événement ;
Timestamp (horodatage) : représente le moment associé à l’événement ;
Headers (en-têtes) : permettent d’ajouter des métadonnées complémentaires.

Par exemple, dans un système de supervision, un événement pourrait représenter une mesure d’utilisation du processeur d’un serveur :

Key = server-01
Cpu_usage = 92

Timestamp : 2026-08-19 10:30:00 Une fois publié, cet événement devient disponible dans Kafka pour les Consumers intéressés.

4.Topics et partitions : comment Kafka organise les événements

Les événements ne sont pas stockés de manière désorganisée dans Kafka. Ils sont regroupés dans des canaux logiques appelés topics. Un topic correspond généralement à une catégorie d’événements. Dans une architecture de supervision, on pourrait par exemple rencontrer des topics tels que :

metrics ;
alerts ;
events

Un Producer choisit le topic dans lequel il publie son événement. Les Consumers peuvent ensuite s’abonner aux topics qui les intéressent. Plusieurs Producers peuvent publier dans un même topic et plusieurs Consumers peuvent exploiter les événements qui y sont disponibles. Pour améliorer les performances et permettre le traitement parallèle des données, un topic peut être divisé en plusieurs partitions.

Un principe important doit cependant être retenu : Kafka garantit l’ordre des événements à l’intérieur d’une même partition. Il n’existe pas nécessairement d’ordre global entre les événements placés dans différentes partitions. La clé d’un événement peut notamment être utilisée pour déterminer sa partition, ce qui permet de conserver certains événements liés dans la même partition.

5. Brokers, réplication et tolérance aux pannes

Kafka est conçu pour fonctionner comme un système distribué. Un serveur Kafka est appelé un broker. Plusieurs brokers peuvent fonctionner ensemble pour former un cluster Kafka. Les partitions des différents topics sont réparties entre les brokers du cluster. Cette distribution permet notamment de répartir le stockage et la charge de traitement entre plusieurs serveurs.

Kafka utilise également un mécanisme de réplication. Une partition peut disposer de copies sur plusieurs brokers. Ainsi, si un serveur devient indisponible, une copie présente sur un autre broker peut contribuer à maintenir l’accès aux données et la continuité du service.

Figure 3 – Distribution et réplication des partitions dans un cluster Kafka.

6.Conservation et relecture des événements

Une caractéristique importante de Kafka est la manière dont les événements sont conservés. La lecture d’un événement par un Consumer ne provoque pas automatiquement sa suppression. Les événements peuvent rester stockés dans Kafka selon une politique de rétention configurable. Cette caractéristique permet à plusieurs Consumers d’exploiter les mêmes événements indépendamment. Elle permet également de :

relire des événements déjà consommés ;
retraiter d’anciennes données ;
reprendre certains traitements après une interruption ;
permettre à une nouvelle application d’exploiter des événements antérieurs.

Kafka ne constitue donc pas uniquement un mécanisme de transmission entre deux applications. Il fournit également un mécanisme de stockage durable et de relecture des événements. Cette capacité distingue notamment Kafka de certains modèles de messagerie dans lesquels un message est supprimé après sa consommation.

7. Les APIs de Kafka

Apache Kafka propose différentes APIs permettant aux applications d’interagir avec la plateforme. Producer API La Producer API permet aux applications de publier des événements dans les topics Kafka. Elle constitue donc l’interface utilisée du côté des systèmes qui produisent les données. Consumer API La Consumer API permet aux applications de s’abonner aux topics et de lire les événements qui y sont publiés. Elle est utilisée par les systèmes qui doivent récupérer et traiter les données provenant de Kafka. Admin API L’Admin API permet d’effectuer différentes opérations d’administration, notamment sur les topics et certaines configurations du cluster. Kafka Streams API La Kafka Streams API permet de développer des applications capables de traiter des flux d’événements. Elle peut notamment servir à filtrer, transformer, agréger ou combiner des données circulant dans Kafka. Kafka Connect API Kafka Connect facilite l’intégration de Kafka avec des systèmes externes grâce à l’utilisation de connecteurs. Le principe général peut être représenté ainsi : Système externe ↔ Connecteur ↔ Kafka Cette possibilité est particulièrement intéressante lorsqu’une application existante ne communique pas directement avec Kafka et nécessite un mécanisme intermédiaire pour produire ou consommer des événements.

8. Kafka dans une architecture orientée événements

Dans une architecture orientée événements, Kafka sert d’intermédiaire entre les systèmes qui produisent des données et ceux qui les consomment : Source → Producer → Kafka → Consumer → Système cible Cette approche permet aux différents composants d’échanger des informations tout en restant découplés.

Dans une architecture d’observabilité intégrant Thanos, Grafana et Alertmanager, une étude spécifique est nécessaire afin d’identifier les données échangées, les rôles de Producer et de Consumer, les topics à utiliser ainsi que les éventuels connecteurs, API REST ou services intermédiaires.

Figure 4.

9. Conclusion

Apache Kafka est une plateforme distribuée de streaming d’événements permettant de transporter, stocker et distribuer des données entre différents systèmes.

Son fonctionnement repose sur plusieurs concepts complémentaires : les Producers publient des événements, les Consumers les lisent, les topics permettent de les organiser, les partitions facilitent leur distribution et leur traitement parallèle, tandis que les brokers assurent leur stockage au sein d’un cluster.

La réplication améliore la disponibilité et la tolérance aux pannes, tandis que les politiques de rétention permettent de conserver et de relire les événements même après leur consommation. Kafka fournit également différentes APIs pour produire, consommer, administrer, traiter et connecter les flux d’événements à des systèmes externes.

La compréhension de ces mécanismes constitue une première étape avant l’étude de l’intégration de Kafka avec Thanos, Grafana et Alertmanager. Cette prochaine analyse permettra d’identifier précisément les flux de données, les Producers, les Consumers, les topics et les composants intermédiaires nécessaires.