Le 1er octobre 2026, en plein milieu de sa traditionnelle “Birthday Week”, Cloudflare a dévoilé K2, un nouveau service de streaming d’événements construit directement sur son stockage objet R2. L’annonce, signée par l’ingénieur Micah Wylde sur le blog officiel de l’entreprise, vise une cible précise : les équipes qui gèrent aujourd’hui des clusters Apache Kafka et qui en ont assez d’opérer des brokers, des partitions et des réplicas. Pour les entreprises françaises et européennes qui cherchent à réduire leur dépendance aux piles d’infrastructure lourdes, l’arrivée d’un acteur du calibre de Cloudflare sur ce segment change la donne.
K2 arrive en bêta publique, réservée aux comptes Workers Paid, avec des limites encore modestes : 10 Go de stockage par compte et 30 Mo/s de débit de production par flux. Mais le positionnement est clair. Cloudflare veut proposer une alternative serverless à Kafka, à Amazon Kinesis et à Confluent, sans que les développeurs aient à gérer la moindre machine. Ce lancement s’inscrit dans une semaine chargée pour l’entreprise de San Francisco, qui a aussi revendiqué la première place en débit réseau dans 74 % des 1 000 plus grands réseaux mondiaux, contre 60 % en avril 2026.
Qu’est-ce que Cloudflare K2 exactement ?
K2 est une primitive de streaming d’événements. Concrètement, une application peut écrire (“append”) des enregistrements dans un flux nommé, et Cloudflare les stocke sous forme de journal ordonné et durable. L’idée centrale, c’est la séparation entre producteurs et consommateurs : un service peut continuer à écrire des données pendant qu’un autre les lit à son propre rythme, s’arrête, puis reprend plus tard sans perdre le fil. C’est exactement le problème que Kafka a résolu il y a quinze ans, mais Cloudflare le résout avec une architecture entièrement différente.
Sous le capot, K2 repose sur un journal partitionné et durable construit sur R2 Object Storage, le service de stockage compatible S3 de Cloudflare. Cette approche permet de découpler le stockage du calcul : la capacité de stockage grandit indépendamment de la puissance de traitement, ce qui est impossible avec un cluster Kafka classique où chaque broker porte à la fois le disque et le calcul. R2 affiche une durabilité annoncée de 11 “9”, ce qui place K2 dans une classe de fiabilité comparable à celle des grands fournisseurs de stockage objet.
La rétention des données est configurable, avec un maximum de 30 jours en bêta et des durées plus longues disponibles sur demande. Les flux peuvent être consommés de deux façons : soit en répartissant les enregistrements entre un groupe de consommateurs (comme un pool de workers qui se partagent la charge), soit en livrant chaque enregistrement à plusieurs abonnés indépendants. Chaque abonnement garde sa propre position dans le flux, ce qui autorise des vitesses de traitement différentes selon l’application.
Comment accéder à K2 : Workers, HTTP et Wrangler
Cloudflare a conçu K2 pour s’intégrer nativement dans son écosystème de développeurs. Les flux peuvent être créés et administrés via trois canaux : le tableau de bord Cloudflare, l’outil en ligne de commande Wrangler, ou une API REST. Côté exécution, les développeurs écrivent dans un flux soit via un binding Workers (le modèle de liaison propre à Cloudflare Workers), soit via une API HTTP classique, ce qui ouvre la porte à des intégrations depuis n’importe quel langage ou environnement, pas seulement depuis l’écosystème JavaScript de Workers.
Ce choix d’architecture distingue K2 d’un Kafka hébergé. Cloudflare précise explicitement dans son annonce qu’il ne s’agit pas d’un Kafka géré par Cloudflare, mais d’un journal natif à l’entreprise, sans couche de compatibilité avec le protocole Kafka. Autrement dit, les équipes qui migrent depuis Kafka devront réécrire leurs producteurs et consommateurs pour parler le langage de K2, et non l’inverse. C’est un pari : Cloudflare mise sur la simplicité d’intégration avec Workers et R2 plutôt que sur la compatibilité rétroactive avec quinze ans d’écosystème Kafka.
Les chiffres clés du lancement : limites et tarifs
Le tableau ci-dessous résume les paramètres techniques et tarifaires annoncés par Cloudflare pour la phase de bêta publique de K2. Ces chiffres évolueront probablement à la sortie de bêta, mais ils donnent une première idée du positionnement prix par rapport aux solutions existantes.
| Paramètre | Valeur en bêta publique | Remarque |
|---|---|---|
| Stockage maximum par compte | 10 Go | Limite spécifique à la bêta, pas la version finale |
| Débit de production par flux | 30 Mo/s | Par stream, pas par compte |
| Rétention par défaut | 30 jours | Extension possible sur demande |
| Prix données produites | 0,04 $/Go | Facturation à l’écriture |
| Prix données consommées | 0,04 $/Go | Facturation à la lecture |
| Prix rétention mensuelle | 0,02 $/Go/mois | Coût de stockage dans le temps |
| Durée de bail des lots consommés | 5 minutes | Fenêtre avant réattribution d’un lot non acquitté |
| Latence de production (p99) | ~1 seconde | Compromis assumé lié à l’écriture sur objet storage |
| Accès requis | Abonnement Workers Paid | Pas disponible sur le plan gratuit |
Le point le plus intéressant pour les équipes financières est sans doute l’absence de coût fixe. Avec Kafka auto-géré, la facture démarre dès la mise en route du premier cluster, qu’il serve ou non. Avec K2, la facturation suit strictement l’usage réel en gigaoctets produits, consommés et retenus. C’est le même raisonnement économique qui a propulsé Cloudflare Workers et R2 : transformer un coût d’infrastructure fixe en coût variable aligné sur le trafic.
Le compromis technique : la latence contre la simplicité
Cloudflare ne cache pas le principal inconvénient de son architecture. Parce que K2 écrit sur du stockage objet plutôt que sur des disques locaux de brokers, le service doit accumuler des lots localement avant de les écrire sur R2. Cette accumulation introduit une latence de production mesurée autour d’une seconde au 99e percentile. Un cluster Kafka bien réglé, avec des disques NVMe locaux, peut descendre sous la dizaine de millisecondes pour le même type d’opération.
Pour la majorité des cas d’usage, cette différence de latence ne pose pas de problème. Un pipeline d’ingestion de logs, un système de notification événementielle, une synchronisation entre microservices tolèrent très bien une seconde de délai. Mais pour les cas critiques comme le trading à basse latence, la détection de fraude en temps réel ou les systèmes de contrôle industriel, ce compromis élimine K2 d’office. Cloudflare semble avoir fait ce choix en toute connaissance de cause, en misant sur le marché beaucoup plus large des usages tolérants à la latence plutôt que sur la niche du temps réel strict.
Birthday Week 2026 : une semaine d’annonces cloud chargée
K2 n’est pas sorti seul. Cloudflare a profilé la même semaine plusieurs annonces qui dessinent une stratégie cohérente de plateforme de développement complète. Le même jour, l’entreprise a annoncé que ses conteneurs pouvaient désormais démarrer six fois plus rapidement, avec une sélection dynamique de l’image et du type d’instance gérée automatiquement par l’agent sous-jacent, ainsi que des snapshots de système de fichiers désormais en bêta publique.
Le 29 septembre, veille de l’annonce K2, Cloudflare et Deutsche Telekom ont annoncé un partenariat centré sur un internet plus sécurisé et résilient pour les opérateurs télécoms européens. Ce rapprochement avec l’un des plus gros groupes télécoms du continent illustre l’ambition de Cloudflare de s’ancrer plus profondément dans les infrastructures critiques européennes, à un moment où la question de la souveraineté numérique domine les débats à Bruxelles. Cloudflare a également évoqué Basin, décrit comme une plateforme de données plus ouverte et accessible pour les développeurs, bien que les détails techniques complets restent encore limités à ce stade.
Pourquoi Cloudflare se lance sur le marché du streaming
La logique derrière K2 s’inscrit dans la trajectoire de Cloudflare depuis plusieurs années : transformer chaque couche d’infrastructure cloud traditionnelle en primitive serverless disponible depuis son réseau de 335 villes. Workers a remplacé les serveurs d’application, R2 a remplacé le stockage objet facturé avec frais de sortie, D1 a remplacé les bases de données relationnelles managées. Le streaming d’événements était l’une des dernières briques majeures manquantes dans ce catalogue, et Kafka en est la référence incontournable depuis sa création chez LinkedIn en 2011.
L’argument commercial de Cloudflare est la simplification opérationnelle. Faire fonctionner Kafka demande de réfléchir aux brokers, aux partitions, à la réplication, à la capacité et à l’ensemble des opérations de cluster. K2 propose de retirer cette charge en la déléguant entièrement à la plateforme Cloudflare, sur le même principe que les bases serverless ont retiré la gestion des instances de base de données aux équipes applicatives. Cette promesse de “zéro opération” parle directement aux équipes techniques réduites, très présentes dans les startups et PME technologiques européennes qui n’ont pas les moyens d’entretenir une équipe SRE dédiée au streaming de données.
K2 face à Apache Kafka : les différences qui comptent
La comparaison avec Apache Kafka est inévitable puisque Kafka reste la référence du secteur depuis plus d’une décennie. Techniquement, les deux systèmes répondent au même besoin fonctionnel, un journal ordonné et durable d’événements, mais avec des philosophies opposées. Kafka est open source, auto-hébergeable, extrêmement flexible, et dispose d’un écosystème massif de connecteurs, de clients dans tous les langages et d’outils tiers. En contrepartie, il demande une expertise opérationnelle réelle pour fonctionner de façon fiable à grande échelle.
K2 inverse ce compromis. Il retire la charge opérationnelle mais enferme l’utilisateur dans l’écosystème Cloudflare, sans la portabilité qu’offre le protocole ouvert de Kafka. Pour une entreprise qui part de zéro et qui construit déjà son application sur Workers et R2, K2 s’intègre naturellement et réduit la complexité globale du projet. Pour une entreprise qui a déjà investi des années dans une infrastructure Kafka, avec des connecteurs Kafka Connect et des pipelines Kafka Streams, la migration vers K2 implique une réécriture substantielle qui doit se justifier par des gains suffisants en coût ou en simplicité.
Comparatif complet : K2, Kinesis, Confluent, Redpanda et WarpStream
Le marché du streaming d’événements compte désormais plusieurs approches concurrentes, chacune avec son propre compromis entre ouverture, performance et simplicité opérationnelle. Le tableau suivant positionne K2 face aux principales alternatives disponibles pour les équipes techniques européennes en 2026.
| Solution | Modèle | Compatibilité Kafka | Opération | Point fort |
|---|---|---|---|---|
| Cloudflare K2 | Serverless propriétaire | Non | Entièrement gérée | Intégration native avec Workers et R2 |
| Apache Kafka | Open source auto-hébergé | Référence native | Manuelle ou via opérateur | Écosystème le plus large, portabilité totale |
| AWS Kinesis | Managé propriétaire AWS | Non | Gérée par AWS | Intégration profonde avec l’écosystème AWS |
| Confluent | Kafka commercial managé | Native | Gérée ou hybride | Outils entreprise, support, gouvernance des données |
| Redpanda | Broker alternatif compatible Kafka | Native | Auto-hébergée ou cloud | Performance, écrit en C++, pas de JVM |
| WarpStream | Compatible Kafka sur stockage objet | Native | Gérée | Coût réduit via stockage objet, comme K2 |
Le positionnement le plus proche de K2 sur le plan architectural est en réalité WarpStream, qui mise lui aussi sur le stockage objet pour réduire les coûts, mais en conservant la compatibilité avec le protocole Kafka. C’est précisément là que Cloudflare a choisi de ne pas suivre le même chemin, en misant sur une intégration propriétaire plus poussée avec son propre écosystème plutôt que sur l’interopérabilité. Ce choix stratégique rappelle la bataille autour des bases de données serverless, où chaque fournisseur cloud a dû choisir entre ouverture et intégration verticale.
Contexte historique : du broker Kafka au journal sur stockage objet
Pour comprendre pourquoi cette annonce compte, il faut remonter à l’origine de Kafka. Le projet est né chez LinkedIn en 2011 pour résoudre un problème précis : faire circuler des volumes massifs d’événements entre des systèmes internes sans que chaque équipe ne doive construire son propre pipeline point à point. Le succès a été tel que Kafka est devenu la colonne vertébrale de données événementielles dans une large majorité des grandes entreprises technologiques mondiales au cours de la décennie suivante.
Mais Kafka a été conçu pour une époque où le calcul et le stockage étaient encore pensés ensemble, sur les mêmes machines physiques. L’essor du stockage objet à bas coût, porté par S3 puis par des alternatives comme R2, a ouvert la voie à une nouvelle génération d’architectures qui séparent les deux. WarpStream a été parmi les premiers à explorer cette voie avec une couche de compatibilité Kafka, avant d’être racheté par Confluent en 2024. Cloudflare, en lançant K2 sans cette couche de compatibilité, prend un chemin plus radical, pariant sur sa propre base d’utilisateurs Workers plutôt que sur la base installée Kafka.
Impact sur le marché cloud européen et la question de la souveraineté
L’arrivée de K2 intervient à un moment particulièrement sensible pour le cloud en Europe. La Commission européenne a confirmé avoir envoyé des constats préliminaires à Amazon et Microsoft en juin 2026 dans le cadre du Digital Markets Act, en vue d’une possible désignation d’AWS et Azure comme “gatekeepers”. Si cette désignation se confirme, les deux hyperscalers disposeraient de six mois pour se conformer à des obligations d’interopérabilité et de réduction du verrouillage client. Dans ce contexte réglementaire mouvant, chaque fournisseur alternatif qui propose une brique d’infrastructure facile à adopter et facile à quitter gagne en attractivité pour les entreprises européennes soucieuses de ne pas s’enfermer davantage chez un hyperscaler déjà sous surveillance.
Cloudflare, en tant qu’entreprise américaine, ne résout pas en soi la question de la souveraineté numérique européenne. Mais son modèle de facturation sans frais de sortie sur R2, hérité de la polémique autour des frais de transfert de données facturés par AWS et Azure, s’inscrit dans une tendance que les entreprises européennes suivent avec attention depuis plusieurs années. Le partenariat annoncé avec Deutsche Telekom la même semaine renforce cette lecture : Cloudflare cherche à se positionner comme un partenaire d’infrastructure pour les opérateurs télécoms européens plutôt que comme un simple fournisseur cloud concurrent des hyperscalers américains.
Ce que cela change pour les équipes techniques en France
Pour les équipes de développement françaises qui utilisent déjà Cloudflare Workers ou R2, K2 réduit mécaniquement le nombre de fournisseurs à intégrer dans une architecture événementielle. Plutôt que de faire tourner un cluster Kafka managé chez un fournisseur tiers, ou de payer les frais de sortie de données vers un service Kinesis externe, toute la chaîne peut désormais rester à l’intérieur du même réseau Cloudflare, du calcul au stockage en passant par le streaming.
Cette consolidation a un revers. En concentrant calcul, stockage et streaming chez un seul fournisseur, les entreprises augmentent leur dépendance à ce fournisseur unique, ce qui va à l’encontre des recommandations de diversification que portent plusieurs autorités de régulation financière européennes depuis les débats sur la résilience opérationnelle numérique. Les équipes IT devront donc peser le gain de simplicité contre ce risque de concentration avant d’adopter massivement K2 en production, surtout pour des charges considérées comme critiques.
Les limites actuelles qui freinent une adoption immédiate
Plusieurs éléments rappellent que K2 reste un produit de bêta publique, pas une solution mature prête pour toutes les charges de production. La limite de 10 Go de stockage par compte est largement insuffisante pour des pipelines d’événements à fort volume, typiques des plateformes e-commerce ou des systèmes de télémétrie IoT à grande échelle. Le débit de 30 Mo/s par flux, bien que confortable pour de nombreux usages, reste loin des débits que peut absorber un cluster Kafka correctement dimensionné avec plusieurs dizaines de partitions.
L’absence de documentation publique sur les garanties de livraison exactes (au moins une fois, exactement une fois, ou au plus une fois) complique aussi l’évaluation pour les cas d’usage financiers ou transactionnels, où ces garanties conditionnent directement la conformité réglementaire. Cloudflare devra préciser ces aspects avant que les équipes de conformité des grandes entreprises réglementées, dans la banque ou l’assurance par exemple, n’envisagent sérieusement une migration vers K2 pour des flux sensibles.
Cinq prévisions pour l’évolution du marché du streaming serverless
Première prévision : les limites de bêta de K2 (10 Go de stockage, 30 Mo/s par flux) seront revues à la hausse dans les prochains mois, suivant le même calendrier que R2 et Workers lors de leurs propres sorties de bêta, où Cloudflare a systématiquement élargi les quotas après quelques mois de retours utilisateurs.
Deuxième prévision : d’autres fournisseurs edge et serverless, notamment ceux qui opèrent déjà des couches de stockage objet concurrentes à R2, seront tentés de répliquer l’approche de Cloudflare en construisant leur propre primitive de streaming au-dessus de leur stockage objet existant plutôt que de continuer à revendre du Kafka managé tiers.
Troisième prévision : la pression concurrentielle de K2 et de WarpStream sur le modèle économique du streaming poussera Confluent et AWS Kinesis à revoir leurs grilles tarifaires vers des modèles plus proches du paiement à l’usage strict, pour limiter la fuite de charges de travail tolérantes à la latence vers des alternatives moins chères.
Quatrième prévision : les entreprises réglementées européennes, notamment dans la finance, resteront prudentes sur K2 jusqu’à ce que Cloudflare publie des garanties de livraison précises et une certification ou attestation de conformité adaptée aux exigences du secteur, un parcours que R2 lui-même a dû suivre avant d’être adopté plus largement par ce type de clients.
Cinquième prévision : le débat entre compatibilité Kafka et intégration propriétaire, déjà visible entre WarpStream et K2, deviendra l’un des axes de différenciation commerciale les plus discutés du secteur du streaming d’ici la fin 2027, à mesure que de plus en plus d’entreprises devront choisir entre portabilité et simplicité opérationnelle.
Comment tester K2 dès aujourd’hui
Les équipes qui souhaitent évaluer K2 dès maintenant doivent disposer d’un abonnement Workers Paid actif sur leur compte Cloudflare. La création d’un flux se fait en quelques commandes via Wrangler, l’outil en ligne de commande du Developer Platform de Cloudflare.
# Créer un nouveau flux K2 via Wrangler
wrangler k2 stream create mon-flux-evenements
# Lister les flux existants du compte
wrangler k2 stream list
# Consulter la configuration d'un flux
wrangler k2 stream describe mon-flux-evenementsCôté code applicatif, un Worker peut écrire dans le flux via le binding dédié configuré dans le fichier wrangler.toml, puis publier des enregistrements au fil des événements applicatifs. Cette approche reste nettement plus légère que le déploiement d’un client Kafka traditionnel, qui demande généralement de gérer des connexions persistantes vers plusieurs brokers et de configurer des paramètres de retry assez complexes.
Foire aux questions
K2 est-il compatible avec le protocole Apache Kafka ?
Non. Cloudflare précise explicitement que K2 n’est pas un Kafka hébergé et ne propose pas de couche de compatibilité avec le protocole Kafka. Les applications doivent être écrites spécifiquement pour l’API de K2.
Quel est le prix de Cloudflare K2 en bêta ?
Cloudflare facture 0,04 $ par Go de données produites, 0,04 $ par Go de données consommées, et 0,02 $ par Go et par mois pour la rétention, sans frais fixe de cluster.
K2 peut-il remplacer un cluster Kafka en production dès maintenant ?
Pour les charges tolérantes à une latence d’environ une seconde et aux limites actuelles de bêta (10 Go de stockage, 30 Mo/s par flux), K2 peut déjà convenir. Pour les charges à très fort volume ou à latence critique, un cluster Kafka ou un service comme Kinesis reste plus adapté à ce stade.
Faut-il un abonnement payant pour utiliser K2 ?
Oui, K2 nécessite un abonnement Workers Paid actif. Il n’est pas disponible sur le plan gratuit de Cloudflare Workers.
Quelle est la différence entre K2 et WarpStream ?
Les deux reposent sur du stockage objet pour réduire les coûts, mais WarpStream conserve une compatibilité avec le protocole Kafka, alors que K2 utilise une API propriétaire propre à Cloudflare, sans compatibilité Kafka.
Pourquoi la latence de production de K2 est-elle plus élevée que celle de Kafka ?
Parce que K2 écrit sur du stockage objet R2 plutôt que sur des disques locaux de brokers, le service doit accumuler des lots d’enregistrements avant de les écrire, ce qui introduit une latence mesurée autour d’une seconde au 99e percentile.
K2 est-il disponible dans toutes les régions, y compris en France ?
K2 s’appuie sur le réseau mondial de Cloudflare, qui couvre 335 villes dont plusieurs points de présence en France et en Europe, mais la gestion régionale précise des données dépend de la configuration de chaque compte.
Cloudflare a-t-il annoncé d’autres nouveautés pendant Birthday Week 2026 ?
Oui. La même semaine, Cloudflare a annoncé un démarrage six fois plus rapide pour ses conteneurs, des snapshots de système de fichiers en bêta publique, un partenariat avec Deutsche Telekom, ainsi qu’une plateforme de données appelée Basin.