De quoi le futur de la data sera-t-il fait ? (sous un intervalle de prévision assez large…)
Les buzz successifs autour de la Big Data, de la Data Science et maintenant de l’Intelligence Artificielle ne doivent pas cacher qu’une grande partie des entreprises, ne se lancent pas totalement dans ces approches, particulièrement lorsqu’elles ne sont pas « data natives ». Mais est-ce une si mauvaise chose ? Car, sous le vent des discours marketing, il faut savoir raison garder.
Dans cet article, je donnerai mon point de vue sur l’évolution en cours ou à venir dans le monde de la data, aussi bien en termes de gestion de projet et d’équipe que d’outils et d’architectures.
AVERTISSEMENT : cet article contient, non pas des propos de comptoir, mais sans doute des propos dignes de fin de buffet de meetup, entre cartons gras de pizza et soda éventé. Il s’agit donc d’un avis personnel, par ailleurs, influencé par ma proximité avec l’éditeur Microsoft mais aussi par l’écoute assidue de l’excellent podcast du Big Data Hebdo.
Les dernières tendances observées
En ce début d’année 2020, les craintes vis-à-vis du cloud semblent s’être estompées, emportées par quelques exemples de migration dans des secteurs très sensibles comme les banques ou assurances. Mais il ne faut pas déconsidérer l’approche hybride (choisir ce que l’on met dans le cloud : le moins sensible, ce qui demande de la scalabilité, etc.), ou multi-fournisseurs. Cette dernière approche permet en effet d’éviter le « vendor locking », c’est-à-dire se retrouver pieds et poings liés auprès d’un éditeur. Vous aviez tout misé en 2014 sur un cluster Hortonworks on-premises ?
La Data Science fait peur car si l’on sait quand démarre le projet, il n’y aucune certitude quant à sa durée ni même dans la capacité à trouver de l’information dans les données. Dans cet article, je décris plus en détails l’incertitude du ROI de l’embauche d’un.e Data Scientist. De plus, le passage en production pose de nombreuses questions et bouleverse les habitudes des départements IT.
Le Proof of Concept est devenu un « bad buzzword », remplacé par l’injonction de l’industrialisation, au détriment de la réflexion sur la pérennité des résultats et la quantité de données nécessaires pour y parvenir. Ainsi, une étude ad hoc de segmentation des clients a pu se réaliser sur un échantillon de quelques milliers d’individus et donner des résultats fiables (bien sûr présentés dans des intervalles de confiance), valides au moins plusieurs mois. Y avait-il nécessité d’industrialiser un algorithme de clustering recodé en Spark ml, mis à jour toutes les nuits sur les téraoctets contenus dans le CRM ?
Où se trouve aujourd’hui l’intelligence artificielle ? Dans les laboratoires de recherche ou les start-ups mais sans doute pas dans une grande majorité d’entreprises, hormis sur leur brochure présentée lors du dernier salon IA à la mode. Les utilisateurs disent oui à l’IA mais à condition qu’ils ne s’en soucient pas. L’IA doit être intégrée dans des produits plus courants comme le dashboard, l’outil de ticketing ou encore le CRM. Ce n’est pas un projet en tant que tel ou alors un joli projet de recherche fondamentale qui disparaitra dès que les Crédits Impôts Recherches ne seront plus suffisants.
Au-delà de ces quelques éléments caractéristiques très visibles en surface, de véritables bouleversements de fond sont en cours.
Le marché de la Data
Quels secteurs pour quels cas d’usage ?
Tous les secteurs d’activité sont concernés par les projets data car la donnée est potentiellement partout mais à condition d’être collectée et bien collectée, c’est-à-dire d’avoir un niveau de qualité (valeurs manquantes remplacées si besoin, valeurs aberrantes identifiées et corrigées) et de documentation suffisants pour être exploitée. N’oubliez jamais que « garbage in, garbage out ! ». Sans qualité de donnée, le projet échouera. Avec un bon niveau de qualité, le projet devrait réussir.
La difficulté réside aujourd’hui dans l’émergence des cas d’usage, entre des utilisateurs qui ne les anticipent pas et des avant-ventes où l’imagination est débordante. Ensuite, le choix des cas d’usage devra être orienté par la valeur (création ou économie) mais tempéré par la faisabilité, la complexité et la capacité à passer en production. Cela permet de prioriser les projets au moyen d’un visuel de type matrice BCG.
Comment adresser les clients ?
Les entreprises vont attendre de la part des ESN, de l’expertise sur des sujets très, voire trop récents. Bien souvent, l’expertise des consultants se limite à un Proof of Concept voire à la reproduction d’un tutoriel de l’éditeur. Faisons fi des compétences techniques acquises, un consultant doit aujourd’hui faire preuve de curiosité (par une veille régulière et organisée), de débrouillardise (les produits récents sont peu stables voire encore buggés) contrebalancée par une méthodologie : ne pas faire marcher une solution à tout prix si elle n’est pas en capacité de respecter les standards d’industrialisation attendus.
De cette absence de maturité, on déduira que les estimations données pour une prestation au forfait seront très hasardeuses. Face au doute sur l’expertise, la crainte de se tromper de prestataire tend à faire disparaître la présence « d’armées mexicaines » de consultants en régie sur le long terme. Un nouveau modèle doit émerger entre expertise ponctuelle, petit très cadré au forfait et centre de service en support.
Les profils Data
Coding or not coding? Il existe maintenant deux approches possibles selon les outils. Ceux qui ne codent pas et s’appuient sur des briques prédéfinies qu’ils assembleront, seront nommés « citizen developers » par opposition aux développeurs traditionnels (« canal historique », les vrais, les geeks).
Cette distinction s’applique aussi aux métiers de la data : un citizen data scientist travaillera par exemple sur la plateforme Dataïku DSS comme décrit dans cet article.
Même si leur utilisation ne se fait pas toujours à juste titre, en particulier dans les offres d’emploi, les postes dans la data se stabilisent autour de trois métiers distincts.
Data (business) Analyst
- Qualité principale : savoir faire parler les chiffres et ceux qui les attendent.
Mettre à disposition un indicateur, même sous ses plus beaux attraits visuels ne sert strictement à rien. Il faut porter un message, et espérer que celui-ci serve ensuite à une prise de décision. Mais pour donner une réponse pertinente, encore faut-il avoir entendu et compris la question !
- Tâches attendues : trouver les bons points de comparaison, les facteurs explicatifs, savoir résumer, rendre utile et lisible. Je déclare ici la paternité du néologisme « utilisible ».
Data Scientist
- Qualité principale : modéliser de manière mathématique une problématique énoncée par le métier. Le modèle obtenu devra être encadré par des limites d’utilisation et d’interprétation, donner des leviers concrets aux demandeurs.
- Qualité pas si facultative : comprendre les problématiques du métier du Data Engineer (voir ci-dessous).
- Tâches attendues : améliorer la qualité de données en réalisant des contrôles et des corrections. De temps en temps, faire tourner un script d’Automated Machine Learning pour produire un bon modèle (voir ci-après).
Data Engineer
- Qualité principale : ne pas s’énerver contre la qualité du code fourni dans les notebooks du Data Scientist.
- Tâches attendues : déployer du code dans des environnements de test, qualification, production qu’il sera aussi nécessaire de déployer, configurer, superviser.
Le Data Engineer devra faire preuve d’une bonne connaissance des mécanismes de distribution de la donnée et de parallélisation des traitements car c’est sur ses épaules que reposeront les performances lorsqu’elles passeront à l’échelle. « J’comprends pas, ça tourne en local sur mon poste… » On a bien dit de ne pas s’énerver contre le Data Scientist.
Data Strategist
Ajoutons enfin un quatrième métier dont le nom est un néologisme vraisemblablement apparu sur un post LinkedIn et que revendique l’auteur de cet article.
Qualités requises :
· Connaître des REX, aussi bien des réussites que des échecs.
· Expliquer avec pédagogie les mécanismes techniques et leur impact sur la chaîne de la donnée dans l’entreprise.
· Mettre en valeur le patrimoine de données de l’organisation.
· Être inventif pour trouver de nouvelles sources de données qui deviendront de véritables informations et non une couche de détritus supplémentaire dans la décharge du Data Lake.
Les outils de la Data
Le cloud ne fait plus peur même si l’hégémonie de quelques acteurs le devrait. A l’instar d’un particulier qui souhaite conserver son numéro de téléphone lorsqu’il change d’opérateur, les DSI souhaitent conserver leurs développements en changeant de cloud provider.
L’open source s’est forgé, contre vents et marées et grâce à sa communauté, une solide réputation. A tel point que de nombreuses entreprises se sont créées autour d’une brique Open Source pour accompagner sa distribution (Confluence avec Kafka, Databricks avec Spark, etc.), tout en contribuant, à différents degrés, à l’amélioration du produit libre.
Dans ce nouveau monde constitués de market places, les éditeurs sont en perte de vitesse ou tout du moins de visibilité. Sauf à s’octroyer une belle place dans le cadran Gartner annuel, au prix de quelques features bâclées mais au nom ronflant.
Balayons maintenant les principales phases d’un projet Data.
L’ingestion
Plus que jamais, Kafka est incontournable, et il ne faudrait pas le cantonner uniquement aux scénarios des objets connectés. En effet, le système d’event sourcing peut être vu comme une « base de données de bas niveau » reproduisant la commandes SQL. La puissance de cette solution portée par la fondation Apache permet de l’envisager en lieu et place d’un traditionnel ETL. Tout cela est beaucoup mieux expliqué par ici.
Le stockage
Il est indispensable de gouverner la donnée, encore plus au sein du Data Lake. Cela passe par de la méthodologie visant à organiser les données déposées (raw, clean, golden dataset…) mais aussi par la tenue d’un outil de type Data Catalog (voir ci-après). Votre lac de données ne doit pas se transformer en une décharge publique. Sinon, vos utilisateurs s’en détourneront rapidement en se pinçant le nez.
Dans le monde structuré, il y a aura toujours besoin de DBA mais le métier se transforme. Les bases de données intègrent des outils d’auto optimisation, souvent à base de Machine Learning. Les services managés sur les clouds publics affranchissent de la vision hardware. Mais il sera toujours fondamental de comprendre comment fonctionne le moteur sous le capot.
Le traitement
Hadoop MapReduce est mort, vive Spark. Encore faut-il maîtriser l’écriture du code pour qu’il profite au maximum de son environnement d’exécution distribué. Cela passe par du code écrit en langage Scala (le langage natif de Spark) ou les APIs pyspark et SparkR. Mais les data scientists ont souvent grandi en exploitant la librairie Python pandas qui permet de travailler facilement avec des tableaux de données. Ici, la nouvelle librairie koalas s’avère prometteuse car sa syntaxe collera parfaitement à celles de pandas mais avec la capacité de paralléliser les traitements dans un environnement comme Databricks.
Pour les traitements à but prédictif, il va falloir savoir expliquer les résultats obtenus au travers des algorithmes. Que ce soit par nécessité vis-à-vis de la RGPD, par crainte de l’effet « boîte noire », pour identifier des leviers (aspect prescriptif) ou pour convaincre de la performance. C’est le mouvement nommé XAI (Explainable AI) dont vous pourrez lire ici une première approche au moyen de LIME.
Le Deep Learning nécessite dorénavant des compétences… de manipulations des API (Postman est votre superhéros !). On privilégiera les services permettant de réaliser de l’apprentissage par transfert (Transfer Learning ), c’est-à-dire donnant la possibilité d’ajouter un jeu d’entrainement labellisé mais peu volumineux afin de spécifier le modèle. Ce sera le bon compromis entre un service non personnalisable, donc trop générique, et un développement ad hoc qui nécessiterait des compétences fortes (un doctorat en mathématiques appliquées ?), des volumes de données importants, de la puissance de calcul très chère (GPU), pour un résultat qui ne sera ni garanti en qualité, ni stable dans le temps. Une première démonstration, très nantaise, du service Custom Vision de Microsoft est visible ici.
L’exposition
Par exposition, nous entendons la partie émergée de l’iceberg du projet data : la seule qui génère une valeur potentielle.
Demain, tout le monde ou presque sera capable de créer une application web ou un tableau de bord… excessivement moche et tout-à-fait contre intuitif à l’usage. Associer la discipline de l’UX / UI Design devient indispensable, et ce, dès le démarrage d’un projet, c’est-à-dire en phase de recueil des besoins.
A la présentation des démonstrations ou des maquettes, ne perdez pas la seule occasion de faire une première bonne impression. Mais cela ne vous affranchira pas d’un travail itératif qui permettra de tendre vers l’affordance. Personne ne vous a jamais appris qu’on soulevait une tasse à café par son anse. CQFD.
Le data catalog
Fichier plat, d’où viens-tu ? Indicateur, quelle est ta règle de calcul ? Petite donnée, depuis quand n’as-tu pas été rafraichie ? Si toutes ces questions vous semblent définitivement sans réponse, il est grand temps de vous intéresser au sujet du catalogue de données. Selon la profondeur du data mess, le chemin de croix vers la metadata de qualité pourra s’avérer très long. Ne désespérez pas, le jeu en vaut la chandelle. Et les juristes qui surveillent de près le respect de la RGPD vous en remercieront.
Pour ne pas faire de publicité déguisée, citons au moins trois acteurs de ce marché : Data Galaxy, Zeenea et Collibra.
Les briques d’architecture bientôt obsolètes ?
Nous allons enfin aborder la triste liste nécrologique prédictive de l’année à venir. Resquiescat In Pace, Numericus.
Mort des algorithmes supervisés ?
Le travail d’un Data Scientist consiste à soumettre des données d’entraînement, intelligemment préparées, à un modèle mathématique qui découvrira par lui-même les bons paramètres pour une efficacité prédictive.
Aujourd’hui ou plutôt hier, il s’agissait de faire preuve d’inspiration, d’expérience ou bien de raisonnement mathématique pour trouver la bonne famille de modèles (linéaires ou non linéaires, simples ou ensemblistes, etc.). L’Automated Machine Learning arrive dorénavant comme une force brute, visant à tester à la chaîne toutes les approches possibles, profitant de la diminution globale des coûts des traitement.
« The AI revolution won’t be supervised » déclarait Yann LeCun. Autrement dit, il est trop long et coûteux de récolter de la donnée d’apprentissage labellisée. Faire jaillir de l’information de la donnée non labellisée (apprentissage non supervisée) ou labellisée a posteriori (apprentissage par renforcement) est beaucoup plus prometteur mais aussi beaucoup plus complexe.
Mort du data warehouse (physique) ?
La structure des données et les besoins de croisement évoluent aujourd’hui trop vite pour stabiliser un modèle sémantique dans un hypercube, au vu de la quantité et spécificité des développements que cela induit. Les cubes décisionnels sont engoncés dans leurs schémas en étoile(s) qui ne peut plus refléter la complexité de la donnée recueillie dans une organisation.
Dans une architecture cloud, le Data Lake stocke l’information et ce n’est plus une problématique de coût. Il est clairement séparé des ressources de traitement, qui seront beaucoup plus coûteuses mais uniquement au moment où elles travailleront, pour générer ce que l’on peut qualifier de data warehouse virtualisé.
Le piège (ou la contrainte de coût / performance…) serait de matérialiser à nouveau les données agrégées dans une autre ressource de stockage physique. L’un des objectifs du Data Lake était de mettre fin au silotage de la donnée, ne recommençons pas à la cloisonner en data marts !
Mort de l’ETL classique ?
L’acronyme ELT n’est ni l’œuvre d’une personne dyslexique ni une contrepèterie. Il est en effet pertinent de charger (L) l’information dans le format sur lequel elle est extraite (E). Il sera ensuite bien temps de la transformer (T) selon les usages souhaités. Une approche décisionnelle, dans une logique ETL, et une vision d’analyse avancée voire de modélisation prédictive, par approche ELT, ne sont pas forcément compatibles. Ici, la couche « nettoyée » du lac de données sera centrale pour fédérer tous les usages de la donnée raffinée.
Mort de la base relationnelle ?
Les documents au format JSON sont de plus en plus fréquents et le seront encore plus avec l’augmentation des objets connectés.
Malgré leur efficacité, les bases relationnelles ne sont plus hégémoniques et malgré un très (trop ?) grand nombre d’acteurs, des produits du mouvement NoSQL émergent et sont « adoubés » lorsqu’un cloud public développe, autour, une offre managée.
Un avantage ira sans doute aux bases capables de réaliser plusieurs types de stockage et surtout de distribuer ce stockage pour assurer une scalabilité horizontale.
Enfin, n’oublions pas les bases graphes. Aujourd’hui, les spécialistes sont très peu nombreux. Pour autant, un grand nombre de problématiques d’entreprise peut se modéliser sous forme de graphe et offrir toute une panoplie d’algorithmes pour une résolution de problèmes complexes. Si vous croisez un spécialiste des bases graphes, entrez en relation avec lui, il vous reliera certainement à d’autres spécialistes.
Mort du langage SQL ?
Non, définitivement, non. Lorsque la Terre aura été ravagée par une nouvelle guerre nucléaire ou par le dérèglement climatique, il ne restera plus à la surface du globe, que des cafards et le langage SQL. Ce sont même les stockages de données semi ou non structurés qui doivent se plier à la syntaxe qui fêtera bientôt ses 50 ans. Longue vie à toi, SELECT… FROM… WHERE !
Suite à ces propos péremptoires, tous les commentaires sont les bienvenus, le but étant d’ouvrir la discussion. N’oublions pas que « les prévisions sont difficiles surtout lorsqu’elles concernent l’avenir ». (Jacques Chirac, 1993)