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 · 5 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

Dans Kafka, un événement n’est pas automatiquement supprimé après sa lecture par un Consumer. Il peut être conservé selon une politique de rétention configurable. Cette conservation permet notamment 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 assure donc à la fois le transport et la conservation des événements.

7. Les APIs de Kafka

Kafka fournit plusieurs APIs pour interagir avec la plateforme :

API	ROLE
Producer API	Publier des évenements dans Kafka.
Consumer API	Lire et traiter les évenements.
Admin API	Administrer les ressources Kafka.
Kafka Streams API	Traiter et transformer les flux d'évenements.
Kafka Connect API	Connecter Kafka a des systemes externes.

Kafka Connect est notamment utile lorsqu’un système externe doit échanger des données avec Kafka par l’intermédiaire d’un connecteur.

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 producteurs et consommateurs :

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é comprenant Thanos, Grafana et Alertmanager, une étude spécifique permettra d’identifier les données échangées, les rôles de Producer et de Consumer, les topics nécessaires ainsi que les éventuels connecteurs, API REST ou services intermédiaires.

Figure 4 – Illustration conceptuelle des interactions à étudier entre Kafka et les composants d’observabilité.

9. Conclusion

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

Son fonctionnement repose sur plusieurs concepts essentiels : Producers, Consumers, topics, partitions et brokers. La réplication contribue à la tolérance aux pannes, tandis que les politiques de rétention permettent de conserver et de relire les événements.

Cette découverte constitue une première étape avant l’étude de l’intégration de Kafka avec Thanos, Grafana et Alertmanager, afin de déterminer précisément les flux de données et les mécanismes d’intégration nécessaires.