Découvrez Apache Kafka : topics et partitions, stockage et rejouement d'événements, et comment Kafka s'intègre aux systèmes modernes pour événements temps réel, logs et pipelines de données.
Apache Kafka est une plateforme distribuée de streaming d'événements. En termes simples, c'est un « tuyau » partagé et durable qui permet à de nombreux systèmes de publier des faits sur ce qui s'est passé et à d'autres systèmes de lire ces faits — rapidement, à grande échelle et dans l'ordre.
Les équipes utilisent Kafka lorsque les données doivent circuler fiablement entre des systèmes sans couplage fort. Plutôt qu'une application n'appelle une autre directement (et échoue si elle est en panne ou lente), les producteurs écrivent des événements dans Kafka. Les consommateurs les lisent quand ils sont prêts. Kafka stocke les événements pour une durée configurable, de sorte que les systèmes peuvent se remettre des pannes et même retraiter l'historique.
Ce guide s'adresse aux ingénieurs orientés produit, aux équipes données et aux responsables techniques qui veulent un modèle mental pratique de Kafka.
Vous apprendrez les blocs de construction essentiels (producteurs, consommateurs, topics, brokers), comment Kafka scale avec les partitions, comment il stocke et rejoue les événements, et où il s'insère dans une architecture pilotée par événements. Nous couvrirons aussi les cas d'usage courants, les garanties de livraison, les bases de la sécurité, la planification opérationnelle et quand Kafka est (ou n'est pas) l'outil adapté.
Kafka se comprend le plus facilement comme un log d'événements partagé : des applications y écrivent des événements, et d'autres applications les lisent plus tard — souvent en temps réel, parfois des heures ou des jours plus tard.
Producteurs = les écrivains. Un producteur peut publier un événement comme « commande passée », « paiement confirmé » ou « relevé de température ». Les producteurs n'envoient pas les événements directement à des applications spécifiques — ils les envoient à Kafka.
Consommateurs = les lecteurs. Un consommateur peut alimenter un tableau de bord, déclencher un workflow d'expédition ou charger des données dans l'analytics. Les consommateurs décident quoi faire des événements et peuvent lire à leur propre rythme.
Les événements dans Kafka sont regroupés en topics, qui sont essentiellement des catégories nommées. Par exemple :
orders pour les événements liés aux commandespayments pour les événements de paiementinventory pour les changements de stockUn topic devient le flux « source de vérité » pour ce type d'événement, ce qui facilite la réutilisation des mêmes données par plusieurs équipes sans créer des intégrations ad hoc.
Un broker est un serveur Kafka qui stocke les événements et les sert aux consommateurs. En pratique, Kafka fonctionne comme un cluster (plusieurs brokers collaborant) pour gérer plus de trafic et continuer à fonctionner même si une machine tombe en panne.
Les consommateurs s'exécutent souvent dans un groupe de consommateurs. Kafka répartit la lecture entre les membres du groupe, de sorte que vous pouvez ajouter des instances consommantes pour scaler le traitement — sans que chaque instance fasse le même travail.
Kafka scale en divisant le travail en topics (flux d'événements liés) puis en scindant chaque topic en partitions (tranches plus petites et indépendantes de ce flux).
Un topic avec une seule partition ne peut être lu que par un seul consommateur à la fois au sein d'un groupe de consommateurs. Ajoutez des partitions, et vous pouvez ajouter des consommateurs pour traiter les événements en parallèle. C'est ainsi que Kafka supporte des débits élevés pour le streaming d'événements et les pipelines de données temps réel sans transformer chaque système en goulot d'étranglement.
Les partitions aident aussi à répartir la charge sur plusieurs brokers. Plutôt qu'une seule machine qui gère toutes les écritures et lectures d'un topic, plusieurs brokers peuvent héberger différentes partitions et partager le trafic.
Kafka garantit l'ordre au sein d'une même partition. Si les événements A, B et C sont écrits dans cet ordre dans une partition, les consommateurs les liront A → B → C.
L'ordre entre partitions n'est pas garanti. Si vous avez besoin d'un ordre strict pour une entité spécifique (comme un client ou une commande), vous devez généralement faire en sorte que tous les événements de cette entité aillent dans la même partition.
Lorsque les producteurs envoient un événement, ils peuvent inclure une clé (par exemple order_id). Kafka utilise la clé pour router de manière cohérente les événements liés vers la même partition. Cela vous donne un ordre prévisible pour cette clé tout en permettant au topic de se répartir sur de nombreuses partitions.
Chaque partition peut être répliquée sur d'autres brokers. Si un broker tombe, un autre broker ayant une réplique peut prendre le relais. La réplication est une des raisons pour lesquelles Kafka est adopté pour la messagerie pub-sub critique : elle améliore la disponibilité et la tolérance aux pannes sans que chaque application doive implémenter sa propre logique de basculement.
Une idée clé dans Apache Kafka est que les événements ne sont pas juste transmis puis oubliés. Ils sont écrits sur disque dans un log ordonné, de sorte que les consommateurs peuvent les lire maintenant — ou plus tard. Cela rend Kafka utile non seulement pour déplacer des données, mais aussi pour garder un historique durable de ce qui s'est passé.
Quand un producteur envoie un événement à un topic, Kafka l'ajoute au stockage du broker. Les consommateurs lisent ensuite ce log stocké à leur propre rythme. Si un consommateur est hors ligne pendant une heure, les événements existent toujours et peuvent être traités lors de sa reprise.
Kafka conserve les événements selon des politiques de rétention :
La rétention se configure par topic, ce qui permet de traiter différemment les topics « piste d'audit » des topics de télémétrie très volumineux.
Certains topics ressemblent plus à un changelog qu'à une archive historique — par exemple, « paramètres clients courants ». La compaction de log conserve au moins le dernier événement pour chaque clé, tandis que les anciens enregistrements peut-être remplacés. Vous obtenez ainsi une source de vérité durable pour l'état le plus récent, sans une croissance non maîtrisée.
Parce que les événements restent stockés, vous pouvez les rejouer pour reconstruire l'état :
En pratique, le rejouement est contrôlé par le point de départ d'un consommateur (son offset), donnant aux équipes un filet de sécurité puissant lors de l'évolution des systèmes.
Kafka est conçu pour maintenir le flux de données même lorsque certaines parties du système tombent en panne. Il y parvient grâce à la réplication, des règles claires sur qui est « en charge » d'une partition, et des accusés de réception configurables.
Chaque partition de topic a un broker leader et un ou plusieurs followers répliques sur d'autres brokers. Les producteurs et consommateurs s'adressent au leader de la partition.
Les followers copient continuellement les données du leader. Si le leader tombe, Kafka peut promouvoir un follower à jour en tant que nouveau leader, de sorte que la partition reste disponible.
Si un broker échoue, les partitions dont il était leader deviennent indisponibles momentanément. Le contrôleur de Kafka détecte la panne et déclenche une élection de leader pour ces partitions.
Si au moins un follower répliqué est suffisamment à jour, il peut prendre la relève et les clients reprennent la production/consommation. Si aucune réplique en-synchro n'est disponible, Kafka peut suspendre les écritures (selon la configuration) pour éviter de perdre des données déjà reconnues.
Deux réglages principaux influencent la durabilité :
Conceptuellement :
Pour réduire les duplications lors des réessais, on combine souvent des acks plus sûrs avec des producteurs idempotents et une gestion robuste côté consommateur.
Plus de sécurité implique généralement d'attendre davantage de confirmations et de maintenir davantage de réplicas en synchro, ce qui peut ajouter de la latence et réduire le débit maximal.
Des réglages plus permissifs conviennent pour la télémétrie ou le clickstream où une perte occasionnelle est acceptable, alors que les paiements, l'inventaire et les logs d'audit justifient souvent une sécurité accrue.
L'architecture pilotée par événements (EDA) consiste à concevoir des systèmes où les faits métier — une commande passée, un paiement confirmé, un colis expédié — sont représentés par des événements que d'autres parties du système peuvent consommer et auxquels elles peuvent réagir.
Kafka se place souvent au centre d'une EDA comme le « flux d'événements » partagé. Plutôt que le Service A n'appelle le Service B directement, le Service A publie un événement (par ex. OrderCreated) dans un topic Kafka. N'importe quel nombre d'autres services peuvent consommer cet événement et agir — envoyer un email, réserver du stock, lancer des contrôles anti-fraude — sans que le producteur ait à les connaître.
Parce que les services communiquent via des événements, ils n'ont pas à coordonner des APIs request/response pour chaque interaction. Cela réduit le couplage entre équipes et facilite l'ajout de fonctionnalités : vous pouvez introduire un nouveau consommateur pour un événement existant sans changer le producteur.
L'EDA est naturellement asynchrone : les producteurs écrivent rapidement et les consommateurs traitent à leur rythme. Lors de pics de trafic, Kafka aide à tamponner la surcharge pour que les systèmes en aval ne tombent pas immédiatement. Les consommateurs peuvent monter en charge pour rattraper le retard, et si un consommateur tombe temporairement, il reprend depuis où il s'était arrêté.
Considérez Kafka comme le « fil d'activité » du système. Les producteurs publient des faits ; les consommateurs s'abonnent aux faits qui les intéressent. Ce modèle permet des pipelines de données temps réel et des workflows pilotés par événements tout en gardant les services plus simples et indépendants.
Kafka apparaît lorsque les équipes doivent déplacer beaucoup de petits « faits qui sont arrivés » (événements) entre systèmes — rapidement, de manière fiable et de façon réutilisable par plusieurs consommateurs.
Les applications ont souvent besoin d'un historique append-only : connexions utilisateurs, changements de permissions, mises à jour d'enregistrements ou actions admin. Kafka fonctionne bien comme flux central pour ces événements, afin que les outils de sécurité, le reporting et les exports de conformité lisent la même source sans surcharger la base de production. Comme les événements sont conservés, on peut aussi les rejouer pour reconstruire une vue d'audit après un bug ou un changement de schéma.
Plutôt que des appels directs, les services peuvent publier des événements comme « order created » ou « payment received ». D'autres services s'abonnent et réagissent à leur rythme. Cela réduit le couplage fort, aide à la résilience lors de pannes partielles et facilite l'ajout de capacités (par ex. contrôles anti-fraude) simplement en consommant le flux existant.
Kafka est souvent l'épine dorsale pour déplacer les données des systèmes opérationnels vers des plateformes analytiques. Les équipes peuvent streamer les changements depuis des bases applicatives et les livrer dans un entrepôt ou un lac avec une faible latence, en séparant les requêtes analytiques lourdes de l'application de production.
Capteurs, appareils et télémétrie arrivent souvent en rafales. Kafka peut absorber ces pics, les tamponner en sécurité et laisser le traitement en aval rattraper le retard — utile pour la supervision, l'alerte et l'analyse à long terme.
Kafka n'est pas que des brokers et des topics. La plupart des équipes s'appuient sur des outils complémentaires qui rendent Kafka pratique pour le déplacement quotidien de données, le traitement de flux et les opérations.
Kafka Connect est le framework d'intégration de Kafka pour faire entrer des données dans Kafka (sources) et hors de Kafka (sinks). Plutôt que de développer et maintenir des pipelines sur mesure, on exécute Connect et on configure des connecteurs.
Exemples courants : extraire des changements depuis des bases, ingérer des événements SaaS ou livrer des données Kafka vers un entrepôt ou un stockage objet. Connect standardise aussi les préoccupations opérationnelles comme les réessais, les offsets et le parallélisme.
Si Connect sert l'intégration, Kafka Streams sert le calcul. C'est une bibliothèque que vous ajoutez à votre application pour transformer des flux en temps réel — filtrer, enrichir, joindre des flux et construire des agrégats (par ex. « commandes par minute »).
Les applications Streams lisent des topics et écrivent dans des topics, s'intégrant naturellement aux systèmes pilotés par événements et pouvant monter en charge en ajoutant des instances.
Quand plusieurs équipes publient des événements, la cohérence importe. La gestion des schémas (souvent via un schema registry) définit quels champs un événement doit contenir et comment ils évoluent. Cela évite des ruptures comme la renommée d'un champ dont dépend un consommateur.
Kafka est sensible opérationnellement, donc la surveillance de base est essentielle :
La plupart des équipes utilisent aussi des UIs de gestion et de l'automatisation pour les déploiements, la configuration des topics et les politiques d'accès (voir /blog/kafka-security-governance).
Kafka se décrit souvent comme « log durable + consommateurs », mais ce qui importe vraiment aux équipes est : vais-je traiter chaque événement une fois, et que se passe-t-il en cas d'échec ? Kafka fournit les blocs de construction ; c'est à vous de choisir les compromis.
Au plus une fois : vous pouvez perdre des événements, mais vous ne traiterez pas de doublons. Cela se produit si un consommateur commit son offset puis tombe en panne avant d'avoir fini le travail.
Au moins une fois : vous ne perdrez pas d'événements, mais des duplications sont possibles (par ex. le consommateur traite un événement, plante, puis le retraitera au redémarrage). C'est le modèle par défaut le plus courant.
Exactement une fois vise à éviter à la fois la perte et les doublons de bout en bout. Dans Kafka, cela implique typiquement des producteurs transactionnels et un traitement compatible (souvent via Kafka Streams). C'est puissant, mais plus contraint et nécessite une configuration soignée.
En pratique, beaucoup de systèmes adoptent l'au-moins-une-fois et ajoutent des protections :
Un offset est la position du dernier enregistrement traité dans une partition. Quand vous committez un offset, vous dites « j'ai fini jusqu'ici ». Committer trop tôt risque des pertes ; trop tard augmente les duplications après panne.
Les réessais doivent être bornés et visibles. Un schéma courant :
Cela empêche qu'un message poison bloque un groupe entier tout en préservant les données pour correction ultérieure.
Kafka transporte souvent des événements critiques (commandes, paiements, activité utilisateur). La sécurité et la gouvernance doivent faire partie de la conception, pas être ajoutées après.
L'authentification répond à « qui êtes-vous ? » L'autorisation répond à « que pouvez-vous faire ? » Dans Kafka, l'authentification se fait couramment avec SASL (ex. SCRAM ou Kerberos), et l'autorisation via des ACLs au niveau des topics, groupes de consommateurs et du cluster.
Un modèle pratique : moindre privilège — les producteurs écrivent uniquement dans leurs topics, et les consommateurs lisent seulement les topics nécessaires. Cela réduit l'exposition accidentelle des données et limite la surface d'attaque si des identifiants sont compromis.
TLS chiffre les données entre les applications, les brokers et les outils. Sans TLS, les événements peuvent être interceptés sur les réseaux internes comme sur Internet. TLS permet aussi de valider l'identité des brokers et d'éviter les attaques de type « man-in-the-middle ».
Quand plusieurs équipes partagent un cluster, des garde-fous sont nécessaires. Des conventions claires de nommage de topics (par ex. <equipe>.<domaine>.<evenement>.<version>) rendent la propriété évidente et aident les outils à appliquer des politiques.
Associez le nommage à des quotas et à des modèles d'ACL afin qu'une charge bruyante ne prive pas les autres ressources, et que les nouveaux services démarrent avec des paramètres sûrs.
Considérez Kafka comme un système d'archive d'événements seulement si c'est intentionnel. Si les événements contiennent des données personnelles identifiables (PII), appliquez la minimisation des données (envoyer des identifiants plutôt que des profils complets), envisagez le chiffrement au niveau des champs et documentez quels topics sont sensibles.
Les réglages de rétention doivent correspondre aux exigences légales et métier. Si la politique exige « suppression après 30 jours », ne conservez pas 6 mois d'événements « au cas où ». Des revues et audits réguliers maintiennent la configuration alignée à mesure que le système évolue.
Déployer Apache Kafka n'est pas un processus « installer et oublier ». Il fonctionne comme un service partagé : de nombreuses équipes en dépendent, et de petites erreurs peuvent impacter massivement les consommateurs.
La capacité Kafka est surtout un problème mathématique à réévaluer régulièrement. Les leviers principaux sont les partitions (parallélisme), le débit (Mo/s entrant et sortant) et la croissance du stockage (durée de rétention).
Si le trafic double, vous devrez peut-être ajouter des partitions pour répartir la charge, plus de disque pour la rétention et davantage de bande passante pour la réplication. Une bonne habitude est de prévoir le débit d'écriture maximal et de le multiplier par la rétention pour estimer la croissance du disque, puis d'ajouter une marge pour la réplication et le « succès inattendu ».
Attendez-vous à du travail de routine au-delà du maintien des serveurs :
Les coûts sont portés par les disques, la sortie réseau et le nombre/taille des brokers. Un Kafka managé réduit la charge d'exploitation et simplifie les mises à jour, tandis que l'auto-hébergement peut être moins coûteux à grande échelle si vous avez des opérateurs expérimentés. Le compromis porte sur le temps de reprise et la charge d'astreinte.
Les équipes surveillent typiquement :
De bons tableaux de bord et des alertes transforment Kafka d'une « boîte noire » en un service compréhensible.
Kafka convient bien quand vous devez déplacer beaucoup d'événements de façon fiable, les conserver un temps et permettre à plusieurs systèmes de réagir au même flux à leur rythme. Il est particulièrement utile lorsque les données doivent être rejouables (backfills, audits, reconstruction d'un service) et lorsque vous attendez l'ajout progressif de producteurs/consommateurs.
Kafka est efficace quand vous avez :
Kafka peut être excessif si vos besoins sont simples :
Dans ces cas, le surcoût opérationnel (dimensionnement du cluster, mises à jour, monitoring, astreinte) peut dépasser les bénéfices.
Kafka complète — il ne remplace pas — les bases de données (système de référence), les caches (lectures rapides) et les outils ETL batch (transformations périodiques importantes).
Posez-vous :
Si vous répondez « oui » à la plupart, Kafka est en général un bon choix.
Kafka s'intègre le mieux quand vous avez besoin d'une « source de vérité » partagée pour des flux d'événements temps réel : de nombreux producteurs publiant des faits (commande créée, paiement autorisé, stock modifié) et de nombreux consommateurs utilisant ces faits pour alimenter des pipelines, de l'analytics et des fonctionnalités réactives.
Commencez par un flux étroit et à forte valeur — par exemple publier des événements « OrderPlaced » pour les services aval (email, anti-fraude, fulfillment). Évitez de transformer Kafka en une file universelle dès le premier jour.
Rédigez :
Gardez les schémas initiaux simples et cohérents (timestamps, IDs, nom d'événement clair). Décidez si vous appliquerez des schémas dès le départ ou si vous les ferez évoluer prudemment.
Kafka réussit quand quelqu'un est responsable de :
Ajoutez la surveillance immédiatement (lag des consommateurs, santé des brokers, débit, taux d'erreurs). Si vous n'avez pas d'équipe plateforme, commencez par une offre managée et des limites claires.
Produisez des événements depuis un système, consommez-les en un endroit et validez la boucle de bout en bout. Ensuite, étendez aux autres consommateurs, partitions et intégrations.
Si vous voulez prototyper rapidement l'application autour de Kafka (UI React, backend Go, PostgreSQL), des outils comme Koder.ai peuvent aider à générer l'application et ajouter des producteurs/consommateurs via un flux guidé. Ils sont utiles pour construire des tableaux de bord internes et des services légers qui consomment des topics, avec des fonctionnalités de mode planning, export de code, déploiement et snapshots avec rollback.
Si vous cartographiez cela dans une approche pilotée par événements, voyez /blog/event-driven-architecture. Pour estimer les coûts et les environnements, consultez /pricing.
Kafka est une plateforme distribuée de streaming d'événements qui stocke les événements dans des logs durables en append-only.
Les producteurs écrivent des événements dans des topics, et les consommateurs les lisent de manière indépendante (souvent en temps réel, mais aussi plus tard) parce que Kafka conserve les données pendant une période configurée.
Utilisez Kafka quand plusieurs systèmes ont besoin du même flux d'événements, que vous voulez un couplage lâche et que vous pourriez avoir besoin de rejouer l'historique.
C'est particulièrement adapté à :
Un topic est une catégorie nommée d'événements (comme orders ou payments).
Une partition est une tranche d'un topic qui permet :
Kafka garantit l'ordre uniquement à l'intérieur d'une même partition.
Kafka utilise la clé de l'enregistrement (par exemple order_id) pour router de façon cohérente des événements liés vers la même partition.
Règle pratique : si vous avez besoin d'un ordre par entité (tous les événements d'une commande/client dans l'ordre), choisissez une clé représentant cette entité pour que ces événements atterrissent dans une seule partition.
Un groupe de consommateurs est un ensemble d'instances de consommateurs qui se partagent le travail pour un topic.
Dans un groupe :
Si deux applications différentes doivent recevoir chaque événement, elles doivent utiliser des groupes de consommateurs différents.
Kafka conserve les événements sur disque selon des politiques de rétention, permettant aux consommateurs de rattraper leur retard ou de retraiter l'historique.
Types de rétention courants :
La rétention se configure par topic, pour traiter différemment un stream d'audit d'un flux de télémétrie très volumineux.
La compaction du log conserve au moins la dernière valeur pour chaque clé, en supprimant au fil du temps les enregistrements remplacés.
Elle est utile pour des flux de « dernier état » (paramètres courants, profils) où l'on tient à la valeur la plus récente par clé plutôt qu'à chaque changement historique—tout en gardant une source de vérité durable pour l'état actuel.
Le modèle le plus courant en bout-en-bout avec Kafka est « au moins une fois » : vous ne perdez pas les événements, mais des doublons peuvent survenir.
Pour gérer cela :
Les offsets sont le « marque-page » d'un consommateur par partition.
Committer trop tôt peut faire perdre du travail en cas de crash ; committer trop tard augmente les doublons après redémarrage.
Un schéma opérationnel courant : réessais bornés avec backoff, puis publication de l'enregistrement en échec dans un topic de dead-letter pour inspection et rejouement. Cela empêche qu'un message « poison » bloque tout le groupe de consommateurs.
Kafka Connect déplace les données depuis/vers Kafka via des connecteurs (sources et sinks) sans écrire du code de pipeline sur mesure.
Kafka Streams est une bibliothèque pour transformer et agréger des flux en temps réel au sein de vos applications (filtrer, joindre, enrichir, agréger), lisant depuis des topics et écrivant des résultats vers des topics.
Connect sert typiquement à l'intégration ; Streams sert au calcul.