Streamhouse est le nouveau mot à la mode. Voici la partie qui compte vraiment.

Par Andrew Tan

Le mot que personne n’a défini

J’étais sur un panel le mois dernier lorsqu’une personne a utilisé le mot « streamhouse » cinq fois en deux minutes. Elle y croyait sincèrement. Elle affirmait que c’était « le plus grand changement en architecture de données depuis le lakehouse ». Elle disait que cela allait « faire disparaître la frontière entre le streaming et l’analytique ». Elle ajoutait que les équipes qui ne l’adopteraient pas se retrouveraient, dans les dix-huit mois, à « maintenir une infrastructure batch legacy ».

Après le panel, je lui ai demandé ce qu’était concrètement un streamhouse.

Elle a marqué une pause. Puis elle a répondu : « C’est quand votre plateforme de streaming et votre entrepôt deviennent la même chose. » J’ai demandé un exemple. Elle a dit Kafka avec Iceberg. J’ai demandé en quoi c’était différent de ce que Flink fait déjà. Elle a répondu que le streamhouse était « native ». J’ai demandé ce que « native » signifiait dans ce contexte. Elle a expliqué que cela voulait dire qu’on n’avait plus besoin d’un job séparé pour déplacer les données du flux vers l’entrepôt. J’ai demandé ce qui se passait quand il fallait relire le flux, effectuer un backfill ou joindre une table de dimension à évolution lente. Elle a répondu que c’étaient des « détails d’implémentation ».

C’était une vendeuse. Elle vendait quelque chose. Mais le mot est désormais dans la nature, et je l’ai entendu dans la bouche d’architectes de données, de responsables de plateformes, et même d’un CTO qui m’a expliqué que sa stratégie 2027 consistait à « streamhousifier la stack analytique ».

Faisons donc ce que le marketing ne fait pas : définir la chose, séparer le vrai changement du reconditionnement, et déterminer s’il s’agit d’une catégorie qui mérite votre attention ou simplement d’une nouvelle étiquette pour une complexité que vous possédez déjà.

Ce que « streamhouse » est censé signifier

Le terme provient d’un groupe de travail annoncé plus tôt cette année par Confluent, Aiven, Redpanda, StreamNative et Ververica. Le pitch est simple : les données de streaming et les données analytiques ont vécu trop longtemps dans des systèmes séparés. Kafka gère le flux. Snowflake gère l’analytique. Vous construisez un pipeline entre les deux. Le pipeline tombe en panne. Tout le monde accuse l’autre équipe.

La proposition du streamhouse est de les unifier. Les données de streaming arrivent, dès leur arrivée, dans des formats de table ouverts — Iceberg, Delta Lake, Paimon. Les moteurs de requête lisent ces tables directement. Pas de job ETL. Pas de synchronisation batch. Pas de « zone de transit » qui devient obsolète entre deux exécutions. Le flux est la table. La table est le flux.

Confluent appelle cela Tableflow. Aiven l’appelle Aiven Streams. Le nom exact varie selon le vendeur, mais l’architecture reste cohérente :

• Les événements arrivent dans une couche de streaming (Kafka, Redpanda, Pulsar).
• Un moteur de streaming (Flink, Spark Structured Streaming ou un runtime spécifique au vendeur) les écrit de manière incrémentale dans un format de table ouvert.
• Les moteurs de requête (Trino, DuckDB, Snowflake, BigQuery) lisent la table comme s’il s’agissait d’une table d’entrepôt classique.
• La table est « mise à jour en continu » plutôt que « rafraîchie périodiquement ».

Ce n’est pas une arnaque. Il y a une réelle avancée technique. Faire en sorte qu’un pipeline de streaming produise des fichiers de table interrogeables en quasi-temps réel, avec évolution de schéma, compaction et isolation par snapshot, est véritablement difficile. Les équipes qui construisent cela méritent des félicitations.

Mais l’architecture n’est pas nouvelle. C’est un raffinement de ce que Flink, Kinesis Analytics et même certains pipelines Kafka-to-S3 sur mesure font depuis des années. Ce qui est nouveau, c’est le parapluie marketing : le mot « streamhouse », le groupe de travail, et la promesse que ce modèle supprime le besoin de systèmes batch et streaming distincts.

Cette dernière partie est exagérée.

Ce qui change — et ce qui ne change pas

Séparons le réel de l’aspirationnel.

Ce qui s’améliore réellement :

• La latence jusqu’aux données interrogeables diminue. Si vous exécutez une synchronisation batch toutes les heures, passer à du micro-batch continu ou du vrai streaming réduit ce délai à quelques secondes ou minutes. Pour les cas d’usage où la fraîcheur est critique — détection de fraude, tableaux de bord opérationnels, tarification en temps réel — c’est une vraie amélioration.
• L’évolution de schéma est plus propre. Les formats de table ouverts gèrent les changements de schéma mieux que la plupart des pipelines sur mesure streaming-entrepôt. L’ajout d’une colonne ne nécessite plus de script de migration. Le renommage d’un champ est tracé dans les métadonnées. Cela réduit les incidents du type « qui a cassé le tableau de bord ».
• Une seule couche de stockage, moins de copies. Si votre équipe analytique peut interroger les mêmes fichiers Iceberg que ceux produits par votre pipeline de streaming, vous n’avez plus besoin d’un extract vers un entrepôt séparé. Moins de copies signifie moins de jobs de synchronisation, moins de fenêtres de cohérence et moins d’endroits où les données peuvent diverger.

Ce qui reste exactement identique :

• L’orchestration. Un streamhouse ne supprime pas le besoin de coordonner les jobs, les dépendances et les retries. Si votre pipeline de streaming alimente un modèle dbt qui alimente un tableau de bord, ce DAG doit toujours être géré. Le streamhouse remplace l’étape d’extraction batch. Il ne remplace pas la couche d’orchestration.
• Les backfills et les replays. Quand un bug corrompt trois jours de données diffusées en streaming, il faut rembobiner le log et retraiter. Le format de table du streamhouse rend cela possible. Il ne le rend pas facile. Vous devez toujours gérer les offsets des consommateurs, traiter les changements de schéma survenus en cours de flux et vérifier que les données rejouées correspondent à ce que les systèmes en aval ont déjà vu.
• Les workflows inter-systèmes. La plupart des vrais pipelines touchent plus d’un système. Un flux peut déclencher un appel API, mettre à jour un cache, écrire dans une base de données et produire une notification. Le streamhouse gère le chemin analytique. Il ne gère pas le chemin opérationnel. Vous avez toujours besoin d’un runtime capable de coordonner des systèmes aux modèles de cohérence et aux modes de défaillance différents.
• La structure de coût. L’infrastructure de streaming est une infrastructure toujours active. Un job batch qui s’exécute dix minutes toutes les heures coûte dix minutes de calcul par heure. Un job de streaming qui tourne en continu coûte soixante. Le streamhouse déplace le coût des jobs de synchronisation vers le calcul de streaming. Savoir si c’est moins cher dépend de votre volume, de vos patterns de requête et de la qualité de votre paramétrage de compaction.

Le streamhouse améliore le stockage et l’interrogeabilité des données de streaming. Il ne supprime pas le besoin d’un runtime qui gère le travail opérationnel complexe autour de ces données.

L’illusion de la table continue

L’idée la plus séduisante du pitch streamhouse est celle de la « table continue ». C’est une table qui ne devient jamais obsolète. Vous l’interrogez et vous obtenez les dernières données. Pas de job batch. Pas d’attente. La table est vivante.

C’est un modèle mental puissant. Il est aussi légèrement trompeur.

Une table continue n’est pas un objet unique qui se met à jour sur place. C’est une séquence de snapshots, chacun représentant la table à un instant donné. Quand vous l’interrogez, vous lisez l’un de ces snapshots. Le moteur de requête choisit le plus récent qu’il connaît. Le moteur de streaming ajoute constamment de nouveaux fichiers et valide de nouveaux snapshots.

Cela importe parce que l’écart entre « le dernier événement est arrivé » et « le dernier snapshot est interrogeable » n’est pas nul. Il dépend de :

• La fréquence de commit. À quelle fréquence le moteur de streaming écrit-il un nouveau snapshot ? Toutes les secondes ? Toutes les minutes ? Plus c’est rapide, plus la surcharge de métadonnées est importante.
• Le retard de compaction. La table accumule des petits fichiers. Les requêtes ralentissent. Quelqu’un — ou un job planifié — doit compacter ces fichiers en fichiers plus gros. Pendant la compaction, le comportement des requêtes peut changer.
• La cohérence du catalogue. Le moteur de requête apprend l’existence des nouveaux snapshots via un catalogue. Si le catalogue est cohérent de manière éventuelle — et la plupart le sont — une requête peut lire un snapshot qui a trente secondes de retard sur le flux réel. Trente secondes, ce n’est pas du temps réel. C’est du quasi-temps réel déguisé en temps réel.

La table continue est une abstraction utile. Mais elle reste une abstraction au-dessus d’un processus de lots-de-micro-lots. Les fichiers sont discrets. Les snapshots sont discrets. La fraîcheur est limitée par les intervalles de commit, les plannings de compaction et la latence du catalogue. Appeler cela « continu » occulte la réalité technique : des lots plus petits, des commits plus rapides, les mêmes problèmes de coordination.

Là où les équipes finissent encore par coudre des runtimes entre eux

Voici le scénario que le marketing du streamhouse ne vous montre pas :

Vous avez un pipeline de streaming qui écrit des événements dans une table Iceberg. Votre équipe analytique l’interroge avec Trino. Votre équipe ML le lit avec Spark. Votre équipe opérationnelle doit déclencher une alerte lorsqu’un pattern d’événement spécifique se produit — non pas après que l’événement a atterri dans la table, mais au moment où il arrive dans le flux.

Le streamhouse gère les chemins analytique et ML. Mais l’alerte opérationnelle doit s’exécuter sur le flux lui-même, avant que l’événement ne soit validé dans un snapshot de table. Vous déployez donc un job Flink séparé pour traiter le flux brut. Vous avez maintenant deux runtimes : un pour le chemin table, un pour le chemin opérationnel.

Puis l’entreprise demande un rapport hebdomadaire qui rapproche les données de streaming avec les données batch de votre système ERP. Les données ERP n’arrivent pas en flux. Elles arrivent sous forme de dump CSV quotidien. Vous construisez donc un job batch qui lit le CSV, le joint à la table Iceberg et produit le rapport. Vous avez maintenant trois runtimes.

Quelqu’un découvre ensuite que le pipeline de streaming a produit des données erronées pendant six heures le mardi précédent à cause d’une dérive de schéma. Vous devez rembobiner le flux, corriger la logique et rejouer. Mais la relecture doit produire exactement les mêmes snapshots de table que ceux que les requêtes en aval ont déjà vus, sinon l’entraînement de l’équipe ML sera incohérent. Vous coordonnez donc la relecture avec le pipeline de l’équipe ML. Vous faites maintenant de l’orchestration de runtime sur quatre systèmes.

Le streamhouse a résolu le problème « comment interroger mon flux ». Il n’a pas résolu le problème « comment coordonner plusieurs runtimes aux sémantiques différentes ». Ce problème reste le vôtre.

Le cadre de décision honnête

Si vous évaluez si le pattern streamhouse a du sens pour votre équipe, ne commencez pas par le diagramme d’architecture. Commencez par ce que vous essayez réellement de faire.

Utilisez un streamhouse quand :

• Votre cas d’usage principal est l’analytique ou le ML sur des données qui arrivent en continu, et votre synchronisation batch actuelle est le goulet d’étranglement.
• Vous utilisez déjà Kafka (ou Redpanda, ou Pulsar) et vous en avez assez de maintenir des pipelines séparés pour déplacer ces données vers un entrepôt.
• Vos patterns de requête sont compatibles avec les formats de table ouverts — lectures colonnaires, predicate pushdown, isolation par snapshot — et vous n’essayez pas de faire des déclenchements opérationnels en moins d’une seconde.
• Vous avez l’équipe nécessaire pour gérer la compaction, la cohérence du catalogue et l’évolution de schéma à la vitesse du streaming.

N’utilisez pas un streamhouse quand :

• Votre cas d’usage « streaming » est en réalité un job batch qui s’exécute toutes les quinze minutes. Le streamhouse n’est pas gratuit. Si personne n’a besoin des données plus rapidement que toutes les quinze minutes, vous payez du calcul continu pour une valeur intermittente.
• Vous avez besoin de déclencheurs opérationnels — appels API, mises à jour de cache, notifications — qui doivent se déclencher à l’arrivée de l’événement, et non au commit dans la table. Le streamhouse est un pattern analytique, pas un pattern opérationnel.
• Votre équipe peine déjà avec les opérations sur les formats de table ouverts. Le streamhouse ajoute la vélocité du streaming à ces opérations. Si la compaction et la gestion du catalogue sont déjà douloureuses, les rendre plus rapides ne les rend pas plus faciles.
• Vous espérez qu’il remplacera votre couche d’orchestration. Ce ne sera pas le cas. Vous aurez toujours besoin de quelque chose pour gérer les dépendances, les retries, les backfills et les workflows inter-systèmes.

Le streamhouse est un pattern de stockage et de requête. Ce n’est pas un pattern de runtime. Si vos problèmes sont des problèmes de stockage et de requête — données obsolètes, retard de synchronisation, trop de copies — cela vaut la peine d’être évalué. Si vos problèmes sont des problèmes de runtime — coordination, reprise sur incident, sémantique inter-systèmes — le streamhouse n’aide pas et peut même ajouter de la complexité.

Ce que les vendeurs vendent vraiment

Je ne pense pas que le groupe de travail streamhouse soit malhonnête. Je pense qu’il est sélectif. Il montre les cas d’usage où le pattern brille — analytique en temps réel, feature stores ML continus, tableaux de bord opérationnels — et passe discrètement sous silence ceux où il ne fonctionne pas.

Ce qu’ils vendent vraiment, c’est un déplacement du centre de gravité. Au cours des dix dernières années, l’entrepôt était le centre de l’univers des données. Tout y convergeait. La proposition du streamhouse dit que le flux est le centre, et que l’entrepôt n’est qu’un consommateur parmi d’autres.

C’est un changement significatif pour certaines organisations. Si votre entreprise est pilotée par les événements — détection de fraude, IoT, trading en temps réel — le modèle stream-first a du sens. Mais la plupart des organisations ne sont pas pilotées par les événements. Elles sont pilotées par des plannings. Elles exécutent des rapports. Elles mettent à jour des tableaux de bord. Elles réentraînent des modèles pendant la nuit. Pour ces équipes, déplacer le centre de gravité vers le flux est une solution à la recherche d’un problème.

Les vendeurs le savent. C’est pourquoi le marketing insiste sur le « future-proofing » et la « modern data architecture » plutôt que sur des améliorations opérationnelles concrètes. Le streamhouse est positionné comme une évolution inévitable, comme le Cloud ou le lakehouse avant lui. Le sous-texte est : si vous ne faites pas cela, vous prenez du retard.

Peut-être. Mais du retard par rapport à quoi ? Si vos pipelines batch sont fiables, que vos parties prenantes sont satisfaites et que vos coûts sont prévisibles, adopter un streamhouse parce qu’un vendeur dit que c’est inévitable n’est pas de la modernisation. C’est de l’architecture par FOMO.

Où nous nous situons

Chez layline.io, nous ne vendons pas un streamhouse. Nous vendons un runtime qui gère à la fois le batch et le streaming dans le même pipeline, sur l’infrastructure que vous possédez déjà.

La raison pour laquelle cela importe : beaucoup d’équipes évaluent le streamhouse parce qu’elles veulent que le batch et le streaming coexistent sans avoir à maintenir deux stacks distinctes. C’est un vrai problème. Mais le streamhouse le résout en unifiant le stockage autour du flux. Nous le résolvons en unifiant le runtime autour du Workflow.

Si votre équipe analytique a besoin d’une table d’entrepôt et que votre équipe opérationnelle a besoin d’un déclencheur sur flux, les deux chemins peuvent passer par la même logique de pipeline, la même observabilité et la même reprise sur incident. Le format de stockage devient un choix de configuration — Iceberg quand cela aide, Parquet quand ce n’est pas nécessaire, un bus de messages quand vous avez besoin de latence opérationnelle — plutôt qu’un engagement architectural.

Le streamhouse est un pattern utile pour un ensemble spécifique de problèmes. Ce n’est pas une architecture universelle, et ce n’est pas un remplacement du runtime opérationnel qui fait fonctionner vos pipelines à 2 h du matin. Les équipes qui réussissent avec lui sont celles qui l’adoptent pour les bonnes raisons — latence de requête, réduction de la surcharge de synchronisation, évolution de schéma plus propre — et qui n’attendent pas de lui qu’il résolve des problèmes qu’il n’a jamais été conçu pour traiter.

Le buzzword finira par disparaître. La technologie sous-jacente — l’ingestion continue dans des formats de table ouverts — perdurera et s’améliorera. La question est de savoir si votre équipe en avait vraiment besoin avant que le marketing ne vous dise que c’était le cas.

Si votre équipe essaie de distinguer le signal du streamhouse du bruit — ou si vous recherchez un runtime qui gère le batch et le streaming sans vous forcer à choisir une religion de stockage — contactez-nous. Nous avons aidé des équipes à évaluer exactement ce compromis, et la réponse est généralement plus simple que ne le suggèrent les schémas d’architecture.

Andrew Tan est un entrepreneur en série et fondateur de layline.io, qui construit une infrastructure de traitement de données d’entreprise capable de gérer à la fois les workloads batch et temps réel à grande échelle.