Nous entrons dans une ère où les actifs de l’organisation doivent être mis au service de l’essentiel. Il est temps de dire au revoir au data lake « fourre tout », et d’assurer la maîtrise des données essentielles pour la stratégie et la raison d’être de l’organisation. La gouvernance des données devra être pragmatique pour assurer que les investissements (stockages, traitements, compétences data, …) sont mis au service de ce qui compte vraiment.
Le rôle du Chief Data Officer de 2021 est de réguler/minimiser au maximum les comportements automatisés ou humains qui génèrent toujours plus de volume, mais… pas toujours plus de valeur. Ces comportements prennent parfois la forme de boucles de rétroactions positives, non régulées. Il est temps de trouver le bon niveau de régulation pour limiter ces proliférations, vers plus de sobriété. Ce sera un bien pour votre portefeuille et pour l’environnement.
Une donnée… fait des petits
Voici un exemple de rétroaction :
Une donnée fait des petits (copies, données transformées pour des usages spécifiques, parfois ponctuels, ,..). Plus les volumes de données stockées sont importantes dans votre organisation et plus l’augmentation de ces mêmes volumes demain aura tendance à être grande. Duplication des données, copier coller à droite à gauche… Sans une gouvernance aboutie des données en guise de régulation : plus il y a de données… plus il y aura de données, sans même que vous l’ayez demandé ou voulu ! Au même titre que plus il y a de gens sur cette planète, plus il y aura de naissances…
Quelles régulations ?
Faire le tri dans vos données existantes, c’est comme faire le tri dans votre appartement après une grosse dépression : C’est le « bordel ». Vous devez ranger. Vous commencez par enlever tout ce qui n’a clairement rien à faire là et qui n’est pas utile (les déchets, les vieux papiers sans utilité, …), vous remplissez quelques poubelles sans trop d’état d’âme. Puis vient l’étape plus minutieuse, où vous prenez le temps par catégorie. Vous vous posez vraiment la question : « Dans ce qui reste, de quoi puis-je me passer ? ». Alors vous triez en paquets « je garde, je ne peux pas m’en passer », « ça peut, peut être, servir », « je suis décidé, je m’en débarrasse ».
Pour les données c’est pareil. Il y a toujours des petits malins pour dire : « Gardons l’historique, après tout, ça peut peut être servir un jour, c’est le principe du data lake non ? » Non, parce qu’une donnée stockée a un coût environnemental et financier, si on ne sait pas dire simplement pourquoi elle est là, alors elle n’a pas à être là. Fin de la partie. « Delete »… Dans l’ère du « Big Data », ce réflexe n’est pas naturel (c’est le moins qu’on puisse dire) et pourtant il est précieux, et vous évitera bien des problèmes, plus qu’il ne vous fera manquer d’opportunités…
L’ajout d’une nouvelle donnée doit être justifiée « by design ». Une application sera conçue en appliquant le principe de « Data Minimization », pas seulement pour les données personnelles mais pour toutes les données. Si la valeur de la donnée n’est pas avérée, alors on ne demande pas à l’utilisateur de la saisir. L’UX n’en sera que plus épurée, et ça fera un problème de moins à gérer, et un bienfait pour la charge mentale de vos utilisateurs, clients, collaborateurs.
La gouvernance des données doit intégrer dans son ADN ce principe simple et parfois oublié : une donnée qui n’a pas d’usages clairement qualifiés n’a rien à faire dans les bases de données de votre organisation.
Et malheureusement, l’augmentation des volumes peut générer rapidement des pertes de qualité
Parce que plus il y a d’objets et de meubles dans votre appartement, plus il faut prendre du temps pour nettoyer…Il faut bouger les meubles pour nettoyer derrière, soulever les objets pour nettoyer en dessous… Vous n’y échapperez pas, pour les données c’est pareil. La gouvernance des données doit assurer le coup de chiffon qui va bien au bon moment pour limiter les risques de non qualité ou de sécurité, et réduire l’empreinte carbone du système d’information.
Voilà un challenge que le Chief Data Officer devrait s’approprier davantage à l’échelle de son organisation. Maîtriser les volumes et la prolifération des données, pour être capable de maintenir un niveau de qualité acceptable, et documenté : Un utilisateur ou un projet doit être alors capable en toute autonomie de décider si le niveau de qualité de l’information est suffisant pour l’usage qu’il veut en faire, et, si son usage le justifie, qualifier des exigences de qualité supérieur à ce qu’il a aujourd’hui (fraicheur, complétude, ..) avec les équipes en charge des données.
C’est également la juste contribution du CDO dans les prochaines années à la maîtrise de l’empreinte carbone du numérique, en régulant la masse de ses actifs data plus sérieusement qu’il ne le fait aujourd’hui.
Moins de volume ET plus de valeur : Vous relevez le défi ?
La data science est devenue un levier clé aujourd’hui, pour mettre les données au service de bénéfices et de problématiques métiers : Automatisation de tâches & de choix, Fourniture de nouveaux services « intelligents », Amélioration de l’expérience client, Recommandations, etc.
C’est aussi une discipline qui passionne par son caractère particulièrement « innovant », encore aujourd’hui, mais qui génère des croyances sur ce qu’elle peut réellement apporter à une organisation. Certains dirigeants ont souvent donné trop de valeur intrinsèque à la discipline, s’attendant à des retours importants sur leurs investissements (data lake & armées de data scientist / engineers).
En réalité, la Data Science n’est qu’une technique qui a besoin de méthodologie et de discipline. A ce titre, elle nécessite au préalable de très bien définir les problèmes métiers à résoudre. Et quand bien même le problème est bien défini, et le modèle statistique pour y répondre performant, cela ne suffit pas encore. Le modèle doit être utilisable « en pratique » dans les processus métiers opérationnels, s’intégrer parfaitement dans l’expérience utilisateur, etc.
Quels principes clés peut-on se proposer d’appliquer pour maximiser la valeur de cette capacité ? Essayons ici de donner quelques pistes.
Comprendre le métier : analyser les risques, les besoins d’optimisation, les nouvelles opportunités
L’identification d’usages métier, qui nécessitent des méthodes d’analyse de données avancées, est une étape clé. Ces usages ne tombent souvent pas du ciel. Une démarche proactive avec les métiers est nécessaire pour les identifier. C’est d’autant plus vrai lorsque le métier est encore peu familiarisé avec les techniques de data science, et ce qu’il est possible d’en tirer concrètement.
C’est un travail de “business analysis”, dont la Data Science n’a absolument pas le luxe de se passer contrairement à ce qui est pratiqué parfois : Comment travaille le métier aujourd’hui ? Quels sont ses enjeux, ses drivers, ses axes d’innovation, ses axes d’optimisations des processus opérationnels en place, et quelles données sont manipulées aujourd’hui, comment et pour quoi faire ? Quel est le niveau de qualité de la donnée, manque-t-il des informations clés pour répondre aux problèmes quotidiens, ou pour innover ? etc.
Quand on est au clair sur toutes ces questions, on est prêt à identifier des usages concrets avec le métier, qui pourraient bénéficier de techniques d’analyse avancée.
Comprendre l’usage et le système concerné : adopter le point de vue systémique !
Imaginons que nous cherchons à prédire le flux de patients sur un jour donné dans un hôpital, afin d’adapter les ressources, les processus, les dispositifs pour limiter le temps d’attente. Il convient, avant de foncer tête baissée dans l’analyse des données, de comprendre l’ensemble de la problématique. Par exemple, les approches de « system thinking » peuvent être tout à fait adaptées pour que le data scientist s’assure de ne pas oublier de paramètres clés dans la dynamique du problème qu’il veut résoudre. Ainsi, il n’oubliera pas non plus des données clés pour son modèle (existantes ou dont il faudrait organiser la collecte à l’avenir pour améliorer le modèle).
Ce type de représentation (ici : Causal loop diagram), peut permettre au métier de s’exprimer sur le processus, sur l’identification des variables clés, et de formuler ses intuitions sur les paramètres et les dynamiques en jeu qui peuvent influer sur la variable à prédire ! (ici les influences positives ou négatives entre les variables structurantes décrivant la dynamique du système).
Le diagramme ci-dessus n’est qu’un exemple de représentation systémique, on peut adopter d’autres types de représentation du système au besoin. L’important étant d’étendre la compréhension du système, qui peut nous amener à identifier des variables cachées (non intuitives a priori).
Concrétiser un usage : prototyper au plus tôt avec le métier, dans son environnement de travail, au risque de rester éternellement au statut de POC !
Une fois que le système est bien défini, et que les hypothèses et intuitions sont posées, il faut comprendre : comment le modèle analytique sera concrétisé en pratique, qui sera l’utilisateur final, quel est son environnement de travail actuel et comment on pourra intégrer les résultats d’un modèle statistique dans son travail quotidien.
Une technique simple et confortable pour le métier : faire un prototype rapide, même avec des fausses données pour commencer, des faux résultats de modèles statistiques. Bref, l’idée est rapidement de se projeter dans l’usage final de la manière la plus concrète possible, pour aider le métier à s’inscrire dans sa future expérience. Évidemment, nous ne resterons pas éternellement avec des fausses données.
L’objectif est d’être tout à fait au clair, dès le départ, sur le produit fini que l’on veut atteindre, et de s’assurer que le métier le soit tout à fait (ce qui est loin d’être toujours le cas). Ensuite, nous pourrons pousser le prototype plus loin (des vrais données, des vraies conditions pour évaluer la performance, etc.).
Cette méthode permet au data scientist de se mettre à la place de l’utilisateur final, et de mieux comprendre comment son modèle devra aider (est-ce qu’il doit apporter juste une classification, un niveau de probabilité, des informations contextuelles sur la décision prise par le modèle, est-ce qu’il doit favoriser le temps de réponse, l’explicabilité, la performance du modèle, etc.). Toutes ces questions trouvent rapidement une réponse quand on se projette dans le contexte d’usage final.
Interagir par itération avec le business, éviter l’effet Kaggle
Nous pouvons rencontrer parfois un comportement (compréhensible), qui est de vouloir faire le modèle le plus performant possible, à tout prix. On passe des heures et des jours en feature engineering, tuning du modèle, on tente toutes combinaisons possibles, on ajoute / teste des données exotiques (au cas où) qui ne sont pourtant pas identifiées en phase de “business analysis”. Je l’appellerai l’effet « Data Challenge » ou l’effet « KAGGLE*».
Et après avoir passé des jours enfermés dans sa grotte, on arrive tout fier devant le métier en annonçant une augmentation de 1% du score de performance du modèle, sans même avoir songé que 1% de moins pourrait tout à fait répondre aux exigences du métier… Comme on dit… « Le mieux est l’ennemi du bien ». Pour éviter cet effet tunnel qui peut être tentant pour l’analyste (qui veut annoncer le meilleur score à tout prix ou qui joue trop sur Kaggle*), des itérations les plus fréquentes possibles avec le métier sont clés.
Arrêtons-nous au bon moment ! Et cela vaut pour toutes les phases du projet. Commençons par chiffrer le système décrit en phase de business analyse, avec des données réelles, et itérons avec le métier sur cette base. Cela permet d’améliorer déjà la compréhension du problème du data scientist, et du métier concerné. Et cela a déjà une vraie valeur pour le métier ! Alors qu’aucun modèle statistique n’a été conçu pour le moment.
Si un modèle nécessite des données inexistantes, organisons la collecte de ces données avec le Chief data officer, dans le temps. Mais ne nous battons pas à vouloir faire un modèle avec des miettes, si nous savons que cela ne permettra pas d’être à la hauteur des attentes opérationnelles.
Le Data Scientist peut avoir aussi ce réflexe un peu étrange de dire « On va essayer, on va faire avec ce qu’on a et on verra ! » comme s’il croyait lui-même que son métier relève de l’incantation.
Evidemment, je ne fais là aucune généralité. Le rôle d’expert nous oblige à prendre nos responsabilités, et à dire « Non, après examen et quelques tests, je ne suis pas confiant du tout pour répondre à votre besoin avec les données qu’on a aujourd’hui ». Humilité, responsabilité et transparence, à chaque itération avec le métier, sont de mise.
On trouve souvent ce risque de dérive dans la relation Expert vs Métier. Ne tombons pas dans le piège de jouer sur l’ignorance de l’autre pour se créer un travail inutile !
Ces quelques principes sont peut-être évidents pour certains, utiles pour d’autres ! En tous les cas, chez Rhapsodies Conseil, au sein de notre équipe Transformation Data, nous essayons d’appliquer cela systématiquement, et nous pensons que c’est le minimum vital.
Pour éviter de faire perdre du temps à nos clients (et de l’argent), nous commençons nos missions BI & Analytics, systématiquement avec une « micro mission » préliminaire qui nous permet de valider la réelle valeur & la faisabilité de l’innovation recherchée (avec toutes les parties prenantes, en faisant des analyses flash des données…) avant d’aller plus loin !
Nous considérons que dans tout projet de Data Science, le prototype métier, tel que décrit dans l’article, est obligatoire. Nous proposons systématiquement un prototypage métier, toujours dans le soucis de bien projeter la valeur attendue pour le métier !
Nous allons plus loin sur la solution que l’analyse avancée des données. Notre expertise globale sur la transformation data, nous permet y compris sur des missions BI & Analytics, de ne pas hésiter à relever si pertinents des axes clés d’amélioration sur la gouvernance de certaines données, l’organisation, la data quality, la stratégie data long terme de l’organisation ou la culture data de l’entreprise, qui pourraient être profitables ou indispensables à l’usage traité.
Pour nous, traiter un usage BI & Analytics, c’est le traiter dans son ensemble, de manière systémique ! Notre solution finale n’est pas un modèle statistique. Notre solution finale est potentiellement un modèle statistique, mais aussi une gouvernance adaptée pour avoir la qualité de données nécessaire, un modèle qui s’adapte à l’expérience utilisateur souhaitée (et pas l’inverse), et un suivi du ROI de l’usage analytique et de sa pertinence par rapport à la stratégie de l’entreprise.
Avec l’avènement, la démocratisation de l’intelligence artificielle dans toujours plus de secteurs, certaines questions sont posées :
Les machines vont-elles vous remplacer, allez vous perdre votre travail ? Ce progrès technologique nous rend-il de plus en plus vulnérable ? Le rôle de l’éducation dans ce contexte de transition technologique ? Les machines vont-elles devenir plus intelligentes que vous ? Comment faire confiance à des systèmes de décision parfois complexes voire boîtes noire ?
Pour y répondre, développons quelques points :
Rappelons la place de cette intelligence dans nos vies aujourd’hui.
Rappelons que nous contrôlons bien toujours la machine…
N’exagérons pas les impacts sur le monde du travail, regardons un peu an arrière
Oui, une petite mise à jour du système éducatif français ne serait pas un luxe pour s’adapter plus rapidement aux transitions technologiques de demain
L’IA, il y a quand même des risques : Un grand pouvoir implique de grandes responsabilités. Comme souvent, le risque c’est nous même…
Non, cette forme d’intelligence n’a rien a voir avec l’intelligence humaine, elle ne peut donc pas la « dépasser »
Toutefois, Vous ne pouvez pas faire confiance à n’importe qui, et pour l’IA, c’est pareil… Alors comment fait-on ?
1 – Rappelons la place de cette intelligence dans nos vies aujourd’hui
« Mais comment il s’appelle déjà cet acteur, tu sais celui qui joue dans ce James Bond ? Attends je regarde ! » Aujourd’hui, le « Attend je regarde » a maintenant depuis plusieurs années remplacé le « Attends je réfléchis ça va me revenir ! » (Vous souvenez vous avoir dit cette phrase récemment ?).
Google comprend très bien ce que vous cherchez, mieux que vous parfois… Le web ne se repose pas, disponible 24/24. Comme un nouvel organe qui étend votre cerveau, il vous offre une extension de mémoire extraordinaire, que vous pouvez utiliser quand vous voulez, avec des interfaces toujours plus simples.
Les Smart Phones, les moteurs de recherche qui savent mieux que vous ce que vous cherchez, les nouveaux robots intelligents, les véhicules autonomes, … l’avènement de IA, n’est-elle tout simplement pas comparable à l’avènement de l’électricité et de son usage qui a explosé au 20eme siècle ? On a appris à produire et à distribuer de l’énergie. Maintenant on crée et on distribue une forme d’intelligence.
Quelle est-elle exactement, cette intelligence ?
2 – Rappelons que nous contrôlons bien toujours la machine…
Pour ceux qui l’ignorent et qui peut être craignent ces nouvelles technologies, la plupart des algorithmes qui révolutionnent le monde actuel sont fondés sur des théories (pas si récentes) issues par exemple des statistiques, de la probabilité, l’optimisation et la recherche opérationnelle. Je vais peut être estomper les fantasmes de certains, mais aujourd’hui une machine ne peut pas apprendre sans avoir :
Une question précise à laquelle répondre
Un volume et un périmètre de données (d’observations) suffisamment conséquents pour pouvoir modéliser le phénomène sous-jacent et répondre à la question
Des capacités de traitement, et l’énergie qui alimente ces capacités
Et vous savez quoi ? Ces trois prérequis nécessitent aujourd’hui notre intervention humaine. Nous choisissons les problèmes auxquels nous voulons que les machines répondent, nous sélectionnons les sources de données qui permettent à la machine d’apprendre une façon d’y répondre, nous fournissons les capacités de traitement et l’énergie nécessaire. Alors de quoi avez-vous peur ?
Comme souvent, le seul danger, c’est nous même… Nous en reparlerons tout à l’heure.
3- N’exagérons pas les impacts sur le monde du travail, et rappelons nous du passé…
Pour rafraîchir la mémoire de certains, posons nous 5 minutes sur 3 emplois, au hasard, qui n’existent plus aujourd’hui, et ça ne choque plus personne … :
Le Poinçonneur : Vous savez c’était le monsieur qui faisait « des petits trous, toujours des petits trous » sur vos billets de métro il y a bien longtemps…Maintenant, vous avez un Pass Navigo…
Le Télégraphiste : Ils transmettaient les télégrammes ! Et vous savez quoi ? Il n’y a plus de télégraphes aujourd’hui…Maintenant vous utilisez internet…
Le Laitier : « Le quoi ? » Lui était chargé de transporter le lait frais au plus vite avant qu’il ne périsse pour être consommé. Aujourd’hui, vous allez au rayon frais dans votre épicerie la plus proche…
Alors ? Devons nous réembaucher des Poinçonneurs sur les lignes du métro parisien ? Devons nous réinstaurer les télégraphes pour remplacer progressivement internet, parce que quand même ça créerait de l’emploi ! Devons nous revoir notre gestion de la chaîne du froid et simplifier tout ça spécifiquement pour le lait en embauchant quelques laitiers ? Je vous laisse le choix des réponses à chacune de ces questions.
Certains métiers vont évoluer. Certaines tâches seront automatisées ce qui permettra d’approfondir les aspects les plus important du métier, les plus « Humains » ?
Prenons l’exemple du Responsable RH :
Aujourd’hui, ilpasse des heures sur son LinkedIn pour trouver le profil miracle, lisant des tonnes et des tonnes de profils, sans trop savoir auquel se fier et lequel a vraiment une chance de lui répondre…
Demain (et aujourd’hui ça commence déjà) un algorithme pourra lui proposer les profils qui ont le plus de chance d’exceller (et de répondre) pour un poste donné. Les responsables RH passeront plus de temps à préparer un entretien personnalisé avec la personne, en creusant les bons aspects, pour être sûr de prendre la bonne décision. Un partenaire qui deviendra indispensable ?
Il y aura peut être moins de responsables de recrutement alors ? Peut être, mais pas du jour au lendemain.Les choses ne se font pas d’un coup. Il faut du temps pour transformer les entreprises mastodontes… Il faudra du temps pour prendre conscience qu’il faut moins de responsables de recrutement et plus de Data Science, et trouver les bonnes ressources formées, et surtout pour mettre au point les bonnes solutions…
D’ailleurs, nos petits seront-ils formés sur ces sujets ? Nos grands pères à 5 ou 10 ans de la retraites pourront-ils se reconvertir ?
4- Une petite mise à jour du système éducatif français ne serait pas un luxe pour s’adapter plus rapidement aux transitions technologiques de demain
De manière plus générale, concernant ces périodes de rupture / transition technologiques, le système éducatif (français) manque surement de flexibilité. Il est pensé pour être globalement adapté à tous, alors qu’il devrait l’être, de plus en plus, pour pouvoir s’adapter à chacun, et au monde du travail. Je ne dis pas que c’est simple…
Mais par exemple, aujourd’hui, l’outil informatique devrait être porteur de flexibilité dans le système éducatif, mon avis est qu’il n’est pas assez utilisé (au risque d’offusquer certaines personnes…) . Formations en ligne et/ou en autonomie ? Oui, il est possible d’apprendre seul devant son PC aujourd’hui; Il existe des outils totalement adaptés pour les professionnels et pourquoi pas pour les collégiens et les lycéens ? Attention : Je dis bien, A défaut de professeurs spécialisés sur un sujet nouveau par exemple comme l’intelligence artificielle, l’élève devrait pouvoir s’auto-former et passer un examen type Bac spécialisé dans les nouvelles technologies de l’information, sur la base de cet enseignement, s’il est motivé, pourquoi pas ? Il réussira.
De même, pour toutes personnes dans la vie active qui sont tout à fait aptes à se former rapidement sur un nouveau domaine innovant, pourquoi ne seraient-ils pas aussi brillants dans ces nouveaux domaines que des petits jeunes sortis d’école ? si on leur donne aussi les moyens de s’auto-former et de passer des examens spécialisés plus simplement.
Plus globalement : « C’est en forgeant, que l’on devient forgeron ». Dans ces périodes de transitions technologiques, cette phrase devrait inspirer les recruteurs, qui devraient plus prendre en compte la capacité d’un candidat à apprendre rapidement, à s’adapter à des situations différentes / nouvelles, plutôt que de s’obstiner sur les petites lignes de diplômes du CV.
5- L’IA, il y a quand même des risques: un grand pouvoir implique de grandes responsabilités. Comme souvent, le risque c’est nous même
Plus il y aura d’actions automatisés, et connectées, plus la société sera vulnérable à la cyber-attaque, et plus les exigences de sécurité seront élevées.
Les données peuvent être utilisées à bon escient pour améliorer notre manière de vivre, se re-concentrer sur l’essentiel dans un monde que nous avons nous même rendu plus complexe qu’il ne l’était… Malheureusement, il peut être utilisé à mauvais escient.
Comme on dit, un grand pouvoir implique de grandes responsabilités… Les fournisseurs Cloud par exemple ont une grande responsabilité. Une grande ressource de calcul ne devrait plus demain être vendu au premier venu, car elle peut être une arme.
L’IA peut en exemple être utilisé pour élaborer des attaques plus intelligentes. Il faudra alors aussi prévoir des systèmes de défense plus intelligents. Vient la course aux armements version IA… L’actualité nous fait déjà entrevoir ces cyber-guerres (la potentielle intervention de la Russie dans l’élection de monsieur Trump en est un exemple). Les hackers commencent déjà à utiliser le Machine Learning comme levier d’attaque. Vous trouverez par exemple, cet article qui traite du sujet.
6- Non, cette forme d’intelligence n’a rien à voir avec l’intelligence humaine, elle ne peut donc pas la « dépasser »
Si cela vous inquiète vraiment, c’est que vous manquez simplement d’informations sur le sujet. Comme discuté au point 2 de cet article, il n’y a absolument aucune technologie ni même aucune démarche scientifique aboutie qui permette à une machine d’égaler l’intelligence Humaine. La forme d’intelligence produite par les algorithmes actuels et la forme d’intelligence qui habite votre cerveau n’ont absolument rien à voir : L’un est fait pour répondre à un problème bien précis,l’autre est capable de penser, d’inventer, de créer, d’aimer, et ce depuis 200 000 ans…(et de répondre aussi à plein de problèmes, bien précis…)
7- Toutefois, vous ne pouvez pas faire confiance à n’importe qui, et pour l’IA, c’est pareil… Alors comment fait-on maintenant ?
Cette nouvelle forme d’intelligence se diffuse peu à peu pour offrir toujours plus d’efficacité. Elle permet à l’entreprise de prendre certaines décisions de manière moins intuitive et plus mathématique/statistique, lorsque le sujet et les données le permettent.
Reste toutefois à poser un cadre claire de ce que nous souhaitons vraiment faire de ces nouvelles capacités et de ce que nous nous interdisons d’en faire. C’est une question que chacun doit se poser aujourd’hui. Certaines décisions ne devraient-elles pas être prises que par l’homme ? Une machine doit-elle avoir le choix de vie ou de mort ? Demain, la voiture autonome doit-elle avoir à choisir entre percuter la vieille dame ou l’enfant ? Il s’agit de maîtriser le risque et l’éthique.
Reste également, et c’est crucial, à se donner les moyens de mieux comprendre comment décident les algorithmes les plus complexes (exemple : Réseaux de neurones, Deep Learning) qui sont souvent trop opaques. Sinon nous pouvons valider un modèle alors que, par exemple, sa manière de décider n’est en fait pas éthique du tout (ex : Discriminations raciales, etc…). Pour ceux que ça intéressent, une méthode comme LIME vise à innover dans ce domaine : Why Should I Trust You ? Il existe d’ailleurs déjà des librairies de développement dans ce domaine.
Une image pour finir : Dans chaque décision humaine se cache une motivation. Par exemple, si quelqu’un vous donne un bon conseil, que vous le suivez, et que vous vous rendez compte qu’il en a en fait plus profité que vous, vous n’aurez plus confiance en cette personne ? Non ? Si par contre, ce même conseil vous est donné de bon cœur avec bienveillance, alors vous ferez confiance en cette personne ? un nouvel ami ? La motivation est tout aussi importante que la décision en elle même, aussi juste puisse-t-elle paraître a priori (donner un bon conseil…). C’est la même chose avec l’IA. Si nous ne savons pas justifier/comprendre les décisions (conseils…) qu’elle nous donne, alors ça ne peut pas être notre partenaire, ou du moins c’est risqué.
Vous êtes probablement en train de mettre en place votre « Data Lake », « Data Hub » et autres « Data Labs ». A cet instant, nombreux sont les vendeurs autour de vous, briguant une place dans votre cœur…Ils peuvent tout changer ! Ils peuvent faire de vous un brillant Chief Data Officer…
« D’abord, Migrez toutes vos données dans le Cloud sans inquiétude, c’est là que vous trouverez nos outils magiques qui tirerons toute la valeur de vos données ! » Allez, avouez qu’il ne le disent pas comme ça, mais que ce n’est qu’à peine caricaturale. Une variante ? : « Si vous voulez être THE Data Driven Company, notre outil est fait pour vous. Et, il est justement tout à fait adapté et pensé pour votre métier et vos données. Alors Essayez-le. Nous avons même ce qu’il faut pour vos Data Scientist. Tout en un ! ». En changeant quelques mots de leur beau scénario, on ne serait pas si loin d’une pub pour dentifrice…
Je vous prie de ne pas répondre trop vite à ces « experts » de la donnée. De même, n’embauchez pas trop hâtivement une armée de jeunes « Data Scientists ». Ne leur dites pas qu’ils sont l’avenir et qu’ils vont construire des algorithmes des plus innovants, quand au final ils deviendront les rois des Dashboards à faire pour hier.
Votre seul objectif en tant que CDO est de mesurer et d’augmenter la valeur des données de votre Organisation. Et avant d’embaucher qui que ce soit, ou d’avoir le plus gros Data Lake avec le plus de données possible pour justifier l’existence de votre équipe, si vous commenciez par structurer deux approches : L’une par la valeur « Potentielle » de vos données, l’autre par sa valeur « Effective » :
Augmenter le potentiel de vos actifs Data stratégiques :
Appréciez et faites comprendre aux acteurs de votre entreprise la valeur de son patrimoine data. Peut être, allez-vous à la salle de sport tous les jours, ou peut être faites vous votre petit jogging quotidien ? Les gens vous disent : « Tu as l’air en forme, tu es en bonne santé ! ». Et vos données sont-elles en bonne santé ? Qualité ? Disponibilité ? Sécurité ? Travaillez sur vos assets transversaux (Client, Produit, …), assurez-vous qu’a minima leur santé est assurée par une gouvernance adaptée. Sécurisez ce potentiel minimal. Documentez, explorez, améliorez la valeur intrinsèque de vos données clés, mettez à disposition des données à potentiel à vos analystes (via une plateforme adaptée : « Data Lake » ou autre !). Mais ne faites pas que ça, ou c’est la gueule de bois assurée.
Augmenter la valeur effective de vos données :
Parce que ce sont les usages de la donnée qui concrétisent réellement sa valeur, dans le même temps, travaillez continuellement avec les métiers pour comprendre et répondre à leurs usages concrets des données, et améliorez les usages existants !
Et pas seulement les usages qui rendent heureux vos Data Scientists et vos vendeurs de dentifrices préférés. Vous devriez précisément connaître les usages actuels des données pour lesquels certains collaborateurs bondissent : « Cette donnée ne sert à rien ! Je ne peux pas faire mon travail ! Je perds un temps fou, tout est faux 🙁 » Et s’il vous plaît, faites quelque chose pour eux en priorité, rentrez dans leur quotidien et leurs moultes fichiers excel, et changez les choses car vous êtes responsable. Améliorez la valeur d’usage de vos données.
Cher CDO, acheter une belle plateforme dans le Cloud et embaucher quelques Data Scientists ne suffira malheureusement pas à améliorer la valeur de vos données. Avant toute chose, assurez-vous que votre organisation est bien fondée sur l’équilibrage de deux axes clés :
1/ transformez des usages à valeur ajoutée grâce aux données
2/ développez le potentiel de votre patrimoine data pourrait bien vous faire gagner du temps et de l’argent.
« Gouvernance », le mot fait souvent peur. Si vous êtes consultant, vos clients les plus opérationnels vous font certainement un sourire poli quand vous évoquez le sujet, alors qu’ils pensent « Mais qu’est ce qu’il veut encore me vendre celui-là. Une machine à gaz qui va prendre beaucoup de temps, beaucoup de slides, et ne servir à rien ! » ; « Vous savez, nous avons déjà bien d’autres sujets à traiter ».
« Gouvernance des données », vous amenez l’expression avec habileté, en rappelant le volume considérable des données qui deviennent de plus en plus complexes à maintenir, sécuriser, exploiter, BLA, BLA, BLA. Et votre client le plus pragmatique vous dira « C’est bien gentil, mais ça ne m’aide pas à répondre à la demande de ce matin de l’équipe Marketing qui veut que je lui propose une solution pour cibler plus intelligemment les opérations / campagnes marketing… ou celle de l’autre jour de l’équipe Finance, qui n’en peut plus de faire à la main tous ses rapports sur Excel… »
Toute gouvernance, la gouvernance de données incluse, doit être une solution pour répondre à des usages et des points d’attention du métier (la DSI étant un métier parmi les autres).
Évitez la gouvernance de données pour la gouvernance de données !
Il existe une démarche qui a depuis longtemps trouvé sa place dans de nombreuses entreprises, mais qui a très vite montré ses limites, la voici (cela va vous parler si vous avez déjà challengé vos consultants sur le sujet) :
On va modéliser toutes les données existantes dans votre système d’informations
On va identifier les sources applicatives associées à ces différentes données
On va désigner des responsables pour chaque objet de données (des data owners, data stewards, …)
On va écrire des processus de gouvernances des données (validation, workflow, …)
On va mettre en place une instance de gouvernance sur la donnée
On fait tout ça d’abord avec notre vision DSI, on ira voir les métiers une fois qu’on aura une démarche déjà bien en place…
Alors, cela vous rappelle quelque chose ? Cette démarche : c’est faire de la gouvernance pour… SE FAIRE PLAISIR !
Une fois à l’étape 6, je vous défie de répondre précisément à la question suivante : « Alors, à quoi sert-elle cette nouvelle gouvernance ? Que va-t-elle améliorer précisément pour le marketing ? pour l’équipe financière ? pour l’équipe communication ? etc. ». N’ayez aucun doute là-dessus, la question vous sera posée !
La gouvernance des données doit être une solution pour mieux répondre aux usages :
Vos métiers utilisent les données. Ils savent ce qui doit être amélioré, ce qui leur manque comme données pour mieux travailler, tout ce qu’ils doivent faire aujourd’hui pour parer aux problématiques de qualité des données, le nombre de mails qu’ils doivent faire pour trouver la bonne donnée, parfois en urgence, pour leurs usages courants … Ils savent tout cela. Alors plutôt que d’inventorier toutes les données de vos systèmes, partez des usages des métiers et de leur point de vue et formalisez ces usages existants et les usages de demain
Concentrez vos efforts de gouvernance pour améliorer ou permettre les usages à plus forts enjeux ou risques pour l’entreprise
Cherchez à maîtriser l’ensemble de la chaîne de valeur, usage par usage (de la collecte à l’utilisation effective de la donnée pour l’usage) : organisation, responsabilités, outillages/SI
Faites évoluer votre gouvernance par itération, en partant toujours des usages.
Comprenez la stratégie de votre entreprise. Votre direction générale doit être sponsor. Donnez-lui les éléments pour la faire se prononcer sur une question simple : Sur quel pied doit danser en priorité la gouvernance Data, 40% sur le pied offensif (Aide au développement de nouveaux usages innovants), 60% sur le pied défensif ? (Gestion des risques GDPR, maîtrise de la qualité des données concernant les usages identifiés les plus critiques, …) ? 50/50 ? Elle doit vous donner les clés pour prioriser et itérer en adéquation avec la stratégie de l’entreprise.
La gouvernance des données est avant tout un sujet métier. Vous ne le traiteriez pas correctement en restant dans votre étage DSI… Cela peut paraître évident. Mais même quand certains le savent, ils choisissent la facilité : Rester à la maison…
Sortez, rencontrez tous les métiers, et vous formerez une base solide pour votre gouvernance. Ne sortez pas, et vous perdrez beaucoup de temps et d’argent…
Plusieurs questions se posent aujourd’hui, alors que de nombreux environnements Hadoop sont en production depuis quelques mois / années :
Le Data Lake est-il aussi utile/utilisé que prévu ? et ne l’utilise-t-on pas, à défaut d’avoir trouvé un usage pertinent, à des fins qui n’étaient pas prévues au départ ( exemple courant … GPP : Gros Passe Plat ou encore EDDC : Extracteur De Données Centralisé … )
Comment structurer les données dans le Data Lake ? Si c’est pour mettre un Hadoop chez soi et structurer sa donnée dans quelques parquets et des tables hive, mais avec la même logique que nos bonnes vieilles tables SQL normalisés 3NF, à part de dire « Youhou, hadoop on l’a fait, on en a une belle maintenant ! » Quel intérêt ? C’est comme s’acheter une console Switch en ne la décrochant jamais de son socle (pardon pour l’image pour ceux qui ne connaîtraient pas la dernière console de Nintendo…).
Comment on rend la valeur de l’outil palpable par l’utilisateur final ? Que ce soit pour du reporting quasi temps-réel / journalier / mensuel, de la Data Viz ou de l’analyse de données avancée (un super Random Forest, un neural Network au top en production…) qu’est ce qui fera la différence pour l’utilisateur final ? Par rapport à ce qu’on lui donnait déjà avant…
J’essaie de donner des éléments de réponses ci-dessous et ce n’est que mon humble avis. Si vous avez vos expériences à partager n’hésitez pas.
1 – Le data lake est-il aussi utile/utilisé que prévu ?
Les environnements distribués naissent un peu partout au moment ou j’écris ces lignes. 2 cas caractéristiques existent qui peuvent être problématiques :
Cas 1 – Etre gourmand, trop gourmand : De nombreuses entreprises se sont ruées vers la tendance sans même vraiment avoir eu une réflexion de fond sur la valeur que devraient leur apporter ces nouvelles capacités dans leur contexte, elles se retrouvent aujourd’hui avec des téras stockées qui ne leur apportent pas autant qu’elles l’auraient espérées. On a voulu en mettre beaucoup, on n’a pas pris le temps de travailler sur la description de ce qu’on y a mis (meta data), et peu de gens comprennent vraiment ce qu’on peut y trouver et si c’est vraiment fiable.
Leur Data Lake devient petit à petit un passe-plat facilitant préparations et fournitures de certaines données bien spécialisées, même sur des volumes qui ne justifient en rien son usage, opérant quelques croisements ici et là entre sources originales qui n’étaient pas avant dans le même environnement technique. Elles font face à des bi-modes Hadoop VS Entrepôt Oracle/SAS (pour ne donner qu’un exemple). Certaines données sont dans les deux types de système et l’utilisateur Analyste ne sait pas vraiment lequel utiliser. Alors les Data Scientist, statisticiens – vieux de la vieille continuent à bosser dans SAS parce qu’ils n’ont pas le temps d’apprendre Python, et les petits jeunes qui sortent d’écoles pensent pouvoir changer le monde avec leur modèle de churn codé en Python / Spark mais qui a en réalité déjà été implémenté il y a 10 ans par un Data Miner expert SAS avec une méthode et des résultats similaires… Ce n’est qu’un rien caricaturale.
Pour prouver sa valeur et justifier son coût, ce Data Lake là va devoir se recentrer sur des usages clés porteur de valeur (et de gain euros…) pour l’entreprise, qui justifie son existence, ou mourir de désillusion ou rester un gros GPP (gros passe plat…).
Cas 2 – Etre timide, trop timide : D’autres entreprises plus prudentes, fonctionnent en petites itérations, à base de POC Big Data sous Microsoft AZURE, AWS et autres google cloud, en sélectionnant des cas d’usages qui justifient l’utilisation de telles plateformes. Parfois, le risque est d’être dans l’excès inverse du premier cas, en priorisant trop et en ne montrant rien.
Trouver 3 usages coeur de métier pour commencer est une excellente chose, mais les cas d’usages doivent être assez complets pour montrer l’étendue des possibilités que peut apporter un environnement comme hadoop et tous ses petits (la multitude d’outils d’intégrations, d’analyses, de traitements qui se basent sur hadoop).
Toutefois, faire un vrai POC métier est la clé pour les entreprises qui en sont à ce stade, montrer que Hadoop traite très très très vite un très très très gros volume de données, n’apporte rien au métier. Faire une démo d’un outil métier qui illustre un vrai cas métier en mettant en valeur :
La performance ressentie par l’utilisateur (des jolis diagrammes qui s’affiche rapidement quand l’utilisateur clique sur la carte 🙂 « C’est beau, ca va vite, c’est utile ! ouaouh ! »
La valeur/connaissance apportée en plus en allant au bout de l’usage : On sait détecter un problème, une fraude, etc…et ça génère une alerte en temps réel dans l’outil de l’opérateur qui lui recommande l’action à faire ! Ouaouh merci c’est ce qui fallait ! c’était possible alors ? dingue…)
Dans tous les cas, encore une fois allez au bout de l’usage ! On a tendance à s’arrêter juste un peu avant ce qu’il faudrait (par manque de temps, de connaissance métier, de courage). Ne faites pas un POC IT, ayez le courage de faire un vrai POC business pas juste à moitié parce que vous ne connaissez pas assez le métier, allez jusqu’au bout de la démonstration, jusqu’à la jolie petite interface interactive qui fera la différence. Sinon vous n’aurez pas votre Waouh. Faites collaborer les Data Scientist avec les développeurs des appli métiers pour avoir un vrai résultat.
Si vous ne faites pas cela, les gens comprendrons peut être la théorie « D’accord vous faites une grosse boîte où vous mettez toutes les données et puis ça tourne vite comme une machine à laver, c’est ça ? 🙂 ».
Non ! vous voulez un : « Ah, mon opérateur ne va plus devoir scruter toutes les logs à la mano pour essayer de trouver les problèmes, et je vais multiplier par 10 ma productivité donc…En fait…Ai-je toujours besoin d’un opérateur ? » OUI, là on est bon.
2 – Quelques principes pour structurer le data lake
Ne traitez pas votre Data Lake comme une poubelle à données qu’on recyclera peut être un jour en cas de besoin (le fameux « on prend, on sait jamais » du Data Lake, anti GDPR par dessus le marché). Mais traitez le bien comme un lac nourrissant, abreuvant et vital ! Moins de quantité, plus de qualité.
Structurer vos Données intelligemment. Ce n’est pas parce que vous avez beaucoup de place que vous pouvez en mettre de partout et n’importe comment (que dirait votre mère franchement?). Votre Data Lake doit normalement séparer :
Les données sources (Raw Data)à l’image des données du système sources
Les données sources (Raw Data) retraitées uniquement par applications de règles purement techniques (votre format de date standard, types de données, etc…). Pas de règles métiers ! Pas ici, le but est juste de récupérer la donnée brute ! C’est d’ailleurs un sage principe que vous trouvez aussi dans la philosophie DataVault de Dan Linstedt. Vous n’appliquez des règles métier qu’au moment de la construction de vues métiers qui répondent à un usage donné. C’est aussi surtout du bon sens…Cela apportera bien plus d’agilité à l’ensemble du système.
Une Historisation structurée et intelligentedes données du Data Lake. « OH Non ! Il a dit « structuré » et « Data Lake » dans la même phrase le monsieur, c’est pas joli ». Malheureusement, beaucoup d’entreprises oublient cette étape. Mais pourquoi donc ? Suivez par exemple ici (encore désolé…) la modélisation Data Vault 2.0, je parle principalement des concepts de Hubs, Links, Satellites, ou au moins la philosophie pour cette partie. Vous pouvez éventuellement exclure de cette phase certaines données exceptionnelles (par exemple si ce sont des données vraiment peu utilisées très spécialisées, que vous savez ponctuelles comme des données externes one shot (que vous n’achetez pas tous les mois…).
!!! Attention je ne dis pas qu’il faut faire un Data Warehouse d’entreprise dans le Data Lake (je ne rentrerai pas dans ce débat). Le Data Lake doit couvrir un certain nombre de cas d’usage spécifiques, qui nécessitent d’historiser (avec agilité !) un certain périmètre de données, qui tend à grandir au fur à mesure que les nouveaux cas d’usages apparaissent.
Si vous vous arrêtez aux Raw Data et aux business View et que vous ne mettez rien entre les deux, que vous ne faites pas ce travail de structuration fonctionnelle, au bout d’un moment vous aurez un gros sac de données applicatives, et les Data Scientists et autres utilisateurs devront eux même comprendre la logique de recoupement de toutes les sources (notamment le grain, la définition des clés techniques/métiers, etc.). Faites ce travail de structuration de l’historisation (DataVault 2.0 recèle de bonnes idées).
Les données préparées pour être prêtes à l’Usage (Business View), requêtables rapidement pour usages business. C’est dans la consolidation de chacun de ces socles que les règles métiers sont appliquées ! Ici, On ramène les données au plus proche de l’usage et structurées pour l’usage en question. Et n’hésitez pas à dé-normaliser vos Business View! Vous n’êtes pas dans mysql… Plein de lignes et plein de colonnes ? C’est fait pour ! Vous pouvez même aller (dans certains cas) jusqu’à pré-calculer dans une grosse table adaptée tous les indicateurs sur toutes les combinaison de segments (dimensions), de périodes, de dates… (attention, intérêt à mesurer par rapport à votre propre usage de consommation de la donnée), mais ça se fait : « ouahou ! comme les graphiques s’affiche vite… »
Les métadonnées : leur intégration peut se faire de diverses manières, mais faites en sorte que les gens ait confiance aux données qu’ils utilisent (C’est quoi cette donnée ? d’où vient la donnée ? quelle application, quel fichier source ? Qui l’a saisie ? Quand l’a-t-on intégré au Data Lake ? quelle fréquence de mise à jour ? etc.)
3 – Comment on rend la valeur de l’outil palpable par l’utilisateur final ?
Ne croyez pas (et je suis sûr que vous ne le croyez pas) que votre Data Lake se suffit à lui même
S’il est déjà bien structuré (c’est déjà un gros avantage), il a quand même besoin de belles décorations :
je ne vous apprendrai rien : un outil de Data Viz/report qui plaît au métier (parce qu’il a été impliqué dans son choix…). Je ne ferai pas de pubs ici…
Une bonne intégration avec les systèmes opérationnels et dans les deux sens (un savoir faire sur le sujet), pas qu’en collecte. Par exemple : Lancer des simulations directement depuis mon application de gestion qui va lancer un job spark sur la business view associée qui elle va renvoyer des résultats en un rien de temps sur l’application de gestion : L’utilisateur est heureux, il ne connaît pas Hadoop ou Spark, il ne veut rien en savoir, mais vous avez amélioré significativement sa façon de travailler. C’est ce qu’il faut viser. C’est cela aller au bout de l’usage.
Un environnement complet d’analyse pour vos Data Scientist (Data Viz, développement IDE, collaboration/gestion de version, notebooks, les bonnes librairies de dev !) parce qu’ils en ont besoin. Impliquez réellement les principales personnes concernées dans ce choix !
Pour conclure, les idées clés :
Les usages doivent toujours driver la construction itérative de votre Data Lake
Ne cherchez pas à refaire un/des Data Warehouse 2 sans vraiment savoir par qui, pour quoi ce sera utilisé, ne cherchez pas à manger un maximum de données pour devenir le plus vite possible la plus grosse base de données et justifier le nom de votre équipe, BIG Data, j’imagine…
Si on vous pousse un usage auquel on pourrait répondre sur une base mysql, redirigez gentiment le destinateur…A moins que vous soyez force de proposition pour faire évoluer son usage pour justifier l’utilisation d’une telle plateforme.
Si vous êtes assez matures, ne voyez plus votre Data Lake comme un Lab collecteur qui se suffit à lui-même, si vous allez au bout des usages, vous serez obligés de l’intégrer avec des applications métier (vous savez, l’utilisateur qui clique dans son appli et ça lui sort toute sa simulation en 0.5 secondes…).
Inspirez-vous de la philosophie de monsieur Data Vault 2.0 (Dan linstedt) (je ne dis pas qu’il faut tout prendre, mais au moins inspirez vous des concepts de Hub / Links / Satellites qu’un enfant de 4 ans peut comprendre pour une structuration agile de l’historique de vos données). Cela évitera bien des noeuds au cerveau à vos utilisateurs, Data Engineer et Data Scientist, et cela apportera de l’agilité au bout du compte.
Dé-normaliser vos vues métiers ! Dénormalisez vos étoiles, vos 3NF, ça ira bien plus vite !
Le Data Scientist « Stateu » doit ouvrir les yeux au Data Scientist « Informaticien » sur ce qu’il est vraiment en train de faire tourner. Le Data Scientist « informaticien » doit apprendre au Data Scientist trop « stateu » à produire du code industrialisable et réutilisable. Recrutez les deux types de profils (Ecoles de stats, et école d’ingé informatique)
Si vous faites collaborer vos Data Scientist avec les équipes de développements des applications métiers, alors c’est que vous êtes sur les bons usages…
