Par Andrew Tan
La démo qui n'a pas abouti
Nous étions à dix-huit mois de la construction de layline.io lorsque nous avons eu notre premier prospect sérieux dans le secteur des entreprises. Une entreprise de logistique du Fortune 500. Leur équipe de données avait examiné notre architecture, apprécié l'approche batch-plus-streaming, et programmé un atelier d'une journée pour approfondir le sujet.
Nous nous sommes préparés pendant des semaines. Nous avons construit une démo qui montrait tout : traitement d'événements complexes, gestion automatique de backpressure, évolution des schémas. C'était, selon toutes les définitions classiques, une architecture de bonnes pratiques. Distribuée. Tolérante aux pannes. Conçue pour évoluer horizontalement. Le genre de système que l'on dessinerait sur un tableau blanc lors d'une conférence.
L'atelier s'est bien passé. Les ingénieurs ont posé de bonnes questions. Puis, dans les trente dernières minutes, l'architecte principal s'est penché en arrière et a dit quelque chose que je n'oublierai jamais : "C'est impressionnant. Mais nous exécutons tout sur un seul serveur avec des tâches cron, et ça fonctionne. Que gagnerions-nous réellement avec toute cette complexité ?"
J'avais une centaine de réponses prêtes. Scalabilité. Résilience. Pérennité. Mais je pouvais voir sur son visage qu'il ne demandait pas une comparaison technologique. Il me demandait de justifier pourquoi sa réalité actuelle — ennuyeuse, simple, fonctionnelle — était insuffisante.
Je ne pouvais pas. Pas honnêtement.
L'architecture que j'ai supprimée
Trois mois plus tard, j'étais dans une autre salle avec un autre client. Celui-ci était une fintech de taille moyenne. Ils avaient exploité un pipeline de streaming basé sur Kafka pendant deux ans. Il tombait constamment en panne. Ils avaient engagé des consultants, mis à niveau le matériel, réécrit leur logique de consommation deux fois. Le système était "correct" selon tous les manuels de systèmes distribués. C'était aussi un cauchemar à exploiter.
Lors de la réunion, leur ingénieur principal m'a montré le diagramme d'architecture. C'était magnifique. Douze microservices, trois couches de persistance différentes, un magasin de données opérationnelles personnalisé pour la gestion des états. Ils avaient suivi chaque modèle du blog Confluent et du livre de Martin Kleppmann.
"Et si," ai-je demandé, "vous écriviez simplement les événements dans un fichier et les traitiez par lots ?"
Il m'a regardé fixement. "Ce n'est pas... du streaming."
"Non," ai-je acquiescé. "Mais vous traitez de toute façon les événements toutes les heures parce que votre système en aval ne peut pas gérer les mises à jour en temps réel. Vous payez le coût opérationnel d'une architecture de streaming pour obtenir des sémantiques de batch."
Ils n'ont pas acheté layline.io ce jour-là. Mais six semaines plus tard, j'ai reçu un e-mail. Ils avaient supprimé toute l'architecture. Remplacée par un processus unique qui lisait des fichiers et écrivait dans une base de données. Une tâche cron, en gros. Leur latence p99 est passée de 200 ms à cinq minutes — ce qui n'avait pas d'importance car leur processus métier était quotidien. Leurs incidents opérationnels sont passés de trois par semaine à zéro. Leur équipe d'ingénierie est passée de la lutte contre les incendies à la livraison de fonctionnalités.
L'architecture "incorrecte" était meilleure parce qu'elle correspondait à leurs contraintes réelles, pas à leurs aspirations.
Le piège des bonnes pratiques
Voici ce que j'ai appris en 25 ans de construction et de vente d'infrastructure de données : les bonnes pratiques sont par définition dépendantes du contexte, mais elles sont commercialisées comme des vérités universelles.
L'architecture orientée streaming dont Netflix a besoin n'est pas l'architecture dont une entreprise SaaS de 50 personnes a besoin. L'approche des microservices qui permet à Amazon de déployer 10 000 fois par jour n'est pas ce dont votre équipe de quatre ingénieurs a besoin. Le cadre d'agents IA qui a levé 50 millions de dollars en financement VC n'est pas ce dont votre ETL basé sur cron a besoin.
Mais vous ne le sauriez pas en lisant le contenu de l'industrie. Chaque article de blog de fournisseur, chaque conférence, chaque plan d'architecture montre la même progression : commencez simple, puis "évoluez" vers la complexité à mesure que vous grandissez. L'implication est claire : simple, c'est pour les débutants. Complexité, c'est pour les praticiens sérieux.
C'est à l'envers. La complexité est une responsabilité qui devrait être ajoutée à contrecœur, pas un insigne d'honneur à rechercher avec empressement.
À quoi ressemble réellement "ce qui fonctionne pour nous"
J'ai commencé à poser une question différente aux clients lors des premières conversations : "Quelle est la chose la plus simple qui pourrait fonctionner pour votre charge de travail réelle ?" Pas votre charge de travail projetée dans trois ans. Pas votre cas d'utilisation en temps réel aspirant que le PDG a mentionné une fois. Votre charge de travail réelle, aujourd'hui.
Les réponses sont constamment surprenantes :
- Une entreprise de santé traitant un million de dossiers de patients par jour le fait avec un script Python monothread qui s'exécute pendant quatre heures chaque nuit. Il fonctionne depuis six ans sans modification. Pourquoi ? Parce que les dossiers arrivent via FTP à 2h du matin, et les médecins ne regardent les tableaux de bord qu'à 8h.
- Une entreprise de vente au détail traitant les données de point de vente de 2 000 magasins utilise un cluster Kafka à trois nœuds. Pas parce qu'ils ont besoin du débit — ils pourraient loger les événements d'une journée dans un seul fichier — mais parce que leur équipe existante connaissait Kafka et n'avait pas le temps d'apprendre quelque chose de nouveau pendant leur saison la plus chargée.
- Une entreprise de logistique suivant les navires porte-conteneurs en temps réel utilise... une feuille de calcul. L'équipe des opérations la met à jour manuellement. Ils ont essayé de construire un pipeline automatisé deux fois. Les deux fois, le système automatisé a échoué de manière plus difficile à déboguer que la feuille de calcul. La feuille de calcul est "incorrecte" de douzaine de manières, mais elle est inspectable incorrecte. Vous pouvez voir les erreurs.
Aucune de ces pratiques n'est une "bonne pratique". Toutes sont correctes pour leur contexte.
Le cycle de battage médiatique des agents IA
Si vous voulez voir le piège des bonnes pratiques sous sa forme la plus agressive, regardez comment l'industrie de l'ingénierie des données réagit actuellement aux agents IA.
Chaque blog concurrent que je lis dernièrement — Airbyte, Confluent, Kestra — positionne leur produit comme "prêt pour les agents IA". Il y a des plongées profondes sur le protocole de contexte de modèle, les ontologies pour les agents, la gestion des fenêtres de contexte. Le message implicite : si vous n'architectez pas pour les agents IA en ce moment, vous prenez du retard.
J'ai demandé à un client la semaine dernière s'ils envisageaient des agents IA pour leurs pipelines de données. "Nous avons passé six mois à essayer de faire générer du SQL par un LLM," a-t-il dit. "Il était précis à 70% sur les requêtes simples et à 30% sur les complexes. Les 30% étaient suffisamment subtils pour que nous ne les remarquions pas jusqu'à ce que le PDG voie un mauvais chiffre dans un rapport de conseil d'administration. Nous sommes revenus aux ingénieurs écrivant du SQL."
Ce n'est pas un argument contre l'IA. C'est un argument contre le fait de se tourner par défaut vers l'IA parce que c'est la pratique actuelle. Les équipes qui bénéficient des agents IA aujourd'hui ont des caractéristiques spécifiques : volumes de requêtes élevés, schémas relativement simples, tolérance aux erreurs occasionnelles, et ressources en ingénierie pour valider les résultats. Si cela ne décrit pas votre situation, les agents IA ne sont pas encore votre solution — peu importe combien de posts de blog de fournisseurs suggèrent le contraire.
Comment évaluer réellement la technologie
Alors si les "bonnes pratiques" ne sont pas un guide fiable, qu'est-ce qui l'est ?
Voici le cadre que j'utilise maintenant, à la fois pour mes propres décisions architecturales et lorsque je conseille des clients :
Commencez par vos contraintes réelles. Combien de données ? Quels schémas d'arrivée ? Quelles exigences de latence ? Quelle taille et expertise de l'équipe ? Quel budget pour les opérations ? Les réponses à ces questions éliminent immédiatement 90% des architectures "standard de l'industrie".
Optimisez pour le débogage, pas pour l'élégance. L'architecture qui produit des diagrammes propres est souvent celle qui est la plus difficile à déboguer à 2h du matin. Préférez les systèmes où vous pouvez tracer un seul enregistrement de la source à la destination sans traverser trois couches d'abstraction différentes.
Mesurez le coût opérationnel en attention de l'équipe, pas seulement en dollars d'infrastructure. Un système distribué qui fonctionne de lui-même mais nécessite qu'un ingénieur senior soit d'astreinte est plus coûteux qu'un serveur unique qui nécessite des redémarrages occasionnels mais peut être géré par une recrue junior.
Planifiez la migration que vous ferez réellement, pas celle que vous devriez faire. Chaque équipe a des systèmes hérités qu'elle ne retirera jamais. Concevez pour une coexistence harmonieuse avec la vieille technologie plutôt qu'un remplacement révolutionnaire de celle-ci.
En cas de doute, commencez par l'ennui. Vous pouvez toujours ajouter de la complexité. La supprimer est beaucoup plus difficile. Les équipes que je vois réussir sont celles qui ajoutent de la technologie à contrecœur, avec des preuves claires que les approches plus simples ont été épuisées.
L'argument contraire que je ne fais pas
Je veux être clair sur ce que je ne dis pas. Je ne plaide pas pour le conservatisme technique ou contre l'essai de nouvelles choses. Certains problèmes nécessitent réellement des architectures complexes, distribuées, en temps réel. Si vous traitez des paiements à grande échelle, vous avez besoin de sémantiques exactement-une-fois. Si vous servez des fonctionnalités ML avec une latence inférieure à 100 ms, vous avez besoin de streaming. Si vous êtes Netflix, vous avez besoin de ce dont Netflix a besoin.
Mais la plupart des entreprises ne sont pas Netflix. La plupart des pipelines de données n'ont pas besoin de gérer 10 000 événements par seconde. La plupart des équipes n'ont pas un groupe d'ingénierie de plateforme pour gérer le fardeau opérationnel de l'infrastructure de données "moderne".
La vérité inconfortable est que l'industrie a confondu "ce que font les entreprises technologiques à succès" avec "ce que vous devriez faire". Les entreprises technologiques à succès ont des ressources d'ingénierie infinies, une grande tolérance à la douleur opérationnelle, et des modèles commerciaux qui nécessitent tout en temps réel. Votre entreprise probablement pas. Votre architecture ne devrait pas prétendre le contraire.
Où layline.io s'intègre (et où il ne s'intègre pas)
Je vais conclure avec quelque chose qui pourrait vous surprendre : layline.io n'est pas le bon choix pour chaque problème d'intégration de données.
Si vous avez quelques tâches batch qui fonctionnent de manière fiable selon un calendrier, et que votre équipe est à l'aise avec votre configuration actuelle, vous n'avez probablement pas besoin de nous. Sérieusement. La surcharge opérationnelle d'apprendre une nouvelle plateforme n'en vaut pas la peine si votre réalité actuelle est stable et comprise.
Là où nous ajoutons de la valeur, c'est lorsque vous avez dépassé les approches simples mais que vous voulez éviter la taxe de complexité de l'assemblage de plusieurs outils spécialisés. Lorsque vous avez besoin à la fois de batch et de streaming dans le même système. Lorsque votre équipe est fatiguée de maintenir des couches distinctes d'orchestration, de transformation et de surveillance. Lorsque vous voulez vous consolider autour d'un modèle au lieu de gérer une couture de coordination entre trois outils différents.
Même alors, je préférerais que vous commenciez par une preuve de concept qui traite les données d'une seule journée plutôt qu'un plan de migration ambitieux. Prouvez que l'approche plus simple fonctionne pour votre charge de travail réelle avant de vous engager dans la complexe.
La meilleure pratique est celle qui fonctionne pour vous. Tout le reste n'est que marketing.
Si vous évaluez l'infrastructure de données et souhaitez une évaluation honnête de la complexité qui vaut réellement la peine d'être ajoutée pour votre situation spécifique, contactez-nous. Nous vous dirons si vous avez besoin de nous ou si vous devriez garder vos tâches cron.
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.
