Un projet Big Data est un chemin semé d’embûches.
Et même de beaucoup d’embûches ! Et qui ne sont pas que de nature IT ! Lors de ma visite au Salon Big Data, qui s’est tenu à Paris les 6 et 7 mars 2017, j’ai pu assister à 14 retours d’expérience, instructifs et opérationnels à la fois. Je vous propose une synthèse de cette visite autour des 5 points cruciaux à ne pas négliger quand vous allez vous lancer dans le grand bain.
Datamaster : Formater les données, c’est 80% du projet !
Oui, vous avez bien lu. 80% du temps est consacré à faire de l’ETL (Extract Transform Load) afin d’obtenir un jeu de données exploitable pour l’analyse statistique. Ce temps est nécessaire pour cartographier les sources de données, les récupérer, analyser leurs structures (d’un point de vue IT), nettoyer, formater et arbitrer entre des données contradictoires ou incohérentes.
Et là, c’est le Double Effet Kiss Cool® !
Premier effet, le « ping pong »
À qui confier cette tâche a priori peu reluisante ? A un data scientist fraîchement émoulu de Polytechnique ? A un développeur C++ avec 10 ans d’expérience en Front Office ? A un stagiaire de 3ème ? Personne ne va vouloir du « bébé » (et je ne parle pas du stagiaire de 3ème). Généralement le TJM (Taux Journalier Moyen) d’un data scientist est supérieur à celui d’un développeur. Est-ce que ledit data scientist est prêt à passer plus des trois quarts de son temps à faire de l’ETL ? Mais qui pourra le faire mieux que lui, qualitativement parlant ?
Comment justifier tout ce temps aux yeux des commanditaires du projet, qui ne sont généralement pas informaticiens, et n’ont absolument pas conscience de la faible qualité de leurs données ? Commanditaires qui, bercés par les promesses enchanteresses des vendeurs de solutions Big Data, sont persuadés d’êtres détenteurs d’un trésor, et qu’il suffit de se baisser pour récolter le ROI tant promis.
Second effet, « Rio ne répond plus »
L’attention portée par le business peut diminuer fortement car votre projet passe alors dans ce que l’on peut appeler : un tunnel. Quelle communication utiliser pour conserver l’attention des décideurs vis-à-vis votre projet, sans exacerber leur impatience ?
Si votre projet utilise des données périssables (par exemple, les cours journaliers de la bourse), pouvez-vous fournir des données prêtes à l’analyse et qui ont encore un sens, une valeur business, une fois l’algorithme prêt ?
Est-ce que le TTM (Time To Market) sera respecté si on prend en compte la charge réelle de ce travail ?
Moralité : Le ROI (Return On Investment) d’un projet Big Data ne doit pas sous-estimer cette étape cruciale de qualification des données, qui peut s’avérer mortelle si elle s’éternise.
Cybersecurity : Faire l’impasse sur la sécurité, no way !
La majorité des sociétés commencent à se soucier de la sécurité dans deux situations :
soit quand la compliance externe ou interne a mis un carton rouge
soit – et c’est le pire – lorsque des données ont été récupérées par des pirates (ou des organismes d’Etat pas très amicaux) et on parle alors de Data breach.
Les obligations se renforcent avec le RGPD (Règlement Général pour la Protection des Données de l’Union Européenne) – What ? Le quoi ? What ? Si cette notion vous est étrangère, il est grand temps d’aller là --> me mettre à jour après 10 ans comme otage chez les FARCs.
À compter du 25 mai 2018, vous devrez en effet signaler à la CNIL toute fuite des données, et ce, en moins de 48h. Pour info, les amendes vont jusqu’à 4% du chiffre d’affaire annuel international de l’entreprise, avec un plafond de 20 millions d’euros. Donc la sécurité doit être au cœur d’une infrastructure Big Data. Et j’ai bien écrit doit être. Il faut absolument arrêter de croire que l’on peut se préoccuper de la sécurité uniquement après la mise en production effectuée. La sécurité doit être prise en considération par tous les acteurs du projet dès sa conception (privacy by design) et tout au long de sa vie (accountability).
En résumé, vos 3 priorités : Un : La sécurité. Deux : la sécurité. Trois : la sécurité.
Profiling : Copier la NSA, mauvaise stratégie !
Encore un sujet sur lequel des autorités comme la CNIL pourraient vous demander des comptes. Si vous croisez vos données internes avec des données externes (Open Data…), vous pourrez potentiellement avoir un niveau de détail plus fin sur le profil de vos clients, abonnés, prospects, et vos algorithmes pourront être considérés comme du profilage. Là encore, vous êtes soumis au RGPD.
Vous le savez, depuis la Loi Informatique et Libertés (1978 quand même ! Si vous n’étiez pas otage des FARCs, sortez un peu de votre grotte…), il y a beaucoup d’informations qui ne doivent pas entrer dans l’analyse des données, comme la religion, la couleur de peau et bien d’autres. De plus, il faut faire extrêmement attention avec des jeux de données qui viennent d’autres pays comme par exemple les USA qui n’ont pas la même réglementation et sont moins restrictifs sur l’analyse d’aspects religieux, ethniques, etc.
Il faut toujours travailler en collaboration avec les services juridiques, la compliance, et demain le DPO (Data Protection Officer) pour éviter un faux pas qui pourrait se relever très coûteux en termes financiers et d’image...
Transparency : Un modèle n’est pas une boite noire !
De plus en plus de choix affectant des personnes seront faits demain par des algorithmes. Vous devez comprendre les implications de ces modèles et être capable de les expliquer.
Par exemple, le deep learning (les réseaux de neurones avec plusieurs couches cachées) est très puissant mais on n’arrive pas encore à expliquer le fonctionnement en détail d’un tel outil. Les scientifiques continuent à effectuer des recherches théoriques pour mieux le comprendre et ainsi en avoir une meilleure maitrise. Pour en savoir plus, lire: Why does deep and cheap learning work so well?
Il y aura de plus en plus de demandes émanant des utilisateurs pour comprendre les choix effectués par ces algorithmes. Rappelez-vous la demande des lycéens afin de connaître l’algorithme responsable des orientations post bac. Cela s’inscrit dans une demande de plus grande transparence de la part de la société, et c’est bien légitime.
Un autre exemple célèbre est le modèle développé à l’occasion d’un concours organisé par Netflix pour améliorer la recommandation de vidéos. Certes, l’équipe lauréate a raflé 1 million de dollars. Mais son modèle n’a jamais été mis en production. La faute à un coût d’industrialisation bien trop élevé ! Pour comprendre pourquoi, regardez par-là : Why Netflix Never Implemented The Algorithm That Won The Netflix $1 Million Challenge
Un dernier point, et non des moindres : le piège consistant à confondre corrélation et causalité. Parfois, vous pouvez trouver des corrélations sans pouvoir les expliquer. Une société qui a travaillé pour une compagnie ferroviaire est tombée sur cette conclusion : il existe une corrélation entre les incidents sur les portes des trains et les incidents sur leurs freins. Le data scientist n’a pu expliquer la relation entre ces deux types de pannes, sur des ouvrages sans aucun lien mécanique ou fonctionnel. Si vous travaillez sur de la maintenance prédictive, vous devez y veiller très fortement et cela vous empêchera peut-être même de dormir…
Un bon algorithme est un algorithme qui s’explique.
Team : Ne cherchez pas le mouton à 5 pattes !
Ne perdez pas votre temps à chercher un data scientist capable de tout faire tout seul dans son coin, comme un couteau suisse. Un projet Big Data nécessite des compétences complémentaires. Les profils qui vont intervenir lors des étapes successives sont les suivants :
Les architectes : ils vont choisir, qualifier les solutions techniques et proposer une architecture
Les développeurs : ils vont faire de l’ETL avec les données et l’industrialisation en vue d’une mise en production (Sorry guys, je vous ai désignés d’office !)
Les data scientists: ils – ou elles – vont analyser les données et proposer des modèles (le 8 mars est passé par là…)
Les personnes du métier : elles pourront valider le modèle ou l’invalider s’il n’existe pas d’explications tangibles en termes de causalité
Les personnes spécialisées en sécurité IT pour éviter les fuites des données (RSSI – Responsable Sécurité des Systèmes d’Information)
Des profils type compliance – à la fois juridiques et techniques – pour mettre des gardes fous (Risk manager, Compliance Officer, et demain le très attendu CDO – Chief Data Officer)
Pour mettre en œuvre un projet Big Data, les pièges sont nombreux et de nature différente. Il faut constituer une équipe aux profils variés et dotée d’une une forte capacité à communiquer en son sein. Objectif : éviter l’arrêt du projet. Principales menaces : un projet mal conduit en interne (délai et budget dépassés, manque d’intérêt des décideurs…) dans un environnement réglementaire mal maîtrisé (CNIL, Union Européenne, utilisateurs…).
En résumé, les 5 pré-requis :
Fournir des données formatées dans un temps restreint
Ne jamais faire l’impasse sur la sécurité
Toujours travailler avec la compliance
Être capable d’expliquer son modèle
Savoir mixer les profils pour avoir une équipe de choc
Et vous, qu’en pensez-vous ? Avez-vous des expériences à partager à la suite de cet article, en commentaire ? Et si vous voulez, on en parle autour d’un café. ;-)
