Batch vs streaming : choisir le bon paradigme

Les 12 millions de dollars de rafraîchissement que personne ne regardait

En 2019, un grand distributeur nord-américain a reconstruit son analytique de stocks sur une stack streaming complète, Kafka, Flink, tout l'attirail, pour que les directeurs de magasin puissent voir leurs positions de stock « en temps réel ». Dix-huit mois et environ 12 millions de dollars plus tard, un audit interne a mis au jour la vérité qui dérange : le directeur de magasin médian consultait les dashboards de stock une fois par vacation, et les décisions de réapprovisionnement étaient verrouillées sur un cycle nocturne déclenché à 2 h du matin, quoi qu'il arrive. L'entreprise avait acheté une latence inférieure à la seconde pour une décision prise une fois par jour. Le pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → streaming était une Ferrari au ralenti sur un parking.

Voilà le piège. Le streaming est devenu un signe extérieur de richesse, la preuve qu'une organisation data est « moderne ». Mais la latence est un coût, pas une vertu. Votre travail de CDO n'est pas de minimiser la latence ; c'est d'aligner la latence sur la décision qui la consomme. Surdimensionnez et vous brbrLe pourcentage de visiteurs qui repartent après avoir vu une seule page, souvent le signe d'une pertinence insuffisante, d'un décalage d'intention ou d'une expérience utilisateur faible.Voir la définition complète →ûlez du budget et des effectifs sur une complexité opérationnelle que personne n'a demandée. Sous-dimensionnez et vous étranglez un cas d'usage, fraude, pricing dynamique, routage de flotte, qui meurt réellement sans fraîcheur.

Cette leçon vous donne le framework de décision et la discipline opérationnelle pour réussir cet alignement.

Le framework de la latence de décision

ArrArrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êtez de demander « est-ce que ça doit être en temps réel ? ». C'est la mauvaise question parce que c'est l'enthousiasme des ingénieurs qui y répond. Demandez plutôt : quelle est la latence de décision du processus consommateur ?

La latence de décision, c'est le temps entre le moment où un événement se produit et le moment où un humain ou un système peut effectivement *agir* dessus d'une manière qui change l'issue. Elle comporte trois composantes que vous devez interroger séparément :

• La fraîcheur des données, à quelle vitesse la donnée peut arriver.
• La cadence de décision, à quelle fréquence le processus consommateur fait réellement un choix.
• La latence d'action, combien de temps il faut pour exécuter une fois la décision prise.

**La contrainte déterminante est la *plus lente* des trois**. Le distributeur ci-dessus avait une fraîcheur inférieure à la minute, une cadence de décision quotidienne et une latence d'action (le réapprovisionnement physique) se comptant en heures. La fraîcheur n'a jamais été le goulot d'étranglement. Dépenser pour l'améliorer relevait de l'illettrisme économique.

D'où la règle suivante : la fraîcheur ne vaut d'être achetée que jusqu'au point où elle cesse d'être la contrainte déterminante. Au-delà, chaque dollar de réduction de latence produit zéro amélioration de décision.

La courbe de décroissance de valeur

Pour tout cas d'usage, tracez la façon dont la valeur d'une donnée décroît avec son âge. La forme vous indique le paradigme.

• Décroissance en falaise, la valeur tombe à près de zéro en quelques secondes à quelques minutes. Autorisation antifraude, bidding publicitaire, trading algorithmique, dispatch de flotte, coupures de sécurité déclenchées par anomalie. Ici, le streaming n'est pas un luxe ; une donnée tardive est une donnée *sans valeur*. Un score de fraude délivré 400 ms après que la transaction est passée est un rapport, pas un contrôle.
• Décroissance linéaire, la valeur s'érode régulièrement sur plusieurs heures. Supervision opérationnelle, supply chain intra-journalière, contexte pour le service client. Le micro-batch (intervalles de 1 à 15 minutes) gagne généralement : l'essentiel de la valeur, une fraction de la complexité.
• Plateau puis chute, la valeur reste stable pendant un jour ou plus, puis compte à une échéance fixe. Clôture financière, reporting réglementaire, analyse de cohortes hebdomadaire, réentraînement de modèles. Le batch nocturne n'est pas un compromis ici ; c'est l'ingénierie *correcte*.

L'erreur que font les CDO est de traiter la courbe de décroissance de valeur comme une propriété de la *donnée* (« les transactions sont importantes, donc elles doivent être en temps réel »). **C'est une propriété de la *décision qui consomme la donnée***. Le même enregistrement de transaction alimente un contrôle antifraude à décroissance en falaise *et* un rapport de revenus trimestriel à décroissance plate, depuis la même source. L'un exige du streaming ; l'autre ne doit surtout pas en utiliser.

Le coût total de la latence

La Ferrari n'est pas seulement chère à l'achat. Elle est chère à *posséder*, et ce coût de possession est précisément là où la plupart des business cases de CDO mentent discrètement.

Les systèmes batch ont un mode de défaillance indulgent : un job meurt à 2 h du matin, vous êtes alerté, vous le relancez, et à 6 h le monde est identique. Relances idempotentes, checkpoints clairs, backfills faciles. Les systèmes streaming n'ont pas cette clémence. Ils échouent en continu et en vol, ce qui introduit des catégories de coûts qui n'apparaissent jamais sur le slide d'architecture initial :

• Sémantique exactly-once. Garantir que chaque événement est traité une fois, pas zéro, pas deux, en cas de défaillance partielle, est réellement difficile. Se tromper, c'est des clients débités deux fois ou des métriques comptées deux fois.
• Événements désordonnés et en retard. Les vrais flux d'événements n'arrivent pas dans l'ordre. Il vous faut du watermarking et une logique de fenêtrage pour décider combien de temps attendre les retardataires avant de fermer une fenêtre, un arbitrage entre exhaustivité et latence qui n'a pas de réponse gratuite.
• Backpressure et replay. Quand un consommateur en aval ralentit, tout le pipeline doit se dégrader proprement, sinon vous perdez de la donnée. Se remettre d'un bug signifie rejouer depuis un offset, ce qui suppose d'avoir conservé le flux brut.
• La réalité de l'astreinte. Le streaming est un engagement opérationnel 24/7. Un batch nocturne a une fenêtre de maintenance ; un flux ne dort jamais. Budgétez la rotation d'astreinte et le burnout, pas seulement le cluster.

Une heuristique utile, issue des équipes qui ont fait les deux : un pipeline streaming en production coûte environ 3 à 5 fois l'effort opérationnel total d'un pipeline batch équivalent dès lors qu'on inclut l'astreinte, la complexité de test et la prime sur les talents spécialisés. Ce multiplicateur est votre taux de rendement minimal. Le cas d'usage streaming doit générer au moins 3 à 5 fois la *valeur de décision* de l'alternative batch pour atteindre l'équilibre, avant d'avoir gagné un dollar de gain.

Cela recadre le business case. La question n'est pas « pouvons-nous nous permettre de construire du streaming ? ». C'est « la valeur de décision marginale apportée par des données plus fraîches franchit-elle un multiple de coût de 4x ? » Pour la fraude, le pricing dynamique à grande échelle ou la personnalisation en temps réel sur un site à fort trafic, oui sans hésiter. Pour un dashboard ops interne consulté deux fois par jour, presque jamais.

Le juste milieu du micro-batch

La plupart des CDO posent le sujet en binaire. Il ne l'est pas. Le micro-batch, c'est-à-dire exécuter des jobs batch à intervalles serrés (toutes les 1, 5 ou 15 minutes), capte l'essentiel du bénéfice de fraîcheur du streaming tout en conservant la santé opérationnelle du batch : les relances restent faciles, la sémantique est plus simple, et vous gardez une posture de maintenance normale.

Le signal architectural est simple :

# Micro-batch : sémantique batch conservée, cadence quasi temps réel.
# Vous gardez les relances idempotentes et un checkpointing simple.
spark.readStream \
    .format("delta") \
    .load("/events/transactions") \
    .writeStream \
    .trigger(processingTime="5 minutes") \
    .foreachBatch(upsert_to_warehouse) \
    .start()

Passez processingTime à "1 minute" et vous serrez la vis ; mettez availableNow=True et vous êtes revenu au batch planifié, *avec le même code*. C'est tout l'intérêt : le micro-batch vous permet d'ajuster le curseur de fraîcheur sans vous engager sur tout le poids opérationnel du streaming continu. Une large part des cas d'usage étiquetés « temps réel » dans les documents d'exigences sont entièrement satisfaits par un micro-batch de 5 minutes. Ne partez sur du vrai streaming événement par événement que lorsque la courbe de décroissance de valeur est une véritable falaise *et* que votre latence d'action peut réellement exploiter une fraîcheur inférieure à la minute.

Prendre la décision lundi matin

Voici la séquence à dérouler quand un stakeholder exige du « temps réel ».

1. Imposez la conversation sur la latence de décision. Demandez : « Quand cette donnée est plus fraîche, quelle décision précise change, qui la prend, et à quelle fréquence ? » S'ils ne peuvent pas nommer la décision, l'exigence est une aspiration, pas un besoin. Neuf fois sur dix, « temps réel » veut dire « j'en ai assez des dashboards périmés », un problème de qualité de données ou de fréquence de rafraîchissement, pas un problème de paradigme.

2. Trouvez la contrainte déterminante. Cartographiez les trois composantes de latence. Si la latence d'action (une validation humaine, un processus physique, un job nocturne en aval) domine, la fraîcheur en amont est perdue. Le verrou de réapprovisionnement du distributeur rendait cela évident après coup ; rendez-le évident *en amont*.

3. Chiffrez la valeur de décision. Estimez la valeur incrémentale d'agir N minutes plus tôt. La fraude a un chiffre propre : des dollars de pertes évitées par minute de détection plus rapide. Le pricing dynamique : le gain de revenu par cycle de pricing. Si le chiffre est flou ou faible, vous avez votre réponse.

4. Appliquez le multiplicateur. La valeur de décision franchit-elle la barre des 3 à 5x de coût opérationnel par rapport à l'alternative micro-batch ? Sinon, livrez le micro-batch et passez à la suite.

5. Choisissez par défaut le paradigme le plus simple. En cas d'incertitude réelle, prenez l'option la moins complexe. Vous pourrez toujours resserrer un intervalle de micro-batch ou promouvoir un pipeline vers le streaming plus tard. Démonter une stack streaming surdimensionnée dont trois équipes dépendent désormais est un cauchemar politique et technique.

La vision portefeuille

Vous ne choisissez pas *un* paradigme pour l'organisation. Vous gérez un portefeuille, et l'architecture gagnante fait généralement tourner les deux sur les mêmes données source, ce pattern que vous connaissez sous le nom de conception à deux voies, où une couche de service rapide traite les décisions à décroissance en falaise et une couche batch produit l'enregistrement de référence, réconcilié.

La discipline du CDO, c'est le placement : décider quel cas d'usage se pose sur quelle voie, et refuser que l'enthousiasme des ingénieurs ou la mode dirigeante n'entraîne des charges à décroissance plate sur une infrastructure coûteuse. Tenez un registre simple : pour chaque produit dataproduit dataUn actif de données géré comme un produit : un owner, des utilisateurs identifiés, une qualité garantie et une valeur business mesurable.Voir la définition complète → majeur, consignez sa forme de décroissance, sa contrainte déterminante, le paradigme retenu et la valeur de décision qui le justifie. Relisez-le quand quelqu'un demande une montée en gamme. Cela transforme « est-ce que ça doit être en streaming ? » d'un argument émotionnel récurrent en un arbitrage gouverné, fondé sur des preuves.

Un dernier piège à nommer : le théâtre de la fraîcheur. Les dirigeants adorent une tuile de dashboard qui s'incrémente chaque seconde. Ça *fait* moderne. Cela pousse un investissement streaming détaché de toute décision. Quand vous voyez une visualisation temps réel dont la décision sous-jacente bouge une fois par jour, vous regardez du coût déguisé en capacité. Supprimez-la, ou rétrogradez-la en micro-batch, et redéployez l'économie vers un cas d'usage qui vit sur la falaise.

Quand le batch est le choix le plus courageux

Il y a une dimension culturelle que les dirigeants sous-estiment. Dans beaucoup d'organisations data, choisir le batch est lu comme choisir d'être *en retard*. Les ingénieurs ambitieux veulent du streaming sur leur CV ; les éditeurs le vendent comme un prérequis ; le conseil d'administration a lu un papier de McKinsey sur l'entreprise temps réel. La pression ne va que dans un sens.

Défendre une décision batch, ou rétrograder une ambition streaming en micro-batch, demande plus de courage organisationnel que de valider la solution qui brille. Mais c'est fréquemment l'arbitrage le plus lucide. La leçon des 12 M$ du distributeur n'était pas un échec technologique ; chaque composant fonctionnait comme prévu. C'était un échec de placement et un échec de courage : personne d'assez haut placé n'a demandé si la décision alimentée par le pipeline bougeait réellement assez vite pour le justifier.

Votre crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →édibilité de CDO se construit en partie sur votre capacité à dire non à des choses sophistiquées pour des raisons peu sophistiquées. Quand vous refusez de passer une charge en streaming, documentez la logique de latence de décision et le multiplicateur de coût. Cette trace écrite convertit un choix « conservateur » en un choix défendable et quantifié, et vous protège quand le cycle de mode tournera et que quelqu'un demandera pourquoi l'entreprise n'est pas « temps réel partout ».

Le courage inverse compte aussi. Quand un cas d'usage vit réellement sur la falaise, fraude, sécurité, real-time bidding, et que quelqu'un veut économiser en le forçant sur du batch nocturne, vous devez vous battre dans l'autre sens avec la même énergie. Priver de fraîcheur un cas d'usage à décroissance en falaise n'est pas de la frugalité ; c'est livrer un système de contrôle qui arrive après l'événement qu'il était censé prévenir. C'est pire que de ne rien construire, parce que cela crée une fausse confiance.

Points clés

• Alignez la latence sur la latence de décision, pas sur l'ambition. N'achetez de la fraîcheur que jusqu'à ce qu'elle cesse d'être la contrainte déterminante parmi la fraîcheur des données, la cadence de décision et la latence d'action. Passé ce point, chaque dollar de latence rapporte zéro.

• Classez par forme de décroissance de valeur, par décision, pas par jeu de données. Décroissance en falaise → streaming. Décroissance linéaire → micro-batch. Plateau puis chute → batch. La même source alimente des décisions différentes sur des voies différentes ; faites du placement votre discipline centrale de CDO.

• Appliquez le multiplicateur de coût de 3 à 5x comme taux de rendement minimal. Le vrai coût du streaming, sémantique exactly-once, gestion du désordre, replay, astreinte 24/7, représente plusieurs fois celui d'un équivalent batch. Le cas d'usage doit franchir ce multiple en valeur de décision incrémentale avant que vous ne vous engagiez.

• Choisissez le micro-batch par défaut en cas d'incertitude. Un intervalle de 5 minutes satisfait la plupart des exigences « temps réel » avec une santé opérationnelle de niveau batch, et le même code s'ajuste du batch planifié au quasi temps réel. Ne passez au vrai streaming que pour les véritables falaises.

• Tuez le théâtre de la fraîcheur, et ayez le courage de défendre le batch. Un dashboard temps réel qui alimente une décision quotidienne est du coût déguisé en capacité. Documentez la logique de latence de décision derrière chaque choix de paradigme, pour qu'un arbitrage conservateur devienne un arbitrage quantifié et défendable.