Par Andrew Tan
Les dépenses que personne n'inclut dans le budget de migration — et pourquoi le vrai coût du passage au temps réel n'a rien à voir avec les licences logicielles
Le budget qui n'a pas survécu au premier contact
Un VP de l'ingénierie que je connais avait budgété 180 000 $ pour la migration de son équipe du batch au streaming. C'était il y a douze mois. La dernière fois que nous avons parlé, le projet avait consommé 640 000 $ et ils étaient encore à six semaines de la production.
Que s'est-il passé ? Pas de fraude. Pas de dérive des objectifs au sens traditionnel. Ils ont simplement omis de prendre en compte les coûts qui n'apparaissent pas dans les devis des fournisseurs : le délai de six semaines pendant qu'ils embauchaient un ingénieur Kafka qui comprenait les sémantiques exactly-once. Les trois mois passés à exécuter batch et streaming en parallèle parce que personne ne faisait encore confiance au nouveau pipeline. L'engagement de conseil d'urgence lorsque leur agrégation en streaming a produit des chiffres différents du rapport batch et que le CFO l'a remarqué.
Le logiciel lui-même était bon marché. Les coûts cachés les ont dévorés.
J'ai vu ce schéma se répéter dans des entreprises de toutes tailles. Les équipes budgétisent pour l'infrastructure et les licences. Elles ne budgétisent pas pour l'incertitude, la reprise et la taxe opérationnelle de maintenir deux systèmes pendant qu'un remplace l'autre. Au moment où elles réalisent ce qui se passe, le projet est soit au-dessus du budget, soit sous-livré — parfois les deux.
Voici ce qui coûte réellement de l'argent lorsque vous passez du batch au streaming.
Coût n°1 : Le talent que vous n'avez pas encore
L'ingénierie batch et l'ingénierie stream sont liées de la même manière que la menuiserie et la fabrication de meubles. Même matière première, métier complètement différent.
Votre équipe actuelle connaît les horaires cron, les scans de table et la finalité rassurante d'un travail qui commence, s'exécute et se termine. Le streaming leur demande de penser en temps d'événement, de gérer un état illimité et de déboguer des systèmes qui ne s'arrêtent jamais. Certains de vos ingénieurs s'adapteront rapidement. D'autres non — pas parce qu'ils sont de mauvais ingénieurs, mais parce que le traitement de flux distribué est vraiment difficile et que tout le monde ne veut pas se spécialiser dans ce domaine.
Cela crée un coût caché sous trois formes :
Recrutement : Un ingénieur senior en traitement de flux à Londres ou à New York coûte actuellement entre 160 000 $ et 220 000 $ de salaire de base, plus le délai moyen de quatre mois pour embaucher cette spécialité. Si vous en avez besoin de deux, cela représente près d'un demi-million en salaires avant qu'ils n'aient écrit une ligne de code de production.
Formation : Vos ingénieurs actuels doivent apprendre de nouveaux concepts : le watermarking, le décalage des consommateurs, le déséquilibre des partitions, les opérateurs avec état, le at-least-once contre le exactly-once. Ce ne sont pas des sujets d'atelier d'après-midi. Ce sont des mois d'apprentissage pratique où la productivité est inférieure à la normale et les erreurs sont plus coûteuses que d'habitude.
Attrition : Certains de vos meilleurs ingénieurs batch partiront pendant la migration — pas parce qu'ils ne peuvent pas apprendre le streaming, mais parce qu'ils ne se sont pas inscrits pour devenir des spécialistes des systèmes distribués. Ils aimaient le travail de données. Ils iront là où cela se fait encore de la manière qu'ils apprécient.
La ligne budgétaire pour le "talent" dans la plupart des plans de migration couvre la formation. Elle couvre rarement les retards d'embauche, la perte de productivité ou le roulement inattendu.
Coût n°2 : La période d'opération parallèle
Personne n'en parle assez. Vous ne pouvez pas simplement éteindre le batch et allumer le streaming. Pas si vous tenez à votre emploi.
Pendant une certaine période — généralement de trois à six mois, parfois plus — vous ferez fonctionner les deux systèmes. Le pipeline batch continue de produire les rapports auxquels tout le monde fait confiance. Le pipeline streaming fonctionne à côté, produisant des résultats qui devraient théoriquement correspondre mais qui souvent ne le font pas, du moins pas au début.
Cela signifie le double de l'infrastructure. Le double de la surveillance. Le double des alertes. Et une équipe d'ingénieurs qui passent leurs journées à concilier deux ensembles de chiffres au lieu de créer de nouvelles fonctionnalités.
Une entreprise de commerce électronique avec laquelle j'ai travaillé a fait fonctionner des systèmes parallèles pendant huit mois. Leur pile batch coûtait environ 4 200 $ par mois en calcul Cloud. Leur pile streaming coûtait 7 800 $ par mois. Pendant huit mois, ils ont payé les deux. Cela représente 96 000 $ rien qu'en infrastructure — sans parler du temps d'ingénierie passé à enquêter sur la raison pour laquelle le décompte en streaming des commandes du mardi était de 347 de moins que le décompte batch.
La période parallèle n'est pas optionnelle. C'est une assurance. Mais comme toute assurance, elle est coûteuse, et la plupart des équipes sous-estiment la prime.
Coût n°3 : L'archéologie des données
Vos pipelines batch contiennent des années de logique métier accumulée. Quelque part dans un script Python de 400 lignes qui s'exécute à 2 heures du matin se trouve une condition de jointure qui existe en raison d'une exception de tarification de 2019. Personne n'a documenté pourquoi elle est là. La personne qui l'a écrite est partie en 2021. Mais si vous la supprimez, les chiffres de revenus changent de 0,3 % et la finance envoie des courriels furieux.
Migrer vers le streaming signifie comprendre chacun de ces artefacts. Vous ne pouvez pas simplement porter le code. La logique doit être réimplémentée pour le traitement continu des événements, ce qui signifie que vous devez d'abord comprendre ce qu'elle fait et pourquoi. C'est de l'archéologie des données — fastidieux, lent et impossible à estimer avec précision parce que vous ne savez pas ce que vous trouverez avant de commencer à creuser.
Une entreprise de services financiers que j'ai conseillée a passé cinq semaines sur un seul pipeline. La mise en œuvre en streaming a pris trois jours. Comprendre pourquoi la version batch produisait une sortie de cas particulier a pris les trente-deux autres jours. La logique métier était encodée dans une procédure stockée écrite par trois personnes différentes sur quatre ans, avec des commentaires comme "correction pour bug T2" et aucune autre explication.
Coût n°4 : La taxe de complexité opérationnelle
Les pipelines batch échouent visiblement. Un travail plante. Vous recevez une alerte. Vous le réparez. Vous le relancez. Tout le monde comprend ce qui s'est passé.
Les pipelines streaming échouent subtilement. Le décalage des consommateurs s'accumule sur des heures. Les magasins d'état grandissent jusqu'à atteindre les limites de mémoire. Les watermarks dérivent et soudainement vos agrégations fenêtrées laissent tomber des événements tardifs. Au moment où vous le remarquez, vous produisez des résultats légèrement erronés depuis une demi-journée.
Les outils opérationnels sont différents aussi. Vous ne surveillez pas seulement si un travail est terminé. Vous surveillez les distributions de latence, les pentes de débit, les signaux de backpressure et les tailles des magasins d'état. Vos runbooks existants ne s'appliquent pas. Vos alertes existantes ne capturent pas les nouveaux modes de défaillance.
Construire cette maturité opérationnelle prend du temps et des erreurs. La première fois que votre pipeline streaming laisse tomber silencieusement 2 % des événements pendant six heures, vous investirez massivement dans une meilleure observabilité. C'est un coût nécessaire. Mais il n'est presque jamais dans le budget initial.
Coût n°5 : Le coût d'opportunité que personne ne mesure
Pendant que vos meilleurs ingénieurs déboguent le rééquilibrage des partitions et concilient les sorties batch et streaming, ils ne font pas d'autres travaux. Les demandes de fonctionnalités s'accumulent. La dette technique s'accumule. Les concurrents livrent des choses que votre équipe aurait construites si elle n'était pas plongée dans la migration.
C'est le coût le plus difficile à quantifier et le plus facile à ignorer. Il n'y a pas de facture pour cela. Mais c'est réel.
Une entreprise SaaS a suspendu tout nouveau développement de produit de données pendant neuf mois lors de sa migration en streaming. Lorsqu'ils ont terminé, ils avaient construit un pipeline en temps réel techniquement impressionnant — mais leur principal concurrent avait livré trois fonctionnalités analytiques dans la même période et gagné des parts de marché. La migration a été un succès technique et un retard stratégique.
Pourquoi nous continuons à sous-estimer
Une partie du problème est le message des fournisseurs. Les plateformes de streaming vendent la destination : des insights en temps réel, des réactions instantanées, un avantage concurrentiel. Elles ne font pas la publicité du voyage : le recrutement, les systèmes parallèles, l'archéologie, la courbe d'apprentissage opérationnelle.
Une autre partie est le biais d'optimisme. Chaque équipe d'ingénierie croit qu'elle sera l'exception. Leur code est plus propre. Leur équipe est plus intelligente. Leurs exigences sont plus simples. Parfois c'est vrai. Souvent ça ne l'est pas.
Le résultat est un écart persistant entre le coût budgété et le coût réel. J'ai vu des ratios de 2:1, 3:1, voire 5:1. Pas parce que quelqu'un était malhonnête — parce que les coûts réels sont invisibles jusqu'à ce que vous vous soyez déjà engagé.
Comment budgétiser honnêtement
Vous ne pouvez pas éliminer ces coûts, mais vous pouvez en tenir compte. Voici comment je conseille aux équipes de l'envisager :
Ajoutez une marge de 40 % aux estimations d'infrastructure. La période parallèle, les environnements de test, les déploiements en ombre — ils ajoutent tous du calcul et du stockage que vous ne prédirez pas précisément.
Budgétisez pour six mois d'opération double minimum. Si vous terminez plus tôt, célébrez. Si ce n'est pas le cas, vous n'aurez pas à expliquer les dépassements à votre CFO.
Embauchez ou contractez un spécialiste du streaming avant de commencer, pas après vous être retrouvé coincé. Le coût de les faire venir tôt est élevé. Le coût de les faire venir après trois mois de faux départs est plus élevé.
Acceptez que certains pipelines doivent rester batch. Tout ne bénéficie pas du temps réel. Les rapports quotidiens, les analyses historiques, les pipelines de formation ML — ce sont souvent des charges de travail adaptées au batch qui ne justifient pas le coût de la migration. Soyez explicite sur ce que vous ne migrez pas.
Une autre façon de penser la transition
Les équipes qui gèrent cela bien partagent un trait : elles ne le considèrent pas comme une migration. Elles le considèrent comme l'ajout d'une capacité.
Au lieu de "nous passons du batch au streaming", elles disent "nous ajoutons le streaming là où il crée de la valeur, et nous gardons le batch là où il fonctionne encore." Cela ressemble à de la sémantique, mais cela change complètement l'économie. Vous n'êtes plus engagé à tout déplacer. Vous pouvez évaluer chaque pipeline sur ses propres mérites : exigences de latence, complexité, valeur commerciale, coût de migration.
Certains pipelines bougent. D'autres non. Ceux qui bougent justifient leur propre investissement. Ceux qui restent ne génèrent pas de coût inutile.
C'est là qu'une plateforme unifiée est importante. Si vous utilisez des outils séparés pour le batch et le streaming, chaque pipeline subit une pression pour migrer parce que maintenir deux plateformes est coûteux. Si vous pouvez exécuter les deux modèles sur la même plateforme — mêmes workflows, même équipe, même approche opérationnelle — la pression disparaît. Vous ajoutez le real-time streaming là où il est rentable et laissez le batch tranquille là où il fonctionne déjà.
C'est l'approche que nous avons intégrée dans layline.io. Pas parce que le batch est mauvais — il est souvent exactement ce qu'il faut — mais parce que forcer les équipes à choisir une approche et à abandonner l'autre crée des coûts et des risques artificiels. Les équipes qui dorment bien la nuit sont celles qui n'ont pas essayé de faire bouillir l'océan.
Conclusion
Le coût caché du passage du batch au streaming n'est pas le logiciel. C'est tout le reste : les personnes que vous devez embaucher, les systèmes que vous devez faire fonctionner en parallèle, la logique héritée que vous devez exhumer, la maturité opérationnelle que vous devez construire, et l'opportunité que vous perdez pendant que vous vous concentrez sur l'infrastructure au lieu du produit.
Budgétisez-le. Prenez-en compte. Soyez honnête sur les pipelines qui doivent réellement bouger et ceux qui ne le doivent pas.
L'objectif n'est pas d'être en temps réel partout. L'objectif est d'être en temps réel là où cela compte, sans vous ruiner pour y parvenir.
Et après
Si vous prévoyez une migration du batch au streaming, commencez par un audit honnête. Listez vos dix principaux pipelines. Pour chacun, demandez-vous : quel est le coût réel de la latence ? Quel est l'effort de migration estimé ? Quel est l'ajout de complexité opérationnelle ?
Si les chiffres ne justifient pas le déplacement pour un pipeline donné, laissez-le tranquille. Concentrez votre énergie sur les deux ou trois où le temps réel crée une valeur commerciale mesurable.
Pour les équipes évaluant les plateformes, la Community Edition de layline.io est gratuite à explorer. Vous pouvez prototyper un pipeline en streaming aux côtés de votre workflow batch existant et voir à quoi ressemble la réalité opérationnelle avant de vous engager dans le budget.
Essayez la Community Edition →
Andrew Tan est un entrepreneur en série et fondateur de layline.io, construisant une infrastructure de traitement de données d'entreprise qui gère à la fois les charges de travail batch et en temps réel à grande échelle.
