Actualité web & High tech sur Usine Digitale

Comment rater son projet big data en 10 leçons

|
Twitter Facebook Linkedin Google + Email
×

Si vous croyez que le "big data", et la "data science" en particulier, relève de la magie et est l'affaire de magiciens compétents en mathématique, informatique, visualisation, métier … Lisez ces lignes. Si vous n'y croyez pas... Lisez les aussi.

Comment rater son projet big data en 10 leçons
Comment rater son projet big data en 10 leçons

Pour la plupart des dirigeants et managers de PME, le "big data" et la "data science" en particulier relèvent de la magie. Pour pratiquer ses rites, il faut trouver des magiciens compétents en mathématique, informatique, visualisation, métier … Cette croyance génère deux biais majeurs auprès de ceux qui décident d’initier ce type de projet. La conviction qu’essayer de comprendre comment cela fonctionne serait une perte de temps (et prétentieux). Le sentiment que cadrer le projet devient inutile.

 

Demande-t-on à un magicien s’il doit faire sortir du chapeau plutôt un lapin ou une grenouille ? Non. On le regarde faire, c’est tout.

Nous allons nous intéresser ici uniquement à ce deuxième biais. Cette exploration se fera sous l’angle décalé de dix conseils pour rater son projet (big) data. Prenons la métaphore de la potion magique pour l’illustrer. Un village voisin des irréductibles gaulois veut aussi avoir une potion magique. Il a bien observé et croit avoir compris le mode d’emploi. Suivons le progresser d’échec en échec (mais à la fin il réussira !)

 

1- Commencer par "big"

Quand on fait un projet big data il faut être crédible. Allons-y franchement et allons tout de suite là où les ingrédients se ramassent à la pelle : logs web, réseaux sociaux, …

Résultat : il y a de la valeur, mais il faut y mettre le prix, tant en infrastructure qu’en compétence, pour un résultat incertain. Il n’y a pas pourtant besoin de très gros volumes pour exploiter la puissance algorithmique : ce qui compte est moins le nombre des observations que la richesse de chacune.

Les entreprises peuvent commencer par valoriser leurs données internes, moins volumineuses mais intrinsèquement riches et ne nécessitant pas d’infrastructure particulière. Décloisonner les données marketings, comptables, RH, SI, … permet de reconstituer le contexte global de l’entreprise et de produire des analyses algorithmiques percutantes, tant en prédiction qu’en diagnostic. La compréhension d’une sur / sous performance commerciale par exemple doit intégrer toutes ces dimensions. Le coordinateur de ce décloisonnement de l’entreprise par ces données pourrait être le contrôleur de gestion : un scénario à réfléchir.

 

2 - Commencer par acheter ou construire une marmite

DMP, datalake, … difficile de pouvoir démontrer qu’on fait du big data (et c’est important de nos jours) si on ne peut exhiber un de ces ustensiles. Ils sont pourtant coûteux et induisent de nombreux choix techniques. Ne pas savoir pourquoi et comment ils seront utilisés rend tout choix rationnel douteux.

 

Résultat : un datalake (un gros entrepôt de données assez souple pour y mettre n’importe quoi), avec des projets centrés sur le fonctionnement du datalake (on peut s’y noyer), sans connexion métier. Le premier cas d’usage des projets big data est souvent la « connaissance client 360° ». Cet objectif est intellectuellement satisfaisant mais il n’est concrètement jamais terminé, et, le serait-il, il n’induit en lui-même aucun changement. Réunir physiquement les données n’est pas un prérequis pour tester la valeur générée par leur mise en commun. Un poc peut le tester directement et suggérer l’ordre dans lequel un investissement informatique de regroupement de données se justifie. Il est vrai que cette démarche oblige à se poser la question de l’objectif en amont : c’est tout de suite plus difficile.

 

3 - Commencer par recruter un druide

Seule une personne consacrée pourra extirper de la valeur des données. Rien ne sert donc de s’esquinter à quoi que ce soit tant qu’il n’est pas arrivé. La démarche projet est aisée : passer une annonce de recrutement en mettant dedans tous les buzzwords (hadoop, spark, deep learning, …) et indiquer l’ambition associée, par exemple : faire du reporting commercial (sic).

Résultat : un recrutement qui traine ou un recruté qui s’ennuie (personne ne sait quoi lui demander)

 

4 - Commencer par les ingrédients

Il semble évident que dans big data le mot important (après "big") c’est "data". L’étape 1 suggérait de commencer par les données métier. Il est hors de question de se retrouver ridicule avec 3 carottes et un brin de persil à montrer au druide au moment de faire la potion. Allons-y franchement : météo, données de circulation, réseaux sociaux .... Nous pouvons à présent aller voir le cuisinier / druide fièrement et lui dire : allez-y !

 

Résultat : Il y a du bon à multiplier les sources de données pour les croiser. Mais multiplication de sources ne remplace pas une expression de besoin. L’analyste attendra une commande précise pour commencer à travailler ou il inventera un besoin. Un enrichissement progressif de l’environnement de données peut être aussi plus efficace qu’une dispersion d’entrée de jeu.

 

5 - Poser une question et s’y accrocher coûte que coûte

Tous les échecs précédents étaient assez évidents. Celui-ci est plus subtil. Certes. Si vous êtes arrivé à ce stade vous êtes déjà un amateur éclairé, digne de capter l’attention d’un druide. Mais vous pouvez faire mieux.

 

Un exemple pour l’illustrer. Une entreprise veut anticiper ses ventes pour produire au plus juste. C’est une démarche de bon goût : la question semble précise et le problème bien posé. Tellement bien posé qu’on risque d’y apporter une réponse. C’est là un des problèmes des algorithmes : ils répondent toujours même s’ils n’ont rien à dire. L’analyste va sortir de sa boite à outils des algorithmes supervisés. Cela veut dire qu’il va se baser sur les réponses passées associées à certains contextes pour en déduire une réponse future associée à un nouveau contexte. On va donc reproduire le passé.

 

Résultat : Comme l’objectif est de décider de la production optimale, l’analyste va retirer la production des paramètres de son modèle. Hélas le premier facteur qui définit les ventes passées est justement la production passée : sous production = ruptures de stock, surproduction = déstockage. Le modèle mouline du vide.

 

Poser une question est essentiel. La première ne sera probablement pas la bonne. Il faut corriger le tir régulièrement. Dans le cas présent on pourrait envisager de chercher la production qui optimise la marge ?

 

6 - Laisser le druide seul avec sa marmite (effet tunnel)

Imaginez : le druide a sa commande précise, des ingrédients, une marmite (éventuellement) … Il s’enferme dans son laboratoire. 2 ou 3 mois plus tard il ressort ravi de son travail.

 

Résultat : le demandeur a oublié sa question, il ne comprend pas la réponse ou il comprend qu’elle est à côté de son besoin. Une modélisation est souvent assez rapide ; c’est l’optimisation fine qui prend du temps : ajuster la question posée, tester de nouvelles sources de données, de nouvelles approches algorithmique (aller du simple vers le complexe) Une adaptation des démarches projet agile est nécessaire pour faire progresser simultanément celui qui pose la question et celui qui ajuste la réponse algorithmique.

 

7 - Séparer celui qui exprime le besoin et celui qui analyse les données

Imaginons la gestion de projet suivante, classique. Une équipe projet analyse les besoins métier, formalise et ajuste le besoin, identifie les données qui semblent pertinentes, formalise la question cible. Une fois ce travail fait, toutes ces données (les "data" et la formalisation du besoin) sont livrées à l’analyste, qui n’a pas suivi les travaux (mais lui il parle aux données et ça lui suffit).

 

Résultat : Il y aura un résultat. Mais que de pertes en ligne ! L’analyste est plus un artisan qui sculpte un bloc de données avec précision et imagination qu’un scientifique centré sur des formules. L’essentiel de son travail est en amont de l’algorithme, à enrichir et déployer toutes les ressources cachées derrières différentes sources de données. Avoir participé activement aux discussions métier l’aidera en amont à identifier les traitements importants, les pistes à creuser… et en aval à comprendre comment présenter un résultat qui a un sens pour le client métier : une courbe de ROC ou un AUC n‘ont de sens que pour le technicien de la donnée.

 

Le raccourcissement de la chaîne de traitement des données est essentiel à la qualité du résultat final. L’analyste ne doit pas être caché à la cave ou dans son laboratoire mais au contact de ceux qui ont besoin de son analyse. Il n’y a pas besoin de traducteur.

 

9 -  Simplifier le résultat pour mieux le comprendre.

Tous les écueils précédents ont été surmontés. Le résultat est là, accompagné d’un indicateur de performance. Le résultat est là mais la frustration aussi : on ne peut pas toucher ce résultat. Autrefois, pour monter une campagne marketing, il était possible de définir le portrait-robot de la cible après quelques analyses. L’entreprise savait à qui elle s’adressait. Il est toujours possible d’extraire un portrait-robot d’un ciblage : plutôt homme, plutôt périurbain, plutôt 35 50 ans, … La tentation est forte de réduire le ciblage obtenu à ces constatations.

 

Hélas, vouloir synthétiser le résultat d’une approche big data pour se le réapproprier dissout toute la valeur acquise. Ce n’est pas un sexe, un âge, … qui fait la cible mais des milliers de combinaisons de tous les paramètres ensembles. Vous devez accepter de lâcher prise sur le détail mais renforcer votre contrôle en amont (profils à exclure, fréquence de contact maximale…)

 

10 - Réussir en sous-traitant tout. Où est la victoire ?

Imaginez : vous avez tout réussi dans votre projet. Une question précise, des données, des itérations... et un résultat business sensible en bout de course. What else ?

Un détail. Vous avez tout externalisé : les ingrédients, la marmite, le druide.

 

Résultat : Tout marche mais le jour où vous changez de prestataire, même si vous gardez les données vous devrez (ré)apprendre à vous en servir. Et si les traitements étaient liés à un algorithme propriétaire votre compte est bon. Pourtant nous vivons dans un monde où les algorithmes qui gagnent sont gratuits et déjà codés dans des environnements libres.

 

Alternative : faire progresser les équipes internes. Les leviers sont nombreux : organiser des formations avec des MOOCs ou a minima apprendre avec le prestataire qui aide à avancer plus rapidement au début.

 

La seule vraie façon de rater son projet

La seule vraie façon de rater son projet est de ne pas essayer. Tout ce que nous avons vu comme écueils jusque présent font partie des étapes d’apprentissages normaux. Les techniques associées au "big data" concernent tout le monde, que vous ayez des big données ou non.

 

Les ressources nécessaires sont essentiellement quasi gratuites :

- Environnement de calcul (R ou python), packages de codes des algorithmes (tous ceux qui marchent). Si vous êtes allergique aux lignes de codes, les outils avec interface graphique se multiplient (avec licence cette fois)

- Ressource de calcul : Les cas d’usage nécessitant une infrastructure spécifique ne sont vraiment pas si fréquents, sinon ils peuvent faire l’objet de premières évaluations sur des bases réduites.

- Ressources pour se former, pour les candidats motivés (Moocs et livres disponibles gratuitement en ligne).

 

Ce qui coûte :

- Vouloir une marmite et un druide de compétition dès la première étape, histoire d’augmenter les chances de finir dans le gravier au premier virage.

- Payer un résultat ponctuel sans vous préparer à le reproduire par vous-même.

 

Au final comment réussir ? Si vous considérez que vos données et votre façon de les travailler font partie des actifs de votre entreprise : alors réussir le projet signifie avoir progressé en compréhension et en maîtrise. Vous pouvez superposer deux approches qui se nourrissent mutuellement :

- Un investissement de long terme sur vos équipes via la formation, potentiellement accéléré par des recrutements ou des prestations externes qui impliquent les équipes. Il y a souvent déjà beaucoup de profils intéressés de monter en compétence, prêt à y passer du temps via toutes les ressources disponibles en ligne : les détecter et les encourager !

- Des projets datas, simples, prenant source dans les questions opérationnelles quotidiennes des métiers. Des projets qui partiront donc d’un besoin très opérationnel et non de quelconques investissements data hors sol.

L’enjeu est de transformer vos managers : passer de propriétaire de leurs données à garant de leur ré exploitation par les autres services. Un vrai projet de culture d’entreprise en somme.

Just do it.

 

Denis Oblin, spécialiste du Big Data chez Memorandum et membre du comité scientifique du Data Intelligence Forum 2016.

 

Les avis d'experts et points de vue sont publiés sous la responsabilité de leurs auteurs et n’engagent en rien la rédaction.

Réagir

* Les commentaires postés sur L’Usine Digitale font l’objet d’une modération par l’équipe éditoriale.

media

Les cookies assurent le bon fonctionnement de nos sites et services. En utilisant ces derniers, vous acceptez l'utilisation des cookies.OK

En savoir plus
Suivez-nous Suivre l'Usine Digitale sur twitter Suivre l'Usine Digitale sur facebook Suivre l'Usine Digitale sur Linked In RSS Usine Digitale