Agilité et datascience : ce n’est pas si simple !

Agilité et datascience : ce n’est pas si simple !

L’accroissement du nombre de projets de Big Data / Datascience(*) aiguise les appétits de nombreuses sociétés de conseil. Côté clients, nombreux sont les grands groupes qui lancent des  expérimentations tous azimuts.  Nous sommes donc dans une situation où chacune des parties ne maîtrise pas toutes les composantes de son sujet et dont le périmètre évolue en cours de projet.  Périmètre évolutif et ajustements fréquents ont donc conduit naturellement les sociétés à mettre en avant les méthodes agiles comme solution miracle pour piloter les projets de Big Data.

Malheureusement, les choses ne sont pas si simples et nos expériences nous montrent que la réalité est plus nuancée. L’agile est trop souvent utilisé comme prétexte pour excuser des défauts d’avancement et sert parfois d’excuse pour cacher un manque de savoir-faire.

QUELLES SONT LES CARACTÉRISTIQUES PARTICULIÈRES D’UN PROJET DE DATASCIENCE ?

  • Non le big data ne trouvera pas tout seul la réponse à une question mal formulée

  • Non il ne suffit pas de d’alimenter un modèle de machine learning avec des données brutes pour créer un modèle performant.

  • Oui, il faut du temps pour comprendre la nature des données avant de les intégrer dans un modèle.

Une fois les ambiguïtés levées se trouve un second obstacle : L’obstacle de la faisabilité raisonnable. Même si les objectifs sont clairement connus, même si l’équipe est la meilleure possible, il n’est pas certain que l’information recherchée se cache entièrement dans les données. Parfois, il est préférable d’interrompre un projet et de pivoter plutôt que s’acharner à faire parler des données incomplètes. Ou alors choisir un sujet plus court et plus simple qui sera résolu avec des efforts beaucoup plus limités. La faisabilité raisonnable indique cette capacité à arrêter les frais et à se relancer.

POURQUOI LES PRINCIPES AGILES NE SUFFISENT PAS TELS QUELS ?

 La question de la faisabilité ne peut être elle non plus abordée avec les instruments habituels de l’agile. Les projets agiles sont issus du monde du web et des applications mobiles. Ces projets bénéficient aujourd’hui d’un retour d’expérience de plus de 20 ans, de technologies certes en évolution constante mais dont la nature incrémentale facilite la progression de la connaissance acquise et la transférabilité des retours d’expérience. En réalité, aucun projet web ne se pose sérieusement la question de la faisabilité. Cette question a été tranchée depuis longtemps. Or, un projet de datascience peut parfaitement échouer parce l’information que l’on croyait cachée quelque part dans les données ne s’y trouve pas. Aucun mécanisme agile ne peut pallier à ce risque.

QUELLES SONT LES SOLUTIONS PROPOSÉES PAR QUANTMETRY ?

Avec un nombre significatif de projets derrière nous, nous n’avons certes pas trouvé la méthode infaillible pour résoudre tous les problèmes mais nous nous sommes forgés un certain nombre de convictions

En premier lieu, un projet de big data est un type particulier de projet d’innovation ce qui signifie qu’une bonne partie des enseignements des projets d’innovation peuvent être repris et appliqués sans trop de difficulté. Toute initiative suit un funnel (mot intelligent pour désigner un entonnoir) d’innovation dont on peut distinguer cinq phases comme indiqué ci-dessous :

A chaque étape du tunnel des projets s’interrompent et il ne faut pas redouter de stopper des initiatives. En phase de découverte comme nous le sommes actuellement avec le big data, il est préférable de consacrer ses ressources à explorer plusieurs pistes plutôt que miser coûte que coûte sur un seul projet (sous-entendu, si vous vous entendez parler d’un seul POC dont l’objectif serait d’aller en production, méfiez-vous). Choisissez plutôt de miser sur plusieurs opportunités en parallèle quitte à allouer des ressources limitées à chacun plutôt qu’une grosse enveloppe pour un seul projet. Le taux d’arrêt des projets dépend du contexte, de l’acceptation de l’essai erreur dans l’entreprise et des ressources que vous avez à y consacrer. Des sociétés très innovantes comme Google peuvent se permettre de stopper 99 projets sur 100. De manière plus raisonnable transformer 10 opportunités en 5 poc puis en trois pilotes semble un bon niveau de pente.

QUELLES DISTINCTIONS FAIT-ON ENTRE CHAQUE PHASE ?

Opportunité :

Une opportunité est un projet dont on cherche à définir le mandat (idée, sponsor, budget, cas d’usage, valorisation des apports, technologie) et une équipe capable de le porter.

POC

Un POC (Proof of concept) est une opportunité dont on souhaite explorer certaines hypothèses (valorisation d’un business case, choix de technologie, identification des features, approche de machine learning) en prototypant et développant un produit informatique jetable. A l’issue du POC,  le développement est certes jeté mais les décideurs sont éclairés sur les possibilités du projet, son coût et les bénéfices que l’on peut en espérer ainsi que la faisabilité.

Un pilote

Un pilote est un projet de datascience dont on veut valider le fonctionnement dans des conditions réelles d’utilisation avec un périmètre limité en matière de déploiement (sous-ensemble d’utilisateurs, produit ou zone géographique limitée) et une mise en production sur une infrastructure pérenne.

Un projet industriel

Le projet industriel consiste à déployer une application informatique contenant les modèles de datascience du pilote à l’échelle de l’entreprise avec un niveau de fiabilité et de qualité à même de satisfaire les contraintes opérationnelles de l’organisation.

Un projet en amélioration continue

Peu de projets de datascience sont arrivés à ce stade à ce jour, mais cette phase est particulièrement importante et sensible. Il ne s’agit pas tant de corriger des bugs et prendre en compte des demandes que de faire en sorte que le modèle continue à apprendre et progresser, contrôler sa dérive (prédit il toujours aussi bien) et ajuster si nécessaire. En particulier, des modèles prédictifs ayant vocation à faire disparaitre des évènements (ex : Anticiper des pannes en avance) auront tendance à diverger dans le temps car l’évènement qu’ils sont censés prévenir n’apparaissant plus, leur base d’apprentissage devient petit à petit obsolète. Un modèle de machine learning doit prendre en compte les dérives temporelles et s’adapter en continu. Mettre en pratique ces principes s’avère particulièrement délicat et réservé aux plus experts (*).

COMMENT PASSER D’UNE PHASE À L’AUTRE ?

La suite dans un prochain article

 (*)Nous reviendrons plus tard sur l’application des principes devops au big data.