Pour offrir plus de réactivité et de personnalisation aux consommateurs de Data Products, Confluent promeut un usage temps réel de l’ensemble des données disponibles. Un challenge loin d’être seulement technique. Explications de Rémi Forest, Responsable Solutions Engineering.

>> Cet entretien est issu du Guide à télécharger « Data & IA for Business : objectifs impact et valeur »

Que signifie le concept de Data in Motion porté par Confluent ?

Il vise à souligner un changement de paradigme. D’un point de vue utilisateur, les besoins traduisent des attentes en faveur d’une plus grande réactivité et personnalisation. Leur satisfaction implique une utilisation de toute la donnée à disposition et en temps réel, ou en tout cas dès lors qu’elle est disponible.

Cette approche illustre bien une opposition par rapport aux usages traditionnels de la data. Jusqu’à présent, la donnée at rest était stockée en base, interrogée uniquement en cas de besoin.

Avec la Data in Motion, on renverse cette logique. Ce n’est plus l’utilisateur qui vient interroger une donnée statique. Non, c’est la donnée qui circule au sein du SI. Une fois générée, elle est automatiquement poussée vers l’ensemble des systèmes pertinents, qui déclencheront des actions ou des notifications auprès des utilisateurs ou d’autres systèmes.

A lire aussi : SAS : Le vrai sujet Data ? Le passage à l’échelle

A quels types de cas d’usage est-il ainsi possible de répondre ?

La détection de fraude est un exemple de cas d’usage très fréquent. C’est devenu standard aujourd’hui. Lors de la réalisation d’une transaction par carte bancaire, l’approbation est faite et une notification par SMS est envoyée. Il y a peu de temps encore un incident sur une transaction pouvait n’être signalé qu’après plusieurs jours.  

Des applications de ce type se retrouvent également dans l’e-commerce ou la relation client afin par exemple d’éviter de proposer un produit qui vient d’être acheté ou redemander des données déjà saisies par l’utilisateur. Les données existent déjà. Elles doivent “juste” être acheminées, ce qui n’est pas simple, notamment à l’échelle des entreprises actuelles.

Quelle est la valeur ou ROI du temps réel, notamment pour la prise de décision ?

Je vois deux axes en termes de valeur. Le premier est lié au business, c’est-à-dire l’incrément de revenu qui peut être généré, ou par les économies découlant de l’automatisation de certains processus qui se traduira par un ROI direct.

Cependant, il ne faut pas négliger un enjeu plus stratégique et même de survie. Une incapacité à fournir une expérience client du niveau de celle offerte par les digital natives constitue tout simplement un risque pour l’existence même d’une entreprise.

Et si les pure players parviennent à garantir une expérience optimale, ce n’est pas par magie. Certe ils disposent d’énormément de données, mais les entreprises traditionnelles aussi. La différence repose essentiellement dans leur capacité à s’appuyer ces données, et notamment sur des systèmes qui favorisent la circulation de ces données au sein de l’organisation. Cela permet de libérer l’innovation et de proposer de nouveaux services toujours plus performants.

Quels sont les prérequis pour construire un système temps réel et répondre à ces enjeux client ?

Cela relève de la transformation digitale. Et dans ce domaine, le challenge n’est pas technologique. Il est avant tout organisationnel. Des composants techniques comme Kafka et Confluent serviront donc le plan de transformation.

Surtout, ils permettent de s’affranchir des problématiques techniques liées à la collecte massive de données, à la persistance et à la diffusion de l’information. Cela rejoint le sujet du data mesh dont le principe est de rendre disponible la donnée en temps réel partout dans l’organisation et dans un cadre de gouvernance défini.  

Les cas d’usage que nous avons déployés chez Michelin par exemple soulignent cette capacité à casser les silos, tout en s’appuyant sur des environnements hybrides et interconnectés. Confluent dispose d’une riche bibliothèque de connecteurs permettant de se brancher à de nombreux applicatifs du marché pour alimenter la plateforme de streaming.

Pour Michelin, le premier projet portait sur la gestion de la logistique de transport des pneus entre usines et distributeurs. Pour ces opérations, l’industriel s’appuyait sur une architecture legacy avec des traitements en batch. Ils ont migré sur une architecture complètement temps réel basée sur Kafka, et ce de manière totalement transparente pour les utilisateurs.