Gestion de projet Big Data, réflexions et expérimentations

Cet article est une transcription d’une conférence donnée dans le cadre des séminaires PMI Morocco Chapter à Casablanca.

Spécialiste du Big Data ?

Je suis un “spécialiste du Big Data”. Cette expression veut tout et rien dire car le Big Data est une notion floue dont les contours s’étendent facilement de l’administration système de centaines de machines à la présentation de stratégies innovantes à un board de directeurs. Je me considère spécialisé en Big Data car mon travail consiste de manière fondamentale à gérer un cycle de vie complet de la data.

Ce cycle de vie passe par plusieurs phases :

Récolter la donnée des systèmes opérants

Ces systèmes opérants peuvent être de plusieurs formes allant de la base de données transactionnelle critique car liée à un système de production au fichier excel produit à la va-vite par un consultant, en passant par des commentaires Facebook, de la vidéo de caméra surveillance, ou encore du son de la voix d’un téléconseiller en communication avec un client. Récolter la donnée est une brique sensible car il s’agit d’établir un lien le plus propre possible entre deux mondes différents dont les objectifs sont disjoints :

1. Le monde de la production informatique dont la principale préoccupation est la bonne marche et sécurité des services
2. Le monde de la data ingénierie qui ne pense qu’à avoir une donnée la plus fraîche, propre, et brute possible.

Cette jonction est un point de douleur dans beaucoup d’organisations et nécessite un niveau de communication mutuel fort et très souvent un sponsoring élevé pour les projets concernés.

Nettoyer et clarifier la donnée

Là encore, les data ingénieurs doivent jouer les passeurs entre deux mondes car la donnée est par définition agnostique. Suite de bits, elle ne veut rien dire sans l’interprétation volontaire des responsable fonctionnels des différentes sources de données. Sur les bases de données historiques, la succession de projets, évolutions et maintenances trace sur la donnée des rides fonctionnelles et la couvre de verrues techniques et métiers. Nettoyer la donnée, c’est précisément ôter ces verrues et lisser les rides de manière à normaliser la compréhension de la donnée le plus possible pour un traitement fluide et sans accrocs. C’est probablement l’étape la plus ingrate et qu’on soupçonne le moins du cycle de vie de la donnée. C’est aussi l’étape la plus consommatrice de temps.

Valoriser la donnée

Une donnée lisse et propre est un terrain de jeu idéal pour le datascientist. A partir de ce moment, on ne considère plus la donnée comme un sous-produit d’une activité informatique mais comme un actif stratégique qu’il convient de raffiner. Un peu comme un pierre précieuse débarrassée de ses impuretés et qui ne demande qu’à être taillée pour la bonne cliente. Le datascientist doit alors commencer à questionner le métier sur les douleurs et le besoin pour trouver la bonne façon de travailler la donnée de manière à donner pleine satisfaction. Cette valorisation (dite datascience) peut prendre de nombreuses formes mais ce ne sera pas l’objet de notre propos aujourd’hui.

Prototyper des solutions technologiques nouvelles basées sur la data

Parfois, la donnée nettoyée est simplement valorisée en lui donnant plus de visibilité, sans avoir besoin de sortir une batterie d’outils statistiques. Utiliser les dernières technologies d’exploration et de visualisation de donnée afin de rapprocher le monde du métier et le monde de la donnée est un vrai challenge qui nécessite des outils intuitifs et riches. Dans un autre domaine, la blockchain est aujourd’hui un outil intéressant pour lequel le concept de transaction sécurisée, authentifiée et irrévocable a beaucoup de valeur. Même si c’est peu lié au Big Data, nous restons sur un niveau d’innovation technologique fort autour de la data.

Le travail quotidien du Datalab

Je suis aujourd’hui le directeur du Datalab, une entité chargée de coordonner l’ensemble de ces projets/prototypes dans un esprit le plus agile possible. Créer de l’innovation passe souvent par une vision décalée, contestataire et libérée des contraintes organisationnelles. Mon rôle est donc de m’assurer que mon équipe s’exprime dans le cadre de ses missions officielles et officieuses. Cette équipe est constituée de jeunes ingénieurs avec des appétences plus ou moins fortes pour l’informatique, les statistiques et la banque.

Nous alternons entre des projets classiques au sens qu’il y a un besoin exprimé qui doit être traité selon un planning et des projets plus innovants que nous appelons prototypes agiles. La difficulté étant ici de contribuer positivement au développement data de la banque dans le court terme sans négliger des aspects plus exploratoires et recherches qui ne payent qu’à un terme plus long. Les arbitrages sont décidés de manière consensuels et je garde le dernier mot quant aux décisions qui n’atteignent pas un consensus.

En ce sens là, nous mêlons recherche et production (d’où lab de Datalab) avec plaisir mais aussi dans une forme de brouillard quant à la visibilité et à l’impact de notre travail. Il arrive que nous abandonnions des idées intéressantes car difficile à implémenter dans notre contexte bancaire ou parce que trop éloignées des considérations actuelles ce qui peut se révéler frustrant pour l’équipe. Mais c’est un risque à prendre car nous gagnons la liberté d’aller sur des sujets à la pointe de l’analyse de donnée.

Qu’est ce que fondamentalement Big Data ?

La définition originelle

C’est une question difficile car la notion de Big Data est apparu progressivement dans les milieux technologiques dans les années 2000 lorsque nous nous sommes aperçus que les volumes de données augmentaient de manière exponentielle. Le Big Data a d’abord a été associé comme le sens littéral des mots l’indique à une quantité importante de donnée générée par l’Homme, introduisant ainsi des opportunités et des challenges nouveaux. Petit à petit, les solutions technologiques permettant de travailler cette donnée massive de manière efficiente ont fait leur apparition et en premier lieu un framework de traitement appelé Hadoop né de la problématique de l’indexation du web. Traiter de la donnée massive n’a jamais été un problème de capacité mais de ROI. Le Big Data a donc naturellement été associé à une forme d’efficience dans le traitement de donnée à travers des architectures physiques clusterisés dites horizontales. A partir de là, le Big Data a pris une connotation technologique forte car associé à des solutions techniques généralement open source. Quand on parle de Big Data, on parle donc de ces énormes clusters Californiens et Chinois constitués de dizaines de milliers de machines dans lesquelles sont installées des application de traitement efficient de la donnée. C’est personnellement comme ça que j’ai compris le Big Data lorsque je suis entré dans le domaine en fin 2012 : la démocratisation technique prochaine de l’analyse de donnée massive.

La définition des médias

Puis il y a eu cet effet média prometteur et populiste à la fois. On a associé le Big Data à des thématiques métiers dont il était originellement plutôt lointain. Le Big Data, c’est devenu la surveillance des masses, la fin de la vie privée sur internet (facebook, google), la consommation énergétique excessive de ces clusters de machines partout dans le monde (une étude controversée avait estimé qu’une recherche google générait 7 grammes de CO2 soit à peu près l’équivalent de rouler 40 mètres en voiture). Le Big Data est aujourd’hui le symbole de la prise de pouvoir de la digitalisation sur nos vies et notre écologie.

Ma définition

Pour ma part, la définition profonde du Big Data est celle d’un optimiste sur la contribution forte qu’apportera la technologie à la société. J’aime définir le Big Data par l’idée audacieuse qu’il faut générer de la donnée dans toutes nos activités et ensuite traiter cette donnée comme une first class citizen. L’utiliser de manière honnête et juste à bon escient afin de monitorer positivement ce que nous essayons de réaliser dans un esprit perpétuel de self improvement. Lorsque je pense à un process bancaire, j’essaye tout autant de penser user first (UX User eXperience) que data first (data-driven) car je veux me donner les moyens technologiques de piloter et améliorer mon process efficacement et rapidement.

Le Big Data est donc pour moi autant une boîte à outils qu’un état d’esprit constructif animé d’une passion pour la data bien utilisée

Datascience et Deep Learning

D’autres notions importantes sont périphériques au Big Data comme la Datascience ou le Deep Learning. Sans rentrer dans les détails, il est essentiel de comprendre que l’innovation technologique liée au Big Data a été accompagnée par des développements algorithmiques et statistiques qui ont poussé au maximum l’extraction d’information de donnée brute. La datascience est également un mot nouveau dont je n’entendais pas parler au début de ma carrière (on parlait beaucoup à l’époque en France d’apprentissage statistique et plus généralement d’analyse de donnée statistique). L’informaticien et le statisticien étaient deux entités séparées par un épais mur d’incompréhension qui a été cassé par la nécessité impérieuse de combiner les forces des deux domaines. On entend aujourd’hui par datascience l’ensemble techniques informatiques et statistiques qui permettent de traiter de la donnée afin de résoudre un problème métier. Si le Big Data est un mindset outillé, la datascience est un ensemble de procédures de valorisation de la donnée. Et ses acteurs, dits data scientists, sont une des compétences les plus recherchées sur le marché du travail aujourd’hui car le profil est par définition passe-partout multi-disciplinaire (le fameux mouton à 5 pattes). Avant d’être manager ou développeur Big Data, mon coeur de compétence universitaire a été précisément l’algorithmie de la datascience (le Machine Learning). J’ai consciemment choisi d’élargir mon champs de compétence et de m’éloigner progressivement de la valorisation statistique pour m’approcher des problématiques techniques souvent bloquantes dans nos organisations.

Je fais un aparté sur le Deep Learning car les médias évoquent fréquemment la notion d’intelligence artificielle de manière un peu exagérée. Le Deep Learning est une branche du Machine Learning qui se consacre à l’extraction d’information de données non ou peu structurées. Extraire de l’information d’une image ou de son (comme reconnaître un visage ou transcrire la parole) est une tâche très humaine qu’on peut donc approximer par intelligence, bien que cette dernière notion soit infiniment plus complexe. Ces algorithmes de Deep Learning sont capables d’apprendre au fur et à mesure de l’expérience qu’ils reçoivent. Par conséquent, on peut rapprocher cette augmentation de la capacité de modélisation avec l’apprentissage d’un enfant qui découvre le monde. Les modélisations et représentations d’un enfant sont par contre extraordinairement complexes, sémantiquement riches et incroyablement robustes au changement. Les algorithmes de Deep Learning que nous possédons aujourd’hui sont plutôt mono-tâche et forment donc des modélisations très spécialisées, bien que parfois impressionnantes

Innovation Data

L’innovation Data, ce n’est pas seulement le Big Data ou la datascience, mais tous ces sujets prometteurs où la donnée plus ou moins massive, structurée ou pas joue un rôle important dans la disruption des services que nous possédons aujourd’hui. L’exemple le plus connu aujourd’hui est la blockchain qui est nouvelle manière d’atteindre un consensus robuste entre participants. Au Datalab, nous ne travaillons pas sur les cryptocurrencies mais sur l’architecture technique qui porte ces cryptocurrencies, à savoir les implémentations de blockchain. Nous tentons d’appliquer cette idée de robustesse et de consensus dans un contexte où les banques, les administrations et plus généralement les acteurs des secteurs privés et publics doivent de plus en plus échanger de l’information de manière rapide, fluide tout en garantissant un niveau de cohérence transactionnelle fort. La blockchain permet ce genre de uses cases pour peu qu’on choisisse les bonnes implémentations.

Self Business Intelligence

Le sujet de la self BI (Business Intelligence) est également une problématique fondamentale dans la transformation d’une entreprise vers le data-driven. Rapprocher la donnée des métiers est difficile car cela suppose de disposer des bons outils intuitifs et des bonnes couches sémantique de compréhension de la donnée pour faire le lien entre deux mondes qui ne se parlent pas souvent. En pratique, il s’agit de construire une modélisation naturelle et compréhensible d’objets métiers (tel le client d’une banque) à travers la donnée qu’ils génèrent (a utilisé sa carte bancaire, a réalisé un virement etc…), ses caractéristiques (son âge, sa ville de résidence etc…) et des indicateurs plus avancés (indice de satisfaction, score d’octroi de crédit à la consommation etc…). Et de permettre l’exploration de cette modélisation dans une interface qui permet at first glance de saisir des réalités analytiques complexes

Ah tiens ! Les clients équipés en crédit et qui ont plus de 45 ans utilisent plus leur carte bancaire que les clients de moins de 30 ans

Que s’est-il passé ? L’indice de satisfaction de nos clients a été en baisse ces dernières années pour les habitants du nord du pays etc.

L’idéal que nous cherchons à atteindre, c’est donner une réponse à des problématiques métiers en faisant intervenir le moins possible un technicien. C’est-à-dire autonomiser les analystes métiers.

Pourquoi je suis avec vous aujourd’hui ?

La planification

Ayant une modeste expérience des projets informatiques classiques, il sera difficile pour moi de vous apprendre quelque chose sur la gestion de projet canoniques. Gardons en tête que la première étape de la gestion de projet est la planification de celui-ci. Cela passe par décrire la problématique, les douleurs ou les points à améliorer. A les expliciter, les illustrer et comprendre profondément ce qui gêne dans l’état actuel. Cette étape de recueil des douleurs est fondamentale car elle va dessiner la vision à esquisser. Cette vision permet à l’ensemble des participants au projet de garder un cap clair et global sur la direction à prendre. Cette vision peut tenir en quelques phrases sans rentrer dans des détails de spécification. Une fois que les douleurs et la visions sont établies, la planification continue d’abord en segmentant le projet en macro stories, unité fonctionnelles le plus indépendantes possible qui permettent d’avoir une vision plus précise sur le “ce qu’il y a à faire”. Ces macro stories sont une première projection sur l’implémentation concrète du projet. Puis il faut lister les ressources nécessaires (humaines ou matérielles) à la réalisation du projet afin de dessiner le planning macro et estimer la durée et le coût du projet. Lorsque la vision globale est établie, la planification décrira l’ensemble des tâches à réaliser pour chaque macro-story, et tachera d’ordonnancer ces tâches typiquement dans un diagramme de Gantt.

L’idée dans la planification, et plus généralement dans les projets qui se lancent dans un modèle en cascade, c’est de limiter l’incertitude le plus possible et d’ouvrir la voie à une anticipation des problèmes qui risquent de survenir.

Les projets IT classiques consomment de la douleur et implémentent des solutions à ces douleurs.

L’implémentation

Quant à la phase d’implémentation, elle doit être maîtrisée et suivre un cheminement contrôlé. Les différentes macro stories ont été découpées en user stories (cas d’usages métier) ayant chacune leur cahier de recette et leurs interdépendances. A chaque user story est affectée une équipe dont le rôle et les critères de réussites sont clairs et bien définis. Dès que la phase d’implémentation commence à toucher à sa fin, les premiers tests techniques, fonctionnels et de performance globaux doivent se mettre en place afin de procéder aux derniers ajustements avant livraison et déploiement.

Limites du cadre classique

La première limite à laquelle se heurte un projet Big Data est dans la définition même de la mission. Alors que pour un projet classique, les product owners sont généralement des personnes du métier pour qui le besoin et le moyen de recetter le résultat sont clairement identifiés, dans le cas d’un projet où la donnée est en jeu, il faut une expertise data forte afin d’apprécier les objectifs et le travail. Cette problématique de définition des tâches et de mesure de la qualité du travail se retrouve aujourd’hui beaucoup dans les organisations data-immatures. Et la plupart du temps, ce sont des techniciens de la data, des datascientists, qui prennent le relai du métier afin d’aider à spécifier le besoin émis. Ils sont aussi les seuls à même de pouvoir juger du travail accompli. Ce mélange des rôles est nauséabond car il ne permet pas un découplage propre de la maîtrise d’ouvrage et de la maîtrise d’oeuvre.

Une deuxième problématique tient dans la matière travaillée, qui n’est pas une idée mais de la donnée. Et la donnée est un input changeant, capricieux et dont le contrôle n’est jamais assuré. Bâtir un projet sur de la donnée, c’est le construire sur une forme de sable mouvant : il faudra s’adapter constamment à ses fluctuations et ses surprises. C’est la raison pour laquelle nous préférons généralement travailler en itérations agiles et souples plutôt qu’en tâches prédéfinies et sizées comme le voudrait une planification classique. Cette agilité veut dire accepter de redimensionner l’effort de travail pendant l’implémentation de la solution en ajustant continuellement la vision de départ avec les possibilités techniques (on découvre souvent qu’il n’est pas possible de tout faire) qui se présentent à nous au fur et à mesure d’un projet data. Ce risque de variation dans l’exécution du projet data tient principalement au fait que la data est variable et jamais complètement maîtrisée. De nombreuses surprises peuvent survenir qui font que la tâche peut devenir soudainement plus ardue ou beaucoup plus simple.

Enfin un troisième point essentiel concerne la finitude du projet. Bien qu’un projet classique puisse toujours être amélioré, la notion de projet terminé quand on manipule de la donnée est encore plus flou et difficile à définir. Pourquoi cela ? Tout d’abord car pour estimer qu’un projet est fini, il faut être capable de bien comprendre ce qui a été fait et ce qui resterait à faire dans une prochaine version. Et cela, comme nous l’avons dit plus haut, demande une bonne connaissance des métiers de la datascience. Ensuite, la donnée étant changeante, il peut arriver que le projet doive être remis au goût du jour pour s’adapter à un nouveau contexte. Un projet lancé sur une donnée obtenue il y a 6 mois n’est pas exactement le même projet sur la donnée d’aujourd’hui. Ce ne sont peut être pas les mêmes phénomènes mis en jeu lorsqu’on se décale de 6 mois puisque le contexte change. Enfin car les projets data ont souvent des embranchements nombreux avec d’autres directions ce qui crée beaucoup de dépendances à d’autres projets (comme des évolutions de CRM, ou la nécessité de lancer des campagnes de communication ciblées). Cette interdépendance forte rend le projet facilement soumis à des aléas indépendants de sa volonté, ce qui peut nécessiter des ajustements de fin de projet. Un projet data n’est réellement terminé que lorsque l’implémentation métier de toute la chaîne de valeur est complète, ce qui peut parfois nécessiter d’attendre le feedback du marché pour ajuster et corriger. Et considérer le projet terminé et éventuellement réussi.

La compatibilité entre les projets classiques et les projets Big Data n’est pas totalement évidente même si les similarités existent. Gardons en tête que les projets autour de la data nécessitent plus d’ajustement et de souplesse, et que par conséquent il ne faut pas les juger avec la même rigueur organisationnelle mais garder en tête l’application de la valorisation de la data comme vision pour le projet.

Alors quelles leçons faut-il retenir ?

Gérer un projet en s’aidant d’un cadre théorique est important car il permet de construire une représentation concrète du projet dans tous ses aspects y compris les plus aléatoires. Ces aspects aléatoires sont présents dans tous les projets, ne serait-ce que sur les délais de réalisations des équipes techniques. Dans un projet data, il faut partir du principe que les aspects aléatoires seront plus présents que dans un projet classique du fait de l’objet même du projet la data.

L’Humain est au coeur

Un datascientist ne travaille pas la donnée de la même manière qu’un développeur informatique conçoit une application. La data nécessite beaucoup plus de créativité et de capacité de remise en question ce qui donne parfois une touche artistique à cette forme spéciale d’ingénierie. La différence entre un très bon developpeur et un développeur moyen est très importante, Steve Jobs le rappelait dans une vidéo où il annonçait un rapport 25:1 global entre les deux profils. Ce ratio est exacerbé dans un contexte datascience car une mauvaise décision peut se répercuter violemment en aval du travail de modélisation et peut rester insoupçonnée pendant longtemps. Il faut donc valoriser avec vigueur et patience les talents. Leur donner de la responsabilité et récompenser la créativité et la prise de risque. Et féliciter les actes de vigilance car ils peuvent sauver un projet en danger à cause d’une caractéristique de la donnée mal comprise ou mal interprétée. Cet aspect humain rentre pour moi totalement dans le cadre de la gestion du projet Big Data et est sans aucun doute une clé du succès de nombreux projets.

Le culte de l’erreur

L’erreur est humaine, et dans le cas de la donnée, fréquente et souvent imprévisible pour ne pas dire inévitable. Pour travailler efficacement dans ce contexte, il faut être conscient que chacun de nous fera des erreurs et qu’il est plus important de savoir y faire face rapidement puis d’en apprendre des leçons que de chercher à priori à tout prix de les éviter. Dédiaboliser l’erreur est essentiel pour créer un climat sain de travail dans lequel chacun saura s’épanouir sans une épée de Damoclès sous sa tête. Et ainsi exprimer son potentiel. Netflix est par exemple bien connu pour encourager fortement les développeur à tester et “faire planter”, allant même parfois à récompenser les plus grosses erreurs en production. Cultiver l’erreur ne veut pas dire la rechercher mais ritualiser le monitoring et la recherche de feedback des collaborateurs. L’erreur ne s’anticipe pas mais s’apprivoise et devient un facteur essentiel de test de robustesse et de résilience de nos systèmes.

Communiquer avec les stakeholders

On ne comprend jamais assez le besoin. Le développeur qui sommeille en moi est toujours tenté de foncer sur la donnée, de sortir des prototypes rapidement pour enclencher le cycle d’itérations continues. Mais le consultant cherchera toujours à communiquer précisément et de manière permanente avec les stakeholders afin de bien comprendre le besoin au départ. Un projet Big Data est comme nous l’avons dit toujours fortement imbriqué avec d’autres directions. Il faut donc un ajustement permanent de ce qui est en train d’être produit avec la mécanique globale dans laquelle le projet s’imbriquera. Rester à l’écoute, demander du feedback et parfois même provoquer pour tester des idées sont plusieurs manières d’aller chercher une information cruciale pour la vision du projet Big Data.

La plupart du temps, le métier ne saura pas vous dire si c’est bon ou pas, ou si votre projet Big Data va dans la bonne direction étant donné la technicité statistique nécessaire pour juger ce type de projet. Par contre, ce sera à vous de faire le pont et de vous assurer que tout le monde sera satisfait in fine.

Le côté aléatoire des projets

Il est difficile de dire à un stakeholder qu’il est quasi impossible de prédire le temps de construction d’un score prédictif par exemple. Et pourtant, il arrive souvent que ce score sort étonnamment rapidement, ou à l’inverse après de longues semaines d’aller-retours avec les administrateurs de base de données et responsables métiers des DSI.

Ne rien promettre est grave, mais promettre l’imprévisible est pire

Le projet Big Data est comme tout projet soumis à des aléas qu’il va falloir essayer de cerner pour permettre un atterrissage réaliste. Mais il faut aussi savoir expliquer la complexité de travailler la donnée et gérer la frustration qui peut en découler. L’enchevêtrement du Big Data dans le grand cycle de vie de valorisation de la donnée rend difficile cet atterrissage, mais certaines anticipations techniques en amont du projet peuvent aider à cadrer la phase de planning.

Photo credits :

• Nicolas Thomas on Unsplash
• kyler trautner on Unsplash
• Denys Nevozhai on Unsplash