Par Andrew Tan
La différence entre le quasi-temps réel et le véritable temps réel, et pourquoi cet écart coûte plus cher que vous ne le pensez
Le retard de 4,7 millions d'euros
Un grand détaillant européen a perdu 4,7 millions d'euros lors du Black Friday 2024. Pas parce que leur site web s'est planté. Pas parce qu'ils étaient en rupture de stock. Parce que leur système d'inventaire "en temps réel" avait quatre heures de retard.
340 000 clients ont passé des commandes pour des articles déjà épuisés. Le système montrait de la disponibilité. L'entrepôt n'en avait plus. Lorsque la divergence a été découverte, le mal était fait. Remboursements émis. Service client débordé. Réputation de la marque ternie. L'analyse post-mortem a révélé quelque chose de gênant : le pipeline n'a jamais été conçu pour le temps réel. Il était conçu pour le "quasi-temps réel", une distinction qui semblait technique lors des revues d'architecture et s'est avérée catastrophique en production.
J'ai entendu des versions de cette histoire des dizaines de fois. L'écart entre ce que promet le "temps réel" et ce que la plupart des systèmes livrent est plus large que la plupart des équipes ne le réalisent. Et il s'élargit, pas se rétrécit, à mesure que les attentes des clients s'accélèrent.
Comme un arrêt au stand de Formule 1, le traitement des données en temps réel nécessite précision, coordination et la bonne infrastructure.
Ce que signifie réellement "temps réel" (et ce que cela ne signifie pas)
L'industrie a embrouillé cette notion. Trois catégories sont confondues sous la même étiquette.
Le traitement par lots signifie des heures ou des jours entre les mises à jour. Votre tâche ETL nocturne. Votre rapport hebdomadaire. Des limites claires, des fenêtres prévisibles, des modes de défaillance bien compris.
Le quasi-temps réel signifie des minutes entre les mises à jour. Le système vérifie toutes les cinq, quinze, trente minutes. La plupart des "tableaux de bord en temps réel" se situent ici. Bien pour de nombreux cas d'utilisation. Pas bon pour ceux qui comptent le plus.
Temps réel signifie des secondes ou des sous-secondes. L'événement se produit. Le système le sait. L'action en aval se déclenche immédiatement.
Le détaillant n'avait pas un problème de temps réel. Ils avaient un système en quasi-temps réel commercialisé comme temps réel, et personne n'a remis en question la différence jusqu'à ce que cela leur coûte quatre millions d'euros.
Trois forces motrices du changement
L'effet Amazon. Les clients s'attendent à tout instantanément. Pas parce qu'ils ont analysé les exigences techniques. Parce que c'est ce à quoi ils ont été formés à s'attendre. Une étude Shopify de 2022 sur 12 000 consommateurs a révélé que 73 % s'attendent à des mises à jour en temps réel pour le paiement, l'inventaire et l'expédition. Pas "dans l'heure". En temps réel.
Les fenêtres opérationnelles se rétrécissent. La détection de fraude après la transaction n'est pas une détection. C'est une notification. L'argent est déjà parti. Les lignes de fabrication qui attendent des rapports de qualité par lots produisent des unités défectueuses pendant des heures avant que quelqu'un ne s'en aperçoive. Le coût du retard se multiplie plus vite que la plupart des feuilles de calcul ne le capturent.
Pression concurrentielle. Si votre concurrent met à jour ses prix toutes les trente secondes et que vous les mettez à jour toutes les six heures, vous ne faites pas concurrence. Vous êtes spectateur. Ce n'est pas théorique. Les plateformes de commerce électronique, les agrégateurs de voyages, les services financiers. Les entreprises qui gagnent dans ces domaines ont fait de l'infrastructure de données en temps réel une priorité stratégique, pas un simple atout technique.
La vitesse sans contrôle est dangereuse. Les systèmes en temps réel doivent gérer la vélocité tout en maintenant précision et fiabilité.
La complexité cachée
Passer du traitement par lots au streaming est plus difficile qu'il n'y paraît. La surface semble simple : au lieu d'attendre, réagir immédiatement. En dessous, tout change.
Gestion de l'état. Les tâches par lots traitent des ensembles de données bornés. Vous connaissez la taille de l'entrée lorsque vous commencez. Le streaming traite des flux non bornés. Vous devez suivre les fenêtres, gérer les données arrivant en retard, gérer l'état à travers des événements qui peuvent arriver dans le désordre.
Traitement exactement une fois. Exécutez une tâche par lots deux fois par accident ? Vous obtenez une sortie en double, vous la corrigez, vous passez à autre chose. Exécutez un pipeline de streaming deux fois ? Vous facturez les clients en double, comptez l'inventaire en double, notifiez les systèmes en double. Les sémantiques comptent de manières qu'elles ne faisaient pas auparavant.
Contre-pression. Que se passe-t-il lorsque votre source produit plus vite que votre puits ne peut consommer ? En traitement par lots, cela se manifeste par une tâche lente. En streaming, cela se manifeste par des messages perdus, des échecs en cascade, ou des systèmes qui cessent simplement de répondre.
Ce ne sont pas des cas limites rares. C'est le quotidien. Les équipes qui sous-estiment cette complexité finissent avec des pipelines qui fonctionnent en démo et échouent en production.
À quoi ressemble un bon système
Les systèmes en temps réel bien architecturés partagent des caractéristiques.
Résilience par défaut. Pas ajoutée après coup. Le système s'attend à ce que des composants échouent et continue de fonctionner. Disjoncteurs. Dégradation gracieuse. Files d'attente bornées qui réduisent la charge plutôt que de planter.
Observable. Vous devez voir ce qui se passe à l'intérieur d'un pipeline qui traite des milliers d'événements par seconde. Des métriques qui comptent. Une traçabilité qui suit les événements à travers le système. Des alertes qui se déclenchent sur les symptômes, pas seulement sur les défaillances de composants.
Prêt pour la croissance. Le système qui gère dix mille événements par minute devrait en gérer dix millions sans réécriture. Mise à l'échelle horizontale. Conception consciente des partitions. Aucun point de contention unique.
Accessible. L'intégration de données en temps réel ne devrait pas nécessiter un doctorat en systèmes distribués. Les outils existent. La documentation est claire. Les concepts sont apprenables. Les équipes devraient être productives en jours, pas en trimestres.
Ce dernier point compte plus que les autres. Les équipes qui réussissent avec l'infrastructure en temps réel ne sont pas celles qui ont la technologie la plus sophistiquée. Ce sont celles qui l'ont rendue suffisamment abordable pour que leurs équipes existantes puissent l'exploiter.
L'écart d'accessibilité
Un marché à deux niveaux se forme. Premier niveau : les entreprises avec des équipes dédiées au streaming, une expertise Kafka, des ingénieurs en infrastructure qui comprennent le rééquilibrage des partitions et les sémantiques exactement une fois. Deuxième niveau : tous les autres, coincés avec le traitement par lots parce que le temps réel semble trop complexe à tenter.
C'est à l'envers. L'intégration de données en temps réel devrait être aussi accessible que le traitement par lots. Même équipe. Même niveau de compétence. Même délai de mise en production. La technologie est là. Ce qui manque, c'est l'emballage. Des outils qui gèrent la complexité pour que les équipes n'aient pas à le faire.
Chez layline.io, nous construisons pour le deuxième niveau. Des Workflows unifiés qui gèrent à la fois le traitement par lots et le streaming avec les mêmes interfaces. Résilience et observabilité intégrées. Mise à l'échelle qui se fait automatiquement. Le but n'est pas de rendre le streaming simple. C'est complexe, et prétendre le contraire n'aide personne. Le but est de le rendre accessible.
Parce que les détaillants, les fabricants et les entreprises de services financiers qui ont besoin de données en temps réel ont déjà des équipes intelligentes. Ils n'ont pas besoin de personnes différentes. Ils ont besoin de meilleurs outils.
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 par lots et en temps réel à grande échelle.
