Le prochain voyage des applications : extraire de la valeur d’un océan de données

Ken Arora

« Les données sont le nouveau pétrole » ou « Les données sont le lubrifiant de l’économie numérique. » Si vous êtes comme moi, vous avez probablement entendu ces expressions, voire celle, plus typique des écoles de commerce, de « monétisation des données résiduelles », au point qu’elles en sont devenues des clichés. Mais comme tous les bons clichés, elles reposent sur une vérité fondamentale ou, dans ce cas, sur deux vérités complémentaires. La première est que les données générées comme sous-produit des processus opérationnels courants recèlent bel et bien une valeur latente. La seconde, qui lui est liée mais reste souvent passée sous silence, est que le processus intensif visant à extraire cette valeur latente constitue un parcours en plusieurs étapes, jalonné toutefois de phases naturelles de progression et de maturité.

Avec un peu de recul, le concept consistant à exploiter les données issues des opérations pour en tirer de la valeur commerciale n’est certainement pas nouveau. En effet, les secteurs qui dépendent de l’optimisation de la logistique, comme la grande distribution alimentaire et la livraison, ont compris et adopté ce concept depuis longtemps. De même, la tendance actuelle des entreprises en faveur de la « transformation numérique » constitue une généralisation de cette idée, généralement appliquée en premier lieu aux processus métier et aux flux de travail internes. Il convient de souligner qu’une évolution analogue est à l’œuvre dans le domaine des applications et des services applicatifs. Dans cet article, je souhaite examiner comment l’évolution des applications et des services applicatifs interagit et s’accorde avec la grande tendance de fond que constitue l’extraction de valeur à partir des données, où en est aujourd’hui cette symbiose et, enfin, vers quoi elle se dirige dans un avenir proche.

Étape 1 : Collecter et signaler

Ce parcours commence par la collecte des données. Il est utile de considérer les données comme le carburant du système : sans carburant, impossible d’alimenter les moteurs qui effectuent le travail. À première vue, cela semble être un fait accompli, puisque les solutions de services applicatifs mettent à disposition une multitude d’événements et de statistiques concernant la sécurité, la fiabilité, la gestion des performances et l’orchestration. Cependant, les données sont souvent non structurées, leur syntaxe varie et leur sémantique est souvent définie au cas par cas. Prenons un exemple simple, mais courant : comment la notion de temps est-elle représentée dans vos données ? En général, un concept aussi simple qu’un horodatage peut être représenté de nombreuses façons. Cela illustre la nécessité d’une lingua franca, c’est-à-dire d’une représentation commune des « atomes » élémentaires qui décrivent les événements et les statistiques. En termes techniques, on parle d’« ingestion de données », fondée sur un schéma de données cohérent et faisant appel, si nécessaire, à des adaptateurs ou des traducteurs. Historiquement, ce besoin a été l’un des principaux moteurs de la croissance et de la création de valeur des fournisseurs de solutions SIEM, qui y ont répondu en proposant ce vocabulaire normalisé afin d’offrir une vue d’ensemble de la sécurité couvrant une multitude de solutions de sécurité spécialisées. La capacité à produire une présentation intégrée des données — un compte rendu factuel, structuré et global de ce qui se passe actuellement et de ce qui s’est passé auparavant — correspond à l’étape du parcours où se trouve aujourd’hui la majeure partie du secteur. Dans l’écosystème applicatif actuel, cette étape est principalement incarnée par les segments de marché du SIEM et de l’APM.

Étape 2 : synthétiser et décrire

L’étape suivante consiste à donner du sens aux témoignages recueillis : rechercher des points communs, synthétiser les données sous forme de modèles descriptibles et repérer les anomalies. Compte tenu du volume de données concerné, les humains sont généralement assistés par des ordinateurs, qui viennent renforcer leurs capacités dans cette tâche. Cette assistance peut prendre la forme de techniques avancées de classification statistique, souvent non supervisées, parfois complétées par une exploration et une visualisation des données guidées par l’humain.

Dans le domaine de la lutte contre les attaques par déni de service (DoS), on peut notamment citer la visualisation de l’origine géographique du trafic entrant, souvent utilisée pour repérer le trafic malveillant provenant d’un nombre restreint de pays. Autre exemple : les outils d’analyse du comportement des utilisateurs (« UBA »), qui caractérisent les attributs propres aux comportements humains par rapport à ceux des robots. Ces solutions s’appuient souvent sur une analyse statistique pour évaluer la probabilité qu’une interaction sur le Web provienne d’un être humain.

Cette étape du parcours — « Synthétiser et décrire » — constitue une évolution par rapport à l’étape précédente, « Collecter et rendre compte ». Elle repose toujours fondamentalement sur un vaste ensemble de données structurées auquel appliquer l’analyse. Comme indiqué précédemment, cette approche sert de fondement à certaines des solutions ponctuelles les plus récentes (bien que très ciblées) en matière de sécurité des applications.

Étape 3 : Déduire et prédire

La troisième étape de ce parcours consiste à aller au-delà de l’analyse sommaire « Synthétiser et décrire » pour tirer des conclusions analytiques plus approfondies, qui aboutissent à des prédictions et à des prévisions concernant les observations futures attendues. La solution ne se contente ainsi plus d’être purement réactive : elle extrapole intelligemment les comportements futurs attendus. Dans le domaine de l’infrastructure applicative, on peut notamment citer la gestion des performances des applications (APM), qui consiste à identifier des tendances comportementales dans le temps et à les utiliser pour prévoir les besoins futurs en ressources. Autre exemple relevant de la logique métier d’une application : les sites de voyage utilisent des techniques de machine learning (« ML ») pour prévoir l’offre et la demande concernant des itinéraires précis à des dates ultérieures. Les technologies employées ici sont le plus souvent des technologies d’analyse avancée, notamment celles fondées sur les séries chronologiques et les techniques de régression linéaire, qui s’appuient sur les tendances dégagées à l’étape précédente.

Étape 4 : Raisonner et prescrire

La quatrième et dernière étape consiste à « boucler la boucle » afin de mettre en œuvre des ajustements et des mesures correctives applicables à l’ensemble du système. L’analyse issue des deux étapes précédentes est traduite en un ensemble de recommandations proactives. À ce stade, le système devient adaptatif et résilient face aux attaques et aux évolutions de son environnement. Par exemple, une infrastructure applicative théorique exploitant cette capacité pourrait créer ou supprimer de manière proactive des instances de charge de travail conteneurisées en fonction de la demande prévue. Dans le contexte de la sécurité des applications, elle pourrait également filtrer de manière proactive le trafic généré par des botnets en s’appuyant sur les comportements de ces derniers précédemment assimilés. Il existe déjà aujourd’hui un exemple notable dans le domaine de la logique métier : la tarification dynamique, qui repose là encore sur l’anticipation de l’offre et de la demande.

La technologie sous-jacente repose souvent sur des règles, qui servent à traduire les prédictions en actions. Toutefois, dans le contexte des infrastructures et des services applicatifs, cette approche est souvent associée à des directives de configuration et d’orchestration davantage fondées sur l’intention ou de nature déclarative.

Accélérer la transition

Ce parcours — de « Collecter et rendre compte » à « Extraire et décrire », puis à « Déduire et prédire » et enfin à « Raisonner et préconiser » — constitue une progression naturelle. Chaque avancée progressive s’appuie sur les précédentes et ouvre la voie à un niveau de valeur inédit et plus pertinent. Aujourd’hui, les solutions proposées pour relever les défis liés aux infrastructures et aux services applicatifs présentent des degrés de maturité inégaux tout au long de ce processus d’extraction de valeur à partir des données et sont généralement mal intégrées à la multitude de solutions ponctuelles.

L’étape préalable indispensable — le « carburant » proverbial du « moteur » de données — consiste à gagner en visibilité sur un large éventail de services applicatifs. Cette instrumentation, déployée à plusieurs endroits de la chaîne de livraison des applications et associée aux principes d’une sémantique des données cohérente et de référentiels de données fédérés, est l’un des moyens par lesquels F5 accélère sa progression vers l’avenir des services applicatifs. Nous entendons accélérer encore notre rythme afin d’apporter de la valeur à nos clients, à la fois en élargissant l’entonnoir de données pour permettre une meilleure intégration des solutions ponctuelles et en accélérant le développement avancé des briques technologiques pertinentes.

Dans de prochains articles, j’espère approfondir l’architecture guidée par les données, à la fois en examinant de plus près les technologies fondamentales qui la sous-tendent et en prenant du recul pour étudier les interactions entre plusieurs écosystèmes de données au sein de multiples pipelines de données souverains.

À propos de l’auteur

Ken Arora

Autres articles de Ken Arora