L’exploitation de la donnée passe avant tout par une phase de préparation et de nettoyage
Lorsque nous recueillons les besoins de nos clients, on entend souvent « Je veux faire de l’IA » ou « Je veux utiliser telle technique de machine learning ». Cette vision n’est que partielle car elle revient à confondre la fin et les moyens. La mise en place de tels outils repose avant tout sur un travail conséquent de préparation de la donnée. Quiconque a déjà résolu un cas d’usage en data science connaît le fameux ratio de 80% de temps passé à la préparation et au nettoyage des données contre 20% consacré à la modélisation.
Présentée sous le prisme des modèles complexes (IA, deep learning, machine learning…), soit la toute dernière étape d’un projet estampillé “data”, la data science donne parfois l’impression d’une pratique destinée à la résolution de problèmes ardus. Pourtant, la réalité de la construction d’un modèle est parfois très proche de considérations très opérationnelles. Et partagées bien au-delà de la communauté des data scientists.
Dans l’industrie des services, il faut savoir écouter la donnée
Dans une industrie de services, comme celle de l’assurance, une grande majorité des processus opérationnels pouvant décrire les activités de l’entreprise sont ou embarquent des opérations de transformation de données. Voici quelques exemples.
- La gestion d’un sinistre prend, en entrée, les données fournies par le client et les garanties attachées à son contrat. Et livre, en sortie, une décision d’indemnisation (un simple booléen ou un niveau de prise en charge), voire des informations de paiement.
- Un rapprochement comptable prend, en entrée de processus, des données de gestion et des données comptables. Et fournit, en sortie, la différence entre les deux à une certaine maille.
- Un reporting budgétaire prend, en entrée, des données financières de différentes sources. Et fournit, en sortie, une vision synthétisée, agrégée et uniformisée issue de différents calculs et ventilations budgétaires intermédiaires.
- Enfin, en épargne, la création de l’information annuelle aux investisseurs individuels prend, en entrée, les données de contact et l’état des contrats de chaque client. Et conduit à l’édition d’un fichier de publipostage contenant le texte du courrier (voire sa mise en page) et l’adresse postale de destination.
Pipeline et flux de processus : deux visions d’une même méthode
L’analogie entre processus et flux de données ne s’applique pas aussi naturellement à tous les processus métiers. Néanmoins, elle permet dans un grand nombre de cas de décrire une succession de tâches en une suite d’opérations sur les états successifs des données d’entrée. Un diagramme de flux, issu d’une analyse de processus, telle que pratiquée dans le cadre de projets d’amélioration (du type Lean 6 sigma par exemple), présente ainsi une parenté saisissante avec un flux de données tel que développé dans un outil de traitement de données standard.
1 Version flux de processus (Microsoft Visio)
2 Version flux de données (sous Knime)
Changeons de point de vue : le chemin compte plus que le résultat
L’approche par processus permet notamment de se focaliser non sur le résultat du processus, mais sur les transformations de la donnée et, comme le souligne un article récent publié sur le blog de Knime, de « ne plus penser en cellules de tableurs, mais en flux de données ».
On passe ainsi d’une vision statique, qui s’attache au résultat ou au reporting, à une vision de la dynamique de la donnée. Ici, c’est le chemin suivi qui compte, la transformation.
Cette parenté rend ainsi éligible à une approche “data” toute une série de problématiques opérationnelles. L’exemple des contrôles est assez saisissant à cet égard. Un contrôle consiste, schématiquement, à comparer deux données, l’une à valider, l’autre de source sûre, et à en vérifier l’égalité. Mathématiquement, on pourrait comparer cela à une soustraction, un modèle linéaire assez simple et bien maîtrisé. Si l’on se cantonne au résultat recherché, il ne s’agit pas d’un cas d’usage auquel l’analytics pourrait répondre. Pour autant, ces opérations se révèlent souvent fastidieuses et complexes. Elles nécessitent de créer un processus de transformation des données pour parvenir au résultat. Tout comme le data scientist doit créer son pipeline.
C’est ainsi toute une batterie d’outils et de méthodes habituellement utilisés en analytics qui deviennent naturellement applicables à des problématiques auxquelles on n’aurait pas nécessairement pensé les employer. Rien n’interdit de prétraiter des données à contrôler avec un script Python ou un outil de data préparation pour les utiliser en entrée d’un modèle linéaire appelé soustraction.
Des effets vertueux inattendus
Au nombre des effets inattendus de cette approche, on note une bien plus grande proximité des problématiques « métier » et « data ». Il nous est ainsi arrivé chez SeaBird de constater que des équipes métier avaient mis en place de manière manuelle de véritables flux de données à travers des modes opératoires très codifiés. Dans ces cas-là, le passage à un flux automatisé à l’aide d’un outil de BI s’est révélé assez simple. Le travail de cartographie du flux avait été déjà fait. De plus, les équipes reconnaissent leur mode opératoire dans l’outil fini que nous leur avons livré. Ce qui en a donc facilité l’adoption.
Ce phénomène est à la base de ce que l’on nomme parfois « data démocratisation ». Il recouvre les initiatives visant à déployer des outils « no code » ou « low code » auprès de populations non spécialistes de la science des données. Tout en partant du principe que les problématiques sont connues et partagées bien au-delà de la communauté des data scientists. Cette approche n’est probablement pas valable pour des modèles complexes nécessitant des connaissances mathématiques poussées. Elle l’est cependant pour les calculs simples constituant la grande majorité des processus opérationnels de transformation de la donnée. Enfin, la connexité entre processus opérationnels et transformation de données ouvre des perspectives très prometteuses pour la mise en place d’une gouvernance des données pragmatique et efficace.
Rendez-vous dans un prochain billet de conviction pour en savoir plus.
