7 juin 2021 2355 mots, 10 min. de lecture Dernière mise à jour : 15 mars 2022

Les 11 défis de la data préparation et du data wrangling

Par Pierre-Nicolas Schwab Docteur en marketing, directeur de IntoTheMinds
Les évènements de 2020 ont accéléré le basculement vers le télétravail et les relations digitales. Avec la digitalisation, une autre transformation est également en marche: la transformation analytique. Pour faire face à cette révolution des données, je trouve que les […]

Les évènements de 2020 ont accéléré le basculement vers le télétravail et les relations digitales. Avec la digitalisation, une autre transformation est également en marche: la transformation analytique. Pour faire face à cette révolution des données, je trouve que les entreprises ne disposent pas forcément des bons outils quand il s’agit de préparer et d’analyser les données (c’est la data preparation ou le data wrangling).

Dans cet article j’ai voulu remettre en perspective le rôle de ces outils dans le fonctionnement de l’entreprise. En particulier je pense qu’ils peuvent contribuer à gagner en efficacité et ce que je vais donc m’efforcer de démontrer. J’ai défini en particulier 11 caractéristiques qui définissent la solution parfaite de data wrangling / data preparation. Ces dernières sont une extension d’une ébauche que j’avais déjà écrite sur le sujet.

Sommaire

 

La transformation « data » : un défi pour les ressources humaines

Historiquement, la génération de valeur à partir de données était effectuée par des profils spécialisés et couteux (docteurs en data science, codeurs en R/Python). Si l’externalisation est toujours possible pour des besoins ponctuels, elle présente un inconvénient majeur : les consultants externes ne comprennent pas votre métier et ont besoin de temps pour saisir les subtilités cachées de vos données.

Pour pouvoir pleinement bénéficier de vos données et rapidement en tirer toute la connaissance et la valeur, il est dès lors important d’internaliser l’expertise data et de mettre à disposition des outils utilisables par le plus grand nombre. L’utilisation par tous les analystes d’outils de « data wrangling » en self-service me semble ainsi essentiel. Ce sont en effet ces personnes qui comprennent le problème business à résoudre et qui sont donc le plus à même de le résoudre si on leur en donne les moyens techniques.

Internaliser l’expertise data et mettre à disposition des outils utilisables par le plus grand nombre est essentiel.

Cette approche permet à la démarche analytique de sortir du carcan du département «Data Science». C’est également un premier pas pour insuffler une culture analytique globale et être plus « agile (désolé pour le « buzz word »).

En fait, les exemples sont nombreux de personnes au sein des entreprises qui manipulent déjà les données. Dans 99% des cas tout se fait avec Excel et c’est là que des gains d’efficacité énormes peuvent être réalisés. En effet les bons outils de « data wrangling » / « data preparation » offrent des solutions à toutes les limitations d’Excel (transformations complexes, multiplicités des formats de données, volume, …). En ce qui me concerne ma préférence va à Anatella dont j’ai déjà parlé à de multiples reprises (voir par exemple ici).

Dans les paragraphes suivants j’explique ce que doivent être, d’après moi, les 11 caractéristiques d’un bon outil de data preparation / data wrangling.

L’outil de data wrangling doit être outil en « self-service » …

Un outil de data preparation en self-service permet à vos analystes de résoudre plus rapidement les problèmes métier. Ils comprennent les données et leur contexte et grâce à un outil idoine ils sont donc autonomes dans la résolution.

La préparation des données doit être rapide

Typiquement, les data scientists consacrent plus de 85% de leur temps à faire de la « data préparation ». Un outil permettant un gain de vitesse et de productivité pour la « data préparation » est donc le bienvenu !

En particulier, les data scientistes les plus expérimentés ont depuis longtemps réalisé que, pour pouvoir faire un travail de meilleure qualité, il fallait réduire le temps consacré au « data wrangling ». C’est pourquoi, tout comme les analystes-business, les data scientists les plus expérimentés sont demandeurs d’un outil en « self-service », à la souris, car cela leur permet d’avoir un gain immense en productivité en en temps lors de la phase, toujours couteuse, de « data wrangling ».

L’outil choisi doit être fédérateur

Un outil qui favorise et facilite la collaboration entre les analystes business (orientés métier) et les data scientists (orientés technique) me semble indispensable. Sans cet aspect fédérateur, il est en effet difficile d’arriver à une culture analytique globale au sein de votre entreprise.

L’aspect fédérateur d’un outil de « data préparation » est peut-être le plus difficile à obtenir car les besoins des utilisateurs métiers sont souvent éloignés des besoins des « data scientistes » :

  • Les analystes-business évitent le code et veulent accéder facilement et immédiatement à l’information souhaitée. Ils travaillent souvent avec des petites volumétries et sans employer d’algorithmes de grandes complexités.
  • Les « data scientistes » aiment coder et ce n’est pas l’écriture d’un petit millier de lignes de code en R/Python qui vont les arrêter (après tout, ce n’est qu’une petite journée de travail !). Ils travaillent souvent avec des volumétries plus importantes et emploient des algorithmes complexes.

Possibilité de travail par itération

Le travail sur les données est sans fin et doit être vu comme un cycle. Le cycle représenté schématiquement ci-dessous montre bien que le travail est sans fin. Il est alimenté en permanence par de nouvelles données : les données actualisées d’une part, les données provenant de nouvelles sources d’autre part.

cycle de valorisation des données

Le traitement des données n’est donc pas une fin en soi. C’est un cycle, un éternel recommencement. Les outils utilisés doivent donc pouvoir gérer les cycles de mise à jour.

Exemple de traitement itératif des données

Beaucoup d’entreprises utilisent des fichiers excel pour collecter (et échanger) des données auprès de leurs employés. Que se passe-t-il quand un employé décide de légèrement modifier la structure d’un fichier Excel pour qu’il soit mieux adapté au problème business à résoudre ?

Cette petite modification impose la mise-à-jour du processus de « data wrangling » qui collecte les données hors de ces mêmes fichiers Excel. Si ce processus de « data wrangling » est « opaque » (car programmé dans un langage incompréhensible que seul des initiés comprennent, et cela uniquement la journée où ils ont écrit le code), alors tout le processus de collecte des données se retrouve compromis. Ceci conduit à la production de données invalides et, en bout de chaîne, à des décisions erronées. Combien de fois avez-vous entendu un collègue vous dire que ce KPI était absurde et qu’il ne faillait pas en tenir compte ? Cette absence (ici justifiée) de confiance dans les résultats analytiques trouve bien souvent son origine dans l’utilisation d’outils de « data wrangling » trop peu transparents.

Adaptation aux grands volumes de données

Je défends l’idée d’outils adaptés au traitement rapide de grands volumes de données (voir mon benchmark ici). Le temps de traitement est évidemment corrélé au volume de données à traiter. Or, trop souvent, les outils qui sont mis à disposition des business analystes sont trop lents ou ne permettent pas de gérer les grands volumes de données.


Un outil puissant indépendamment des ressources dans le cloud

La question de la puissance de calcul dans la data preparation est à mon avis centrale. Pour rendre l’autonomie aux analystes, il faut leur permettre de répondre à toutes leurs questions sans dépendre de l’accès (ou non) à un « cluster » de machines dans le cloud. Si la puissance de calcul disponible vous contraint dans vos analyses, vous en retirerez une certaine frustration.

Bien qu’il soit maintenant très aisé de créer des « cluster » de machines dans le cloud, le prix n’en reste pas moins (élevé. A cause de ce prix élevé, une société « normale » se limitera à la création d’un seul « cluster cloud » (voire maximum deux). L’utilisation de ce cluster sera en outre réservée à un petit nombre de data scientists.

On comprend tout de suite que, dans ces conditions, le développement d’une culture analytique globale est compromis. Si seulement 2 personnes ont accès au cluster, comment voulez-vous gagner en efficacité et ne pas créer des goulots d’étranglement ?

Outre le prix prohibitif du cloud, il y a aussi la question de la souveraineté des données quand ces dernières sont stockées sur un cloud américain. Pour plus de détails sur ce sujet : voir la décision ‘Schrems II’ du dossier C-311/18 ici.


Un outil aux coûts fixes

Je suis assez allergiques à l’idée de ne pas savoir à l’avance ce que va me coûter l’analyse des données. Pourtant c’est la situation dans laquelle se trouvent toutes les entreprises qui utilisent AWS ou Azure pour le traitement de leurs données. La variabilité des coûts ne permet pas d’anticiper le montant de la prochaine facture. En d’autres termes, un coût variable est associé à chaque question analytique.

Une propriété inhérente aux « clusters clouds » est le « coût variable » lié à chaque question analytique. C’est peut-être même le « Key Selling Point » des offres des géants du cloud : « Vous ne payez que ce que vous utilisez ».

Un data scientist motivé sera ainsi à l’origine de coûts variables plus élevés car il fera un usage intensif du « cluster cloud » pour essayer de comprendre au mieux les données. Au contraire, un data scientist moins motivé occasionnera des coûts variables moins importants.

Le monitoring des coûts de processing dans « cloud » sanctionne les data scientists les plus actifs et les plus motivés

Si l’évaluation des data scientists se fait sur les coûts qu’ils engendrent, on aboutit à une situation paradoxale. Ceux qui travaillent le plus et qui qui sont les plus motivés sont pénalisés. L’usage parcimonieux » du cluster devient ainsi la norme. Comme c’est une situation qui arrive tout le temps, il existe maintenant une pléthore d’outils spécialisés dans le « monitoring du cloud » qui permettent de sanctionner et de couper l’accès aux ressources de calculs à tous les data scientistes un tant soit peu motivés. Dans ces conditions, on comprendra tout de suite que garder la motivation des data scientists risque d’être difficile.

Pour finir sur ce sujet, un outil de data wrangling qui fonctionne en « coûts variables » (comme 99% des solutions clouds) a pour effet de pénaliser, décourager et finalement empêcher vos meilleurs éléments de travailler.


Faciliter l’industrialisation

Ou bon outil de data wrangling doit permettre de facilement industrialiser et automatiser les « recettes » développés par vos équipes.

Voici quelques caractéristiques spécifiques qui me semblent importantes :

  • intégration facile avec tout programme de scheduling (par exemple : le « task scheduler » de MS-Windows ou encore Jenkins).
  • mise en place rapide au sein de votre infrastructure IT actuelle et/ou au sein d’autres langages ou autres framework data. Par exemple, le fait de pouvoir appeler une procédure de « data wrangling » à partir d’un petit script Python est un must.
  • assez robuste pour « encaisser » une augmentation soudaine de volumétrie dans les données sans tout faire planter.

 


Outil intégré

Certaines solutions d’ETL n’en sont pas vraiment car la partie « transformation » (le « T ») est absente ou insuffisamment développée. En ce qui me concerne je donne donc la priorité aux outils qui couvrent l’ensemble des 3 parties du cycle des données : acquisition, stockage, exploitation. Il faut pouvoir passer de l’un à l’autre sans difficulté et sans aucune perte accidentelle d’information.


Multiplicité des connecteurs

J’ai déjà parlé de nombreuses fois de l’importance d’avoir un maximum de connecteurs. Aujourd’hui les données viennent de partout, dans des formats de plus en plus nombreux et parfois propriétaires.


Nombreuses fonctionnalités de transformation des données

C’est un point dont j’ai déjà parlé à de nombreuses reprises et qui me semble essentiel dans une approche « No Code ». Il faut pouvoir disposer d’un maximum de « boîtes » pré-programmées pour couvrir les opérations courantes de transformation des données.

Bien entendu, toutes les solutions d’ETL dignes de ce nom ont une large gamme de « boîtes » à disposition. Mais certaines en ont plus que d’autres (par exemple Anatella) ce qui peut être très pratique.

Ce dernier point parait évident mais, de façon assez surprenante, il n’y a, au final, que très peu de solutions logicielles qui répondent à ce besoin. En effet, beaucoup d’éditeurs de logiciel se contentent de fournir une large connectique et ils oublient totalement l’aspect « transformation des données » qui est au moins une composante aussi importante, si pas plus. Vous voulez des exemples ? En voici deux.

Le fuzzy matching

Super utile pour réconcilier 2 bases de données quand la qualité n’est pas terrible. Pourtant je ne connais qu’une seule solution qui la propose en natif (voir ici pour plus d’infos).

La fonction pivot

Si vous faites de la data visualisation, pouvoir pivoter ses données est vraiment la base. Pourtant, là encore, 99% des solutions de data wrangling ne le proposent pas (dans Anatella les boites s’appellent « flatten » et « unflatten »)



Publié dans Data et IT.

Donnez votre avis

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *