Confluent Cloud ou Kafka auto-hébergé : grille de décision 2026

Le choix entre Confluent Cloud et un cluster Kafka auto-hébergé n’est pas qu’une question de prix mensuel. Il engage la responsabilité opérationnelle de l’équipe, la souveraineté des données, la flexibilité de configuration, et la trajectoire de croissance sur trois à cinq ans. En 2026, avec Confluent Platform 8.2 alignée sur Apache Kafka 4.2 et une offre Cloud qui couvre désormais toutes les régions européennes majeures, le compromis se dessine clairement selon trois axes : le volume de trafic, le profil d’équipe, et les contraintes réglementaires. Ce tutoriel détaille pas à pas une procédure d’évaluation rigoureuse pour choisir, prototyper et chiffrer chaque option.

L’approche n’est pas un comparatif idéologique mais un exercice de décision : on définit les critères, on collecte les données, on simule trois scénarios de charge, on évalue les coûts totaux, on arbitre. À la fin, vous saurez pour votre cas précis ce qui est le plus pertinent.

Prérequis

• Une compréhension générale de Kafka et de ses composants (broker, topic, producer, consumer)
• Accès à une carte bancaire ou un compte d’entreprise pour ouvrir un compte Confluent Cloud d’essai (400 USD de crédits offerts les 30 premiers jours)
• Si l’option auto-hébergée vous intéresse, un compte VPS chez Hetzner, OVH ou Liquid IT
• Temps estimé : 2 heures pour l’évaluation complète

Étape 1 — Cartographier la charge réelle ou prévue

La toute première étape est la mesure honnête de ce que votre application va envoyer dans Kafka. Sans cette mesure, toute estimation de coût est de la fiction. Quatre métriques suffisent.

Le débit moyen en entrée en kilo-octets par seconde — c’est ce que vos producers vont publier en cumul. Le débit en sortie est généralement un multiple du débit d’entrée : si vous avez trois consumers indépendants qui lisent chaque topic, l’égress est trois fois l’ingress. Le volume cumulé conservé sur la durée de rétention — si la rétention est de sept jours et que vous écrivez 1 Mo/s en moyenne, vous stockerez environ 600 Go en régime permanent. Le nombre de partitions total à travers tous les topics, qui détermine le parallélisme de traitement.

Pour une PME ouest-africaine type — paiements mobile-money, logs applicatifs, événements e-commerce — un ordre de grandeur réaliste serait : 50 à 200 Ko/s en entrée, 200 à 600 Ko/s en sortie, 30 à 100 Go de stockage chaud, 50 à 200 partitions. Ces chiffres sont le scénario A.

Pour une scale-up qui a démarré l’event-driven sérieusement, le scénario B serait plutôt 2 à 10 Mo/s en entrée, 6 à 30 Mo/s en sortie, 500 Go à 2 To de stockage, 300 à 800 partitions.

Pour une grosse plateforme — banque digitale, opérateur télécom, plateforme logistique cross-Africain — le scénario C serait 30 à 100 Mo/s en entrée, 100 à 400 Mo/s en sortie, 5 à 30 To de stockage, 2 000 à 10 000 partitions.

Étape 2 — Calculer le coût Confluent Cloud par scénario

La grille tarifaire 2026 de Confluent Cloud repose sur quatre composantes : cluster capacity, throughput (ingress + egress par GB), storage (GB-mois), et add-ons optionnels comme les connecteurs managés. Pour les tiers Basic, Standard, Enterprise et Freight, le cluster est élastique et facturé à la consommation ; pour Dedicated, on paie des CKU provisionnés.

Au scénario A (PME), un cluster Basic suffit. Throughput facturé à 0,014–0,020 USD/Go selon la région, soit 100 Ko/s en entrée × 86400 s × 30 jours = environ 260 Go/mois × 0,02 = 5 USD pour l’ingress. L’egress à 600 Ko/s × 30 × 0,03 = environ 47 USD. Stockage à 50 Go × 0,08 = 4 USD. Total mensuel autour de 60 à 80 USD, soit 35 000 à 50 000 FCFA. Le cluster scale à zéro quand inactif, ce qui est un avantage majeur en dev/test.

Au scénario B (scale-up), on passe sur Standard. Standard scale en eCKU (modèle post-avril 2024) avec une tarification au débit, et le tarif unitaire est légèrement supérieur à Basic. 10 Mo/s en entrée × 30 jours = environ 26 To/mois × 0,03 = 780 USD pour l’ingress. Egress à 30 Mo/s × 0,05 = 3 900 USD. Stockage à 1 To × 0,05 = 50 USD. Total mensuel autour de 4 500 à 5 500 USD soit 2,7 à 3,3 millions FCFA. À ce niveau, on commence à étudier sérieusement les architectures qui minimisent l’egress (cache local, materialized views).

Au scénario C (grande plateforme), Dedicated devient obligatoire pour les SLA stricts. Confluent ne publie pas le tarif officiel par CKU/heure pour Dedicated ; les estimations tierces de référence convergent vers 6 000 à 9 000 USD par CKU et par mois selon la région et les options. Pour un cluster Dedicated de taille moyenne (par exemple 2 CKU avec multi-AZ AWS, 0,1 Go/s peak, 25 To/mois de transfert, rétention 3 jours), un breakdown documenté chiffre à environ 17 000 USD/mois. Avec storage à 30 To × 0,05 = 1 500 USD, et l’egress qui devient le poste dominant, le total mensuel d’un cluster de 10 CKU peut atteindre 60 000 à 100 000 USD selon le ratio egress/ingress, soit 36 à 60 millions FCFA mensuels. À ce stade, l’auto-hébergement devient économiquement très tentant.

Étape 3 — Calculer le coût auto-hébergé par scénario

L’auto-hébergement chez Hetzner, OVH ou Liquid IT obéit à une logique différente : on paie l’infrastructure brute, qu’on l’utilise à 10 % ou à 90 %. Trois postes : VPS, stockage object (pour le tiered storage), et bande passante.

Au scénario A, trois VPS Hetzner CX32 à 6,49 euros chacun (grille tarifaire d’avril 2026) couvrent largement le besoin : environ 20 euros par mois pour le cluster, plus 10 euros pour un MinIO co-hébergé qui gère le tiered storage. Total autour de 30 à 35 euros par mois (20 000 à 23 000 FCFA), soit nettement moins que Confluent Basic dans le même scénario. Le coût caché est le temps d’admin — comptez 4 à 8 heures par mois pour les mises à jour, la surveillance et la résolution d’incidents.

Au scénario B, on monte à un cluster de cinq nœuds CPX41 (8 vCPU, 16 Go RAM, 240 Go NVMe) à environ 39 euros chacun (grille d’avril 2026), soit autour de 195 euros par mois. Le tiered storage devient sérieux : 2 To dans MinIO ou Backblaze B2 à environ 6 USD/To-mois = 10 USD. Bande passante incluse côté Hetzner (20 To gratuit). Total mensuel autour de 210 à 240 euros par mois (140 000 à 160 000 FCFA), à comparer aux 4 500 USD Confluent. Le rapport reste très favorable à l’auto-hébergement — c’est ce différentiel qui justifie l’embauche ou la dédication d’un SRE.

Au scénario C, l’auto-hébergement demande une vraie équipe et probablement plusieurs zones géographiques. Un cluster de douze nœuds CCX33 (8 vCPU dédiés, 32 Go RAM, 240 Go NVMe) à environ 62 euros chacun (grille d’avril 2026) = autour de 750 euros par mois. Storage tiered S3 à 30 To = 150 USD. Sauvegardes cross-région = 200 USD. Total autour de 1 100 à 1 300 USD par mois pour l’infra, plus deux SRE à 500 000 FCFA/mois = environ 3 000 USD de salaire combiné. Total opérationnel autour de 4 300 USD/mois vs 60 000+ USD Confluent Dedicated équivalent — rapport favorable de 1 à 14 environ.

Étape 4 — Évaluer les coûts cachés non-monétaires

Au-delà du chiffre brut, plusieurs facteurs influencent le coût réel total. Le time-to-market : Confluent Cloud démarre en quinze minutes, un cluster auto-hébergé en deux à trois jours pour un setup propre. La charge cognitive : un broker auto-hébergé impose la maîtrise de KRaft, des metrics JMX, du tuning de la JVM, des stratégies de partition. Le recrutement : trouver un SRE Kafka expérimenté à Dakar ou Abidjan est plus difficile et plus cher que sur le marché européen.

À l’inverse, Confluent Cloud impose des contraintes que l’auto-hébergement évite. La souveraineté des données : Confluent Cloud héberge sur AWS, GCP ou Azure dans des régions définies, ce qui peut entrer en conflit avec des lois locales sur la résidence des données. L’vendor lock-in : migrer hors Confluent Cloud demande un effort substantiel, surtout si on utilise les fonctionnalités exclusives (Flink managé, Stream Designer, Tableflow). Les coûts marginaux imprévisibles : un pic de trafic se traduit instantanément en facture, sans alerte préventive.

Étape 5 — Prototyper sur Confluent Cloud en 30 minutes

La meilleure manière d’évaluer Confluent Cloud n’est pas de lire la documentation mais de monter un cluster de test. Les 400 USD de crédits offerts permettent de tourner un cluster Basic complet pendant deux à trois semaines à charge nulle.

# Installer le CLI Confluent
curl -sL https://cnfl.io/cli | sh -s -- -b /usr/local/bin
confluent login

# Créer un environnement et un cluster Basic
confluent environment create dev-kafka
confluent environment use $(confluent environment list -o json | jq -r '.[].id')
confluent kafka cluster create poc-itskc --cloud aws --region eu-west-1 --type basic

# Récupérer les credentials
confluent api-key create --resource $(confluent kafka cluster list -o json | jq -r '.[0].id')

Le CLI renvoie une API key et un API secret qu’on utilise comme username/password Basic Auth pour SASL_SSL. Toute l’API REST Kafka, les CLI kafka-console-producer.sh et kafka-console-consumer.sh fonctionnent identiquement à un cluster auto-hébergé — il n’y a aucun verrou sur le client. Un signal de réussite : on peut publier le premier message en moins d’une minute après la création du cluster.

Étape 6 — Tester l’auto-hébergement en 90 minutes

Côté auto-hébergement, le tutoriel détaillé pas-à-pas figure dans l’article Déployer un cluster Apache Kafka 4.2 en mode KRaft publié sur ce blog. On commande trois VPS Hetzner via leur console, on suit la procédure d’installation, et on a un cluster à trois nœuds en environ 90 minutes. Le coût ce premier mois sera la facture Hetzner — environ 25 à 30 euros — moins le crédit de bienvenue si vous êtes nouveau client.

L’aspect le plus instructif de cet exercice est de réaliser ce qu’on ne fait pas dans Confluent Cloud : le format du stockage avec UUID, le tuning du firewall, l’écriture des fichiers systemd, la configuration des metrics JMX, la mise en place du monitoring. Ce sont des heures précieuses pour comprendre vraiment Kafka, mais ce sont aussi des heures que vous ne consacrez pas à votre métier.

Étape 7 — Modèle de décision en fonction du contexte

À partir des étapes précédentes, on peut formaliser une grille décisionnelle simple en quatre questions.

Quelle est votre charge prévue ? Si scénario A, Confluent Basic est probablement le bon choix : le différentiel de coût est faible et la simplicité opérationnelle est précieuse. Si scénario B ou C, l’auto-hébergement est sérieusement à considérer.

Quelles sont vos contraintes réglementaires ? Si vos données doivent rester en zone géographique précise non couverte par Confluent Cloud, ou si vous êtes soumis à un audit qui exige une infrastructure souveraine, l’auto-hébergement chez un opérateur local (PAIX Dakar pour le Sénégal, Raxio ou Equinix AB1 pour Abidjan) est obligatoire.

Avez-vous l’équipe opérationnelle ? Sans un SRE ou un développeur senior dédié à l’infrastructure 30 à 50 % de son temps, l’auto-hébergement Kafka deviendra une dette opérationnelle. Confluent Cloud absorbe cette complexité.

Quelle est votre trajectoire de croissance ? Si vous prévoyez une croissance de 10x ou plus en 24 mois, Confluent Cloud scale sans friction tandis que l’auto-hébergement demandera des refactorings réguliers. À l’inverse, une charge stable est parfaitement servie par un cluster auto-hébergé bien dimensionné.

Erreurs fréquentes

Cas hybride : auto-hébergement + Confluent Stream Governance

Un compromis méconnu mais intéressant en 2026 : on peut utiliser un cluster Kafka auto-hébergé et brancher les services managés de Confluent à la carte. Schema Registry managé, Stream Lineage, Stream Catalog sont disponibles sur Confluent Cloud à l’unité, indépendamment du broker. C’est utile pour les équipes qui veulent garder le contrôle du stockage et du traitement, mais externaliser la gouvernance des schémas et des contrats de données. Le coût additionnel est modeste — environ 100 USD par mois pour le pack Stream Governance Essentials — et l’intégration avec un broker Apache Kafka standard fonctionne sans modification.

Le cas spécifique de l’Afrique de l’Ouest

Pour une équipe basée à Dakar, Abidjan, Bamako ou Lomé, deux contraintes techniques s’ajoutent à l’arbitrage économique. Premièrement, la latence : un cluster Confluent Cloud en eu-west-1 (Irlande) ou eu-central-1 (Francfort) tourne autour de 70 à 100 millisecondes aller-retour depuis Dakar. C’est acceptable pour de l’event-driven asynchrone, mais cela fait reculer toute architecture qui voudrait du Kafka comme transport synchrone bas-latence. Deuxièmement, la stabilité de connectivité : un cluster auto-hébergé sur un VPN privé interne à un datacenter local n’est pas affecté par une rupture de câble sous-marin SAT-3 ou ACE, contrairement à Confluent Cloud qui exige une connectivité Internet continue.

Ces deux raisons techniques poussent un nombre croissant d’équipes ouest-africaines à privilégier l’auto-hébergement pour la production, en gardant Confluent Cloud pour le développement et les environnements de pré-production où la friction de mise en place compte plus que la latence.

Ressources et références

• Documentation officielle facturation Confluent Cloud
• Confluent Platform 8.2 — interopérabilité et versions supportées
• Calculateur de coûts Confluent Cloud officiel
• Tutoriel auto-hébergement Kafka 4.2 KRaft

Retour au guide principal : Apache Kafka en production en 2026 : panorama complet.