Return to site

Planter son projet #data - I

Quelques points qui vous assureront un bel échec.

· data,computer science,Analytics

"Je me suis rendu compte peu à peu de ce que fut jusqu’à présent toute grande philosophie : la confession de son auteur, une sorte de mémoires involontaires et insensibles (...)".. - Nietzsche, Par-delà bien et mal.

Pourquoi accorder du crédit à mes avis péremptoires ? Parce que je suis en première ligne, et que j'ai vu des projets #data se planter ... et d'autres réussir. J'ai pu en tirer quelques règles personnelles, que je vais de ce pas essayer de partager avec vous.

ATTENTION!

  1. Ce billet contient des illustrations de Shadoks. Elles peuvent paraître idiotes et incongrues, voire moqueuses. C'est, en effet, souvent le cas. Elles ont été dessinées par Jacques Rouxel et sont beaucoup plus sérieuses qu'elles n'en ont l'air.
  2. Aucun consultant en innovation digitale ni transformation numérique n'a été blessé lors de la rédaction de ce billet.
  3. Si, malgré mes efforts, vous jugez ce texte provocant, irrévérencieux voire impertinent, il est évident que je nierai toute forme de responsabilité.

data ⊂ IT, IT ⊄ data

La raison principale de l'échec d'un projet #data, c'est de confondre IT et data. Et c'est le premier point à vérifier. Évidemment, un projet #data est un projet informatique. L'inverse est faux, l'inclusion n'est pas réciproque. Si nous étions en 2016, j'insérerais ici une blague méprisante sur les consultants parisiens (ou provinciaux) spécialistes en transformation digitale ou innovation numérique ; mais puisque nous sommes en 2017 et que je m'efforce de ne plus dire du mal des gens, je n'en ferai rien.

Au lieu de distinguer les nombreux cas qui ne rentrent pas dans le cadre d'un projet data, je vais vous proposer ma définition personnelle, donc simple: "un projet data doit passer par une phase où on ne sait pas ce que le programme va fournir comme résultats". Vous avez deux heures.

L'algorithme doit prendre le dessus, et tel un vulgaire étudiant d'Ingolstadt, il faut ne pas réellement savoir où on va. Il faut donc, à un moment, subir le réel, explorer quelques profondeurs ... et savoir remonter à la surface.

Ce qui implique qu'un projet data doit inclure une base de données trop grosse pour être visualisée de manière exhaustive et, quelque part dans le code, des lignes du genre model.fit, model.predict et model.score. Sinon, on oublie.

Tout le reste n'est que littérature ou, au mieux, statistiques type business intelligence. Ce reste inclut donc les projets qui nécessitent un peu de data crunching, de la visualisation post-Excel ou des formules mathématiques qui ont le mauvais goût de ne pas rentrer dans des requêtes SQL. L'innovation numérique ne se limite évidemment pas à un dashboard sexy et, 2017 ou pas, je sens que je vais probablement avoir du mal à arrêter de me moquer des consultants [*].

Pourquoi un tel projet échouerait ? Simple ! Il pourrait d'abord ne pas échouer en tant que projet ; mais en tant que projet #data, ce serait un échec, puisqu'il n'y a pas réellement d'innovation en terme l'intelligence algorithmique, il est à parier que les résultats obtenus seraient loin des espoirs initiaux. Il pourrait ensuite échouer en tant que projet, car à vouloir bouleverser le cadre classique d'un projet IT, sous prétexte d'innovation forcée (sinon voulue), on se retrouve à devoir inventer un cadre ad-hoc. Donc sous-optimal, impliquant quasi-forcément un non-respect des délais et des coûts.

Bref. Introduire, volontairement ou non, de la "data" ou, pire, de l'intelligence artificielle (IA) dans un projet qui n'en a pas réellement besoin, et en déduire qu'un nouveau cadre de travail est de fait indispensable, c'est risqué. Je laisse en exercice au lecteur le soin de placer dans la phrase précédente les quelques mots clés suivants: disruptif, esprit startup, datalab, data-driven.

Over-engineering

Un projet data est donc un projet IT avec une difficulté technique supplémentaire: la data science. Donc des maths compliquées, des statistiques balaises, des algorithmes décrits par des chercheurs et écrits par d'autres chercheurs (et critiqués par ... ok, vous avez compris), des problématiques parfois ardues de bases de données ou de performances, des pingouins etc.

Utiliser ces outils n'est pas une mince affaire. En toute franchise, mieux vaudrait pouvoir s'en passer :

  • la peinture autour des libraires n'est pas toujours fraîche;
  • le risque de raconter n'importe quoi "parce que l'algorithme l'a dit" est grand;
  • il faudra parler à des gens qui ont fait beaucoup trop de maths ou d'informatique pour être sains d'esprit.

Si j'étais à votre place, j'éviterais soigneusement d'introduire un algorithme d'apprentissage non-supervisé dans mes programmes. Techniquement parlant, les concepts dont je parle ne sont définitivement pas accessibles en lisant trois pages wikipédia et en installant Python après avoir suivi un MOOC de Stanford. Quiconque soutiendrait le contraire ferait bien de relire calmement les paragraphes précédents.

Vous ne feriez tout de même pas couler les fondations de votre maison par un apprenti sans encadrement... ? Utiliser des outils spécialisés requiert des techniciens compétents et formés, comme toujours. A un moment ou un autre, il faut faire intervenir un gars technique. Un data scientist, dans le cas qui nous intéresse.

La bonne nouvelle, c'est qu'il maîtrisera les outils techniques, et sera même heureux de se plonger dans votre problème de scoring avancé ou de yield. La mauvaise nouvelle, c'est qu'il ne saura pas forcément s'arrêter. Et c'est là que l'addition va grimper, car personne ne s'en rendra compte rapidement. Alors que le chef de projet n'osait pas espérer une performance de plus 60% (chiffre totalement hasardeux), le data scientist atteindra les 80% en une semaine et, tel un étalon non débourré, il s'échinera à grappiller chaque point, chaque dixième même, pendant deux mois. Déformation professionnelle, on ne peut pas lui en vouloir. Le souci, évidemment, c'est que personne n'en saura rien, puisque l'écriture des routines traduisant les résultats en indicateurs métiers ne sera pas finalisée, voire commencée ... si tant est que de tels indicateurs aient été définis. Ou eussent, je ne sais jamais.

Votre problème est résolu, mais personne ne s'en est rendu compte. Ni le data scientist, tout à sa problématique technique; ni le chef de projet, qui, avouons-le, ne sait pas trop ce qui obsède son expert es algorithmes; et encore moins le métier.

D'autres cas ?
 

Un exemple: une approche simple et itérative de la construction de la solution aurait résolu le problème en 3 jours, mais la solution n'était techniquement pas satisfaisante, ou peu intéressante: le data scientist a donc choisi une solution plus générique, plus élégante, plus innovante ... et l'a développé en 3 mois. Dommage. Et personne ne peut le savoir.

Un autre exemple: par goût personnel, ou pour utiliser le nouveau framework TensorFlow de Google, il a été décidé de développer un réseau de neurones multi-couches. Le développement prend 6 semaines, et la solution est efficace à, mettons, 87% selon les indicateurs métiers. Tout le monde est content. Manque de bol, le code demande un Ph.D en informatique théorique pour être modifié, et un résultat identique pouvait être atteint avec un simple classeur bayésien (temps de dev: 2 semaines).

Un dernier exemple, le plus classique peut-être: lancer la construction d'un château magnifique alors qu'un simple cagibi suffisait. Et consacrer les 3/4 du temps de développement à sur-généraliser les API internes (au cas où on veuille connecter une base SQL, mongodB, Redis ou Cassandra) optimiser des routines (impliquant un gain de perfs de 13% et un magnifique speed-up de 7.8 sur un octocoeur) avant de passer à l'analyse et la restitution des résultats. Résultats qui, certes, satisferont tout le monde, mais n'utilisent en définitive pas les routines sur-optimisées ni les plugins de bases de données.
 

Et je préfère ne pas parler de paramétrage sans fin de méthodes d'analyses sémantiques (ou autres), avant d'avoir épuisé les possibilités offertes par les regex les plus basiques.

Bref. Comme dans tout projet technique, laisser les experts en roue libre est dangereux.

Un data scientist n'est pas la solution à votre problème.

Vous connaissez cette phrase, certes idiote, mais qui contient une part de vérité: "Arguing with an engineer is like fighting a pig in mud. After the first few hours, you realise they enjoy it"?

Pour les data scientists, c'est pire. Encore une fois, je parle en connaissance de cause: vous ne me rendrez pas plus heureux qu'en me donnant un énorme problème incompréhensible, très technique, six mois de budget et une liberté totale pour le résoudre. Avec un bonus si la solution est élégante et s'il est nécessaire d'aller fouiner dans des articles de recherche de pointe et utiliser des outils analytiques encore en version beta. Très sincèrement [**].

Tout le monde ne travaille pas chez Google, ou en laboratoire de recherche publique assez chanceux pour ne pas courir après les financements, donc ce cas n'arrivera sûrement pas. Les autres projets, classiques, ne peuvent probablement pas se permettre de faire ce genre de R&D. Or, un data scientist est, par formation et par définition, un scientifique. Sinon, vous vous êtes trompés, dommage. Donc quelqu'un aime les problèmes compliqués, cf plus haut et cette histoire de boue. Puisque ces gens sont des laborieux et des passionnés, ils auront tendance à rechercher les problèmes, à s'y plonger, à vouloir complètement le résoudre. Vous voyez où je veux en venir: il faut savoir comment les arrêter sans trop les frustrer et, obtenir d'eux des solutions perfectibles, temporaires, et fonctionnelles.

Ce qui peut être fait en deux semaines doit être fait en deux semaines.

Pas en trois mois. Et beaucoup peut-être fait en deux semaines.

Un data scientist est un développeur par la force des choses, puisque son langage est l'informatique [***]. Il y a un gouffre entre l'aridité d'un article scientifique et le style d'un Flaubert.

Si brillant soit-il, un data scientist n'est probablement pas le meilleur en architecture logicielle. Ni en gestion de projet. Encore moins en communication interne ou externe. Et je préfère ne pas parler de relations clients.

Il y aurait bien d'autres règles, évidemment ...

Et donc?

Ne pas céder à la nouvelle mode de caser la #data ou, pire, l'intelligence artificielle, dans tous les projets qui n'ont d'innovants que le fait d'avoir été imaginés quelque part lors des six derniers mois. Les outils typiques d'un projet #data comme l'apprentissage automatique (machine learning en français) sont coûteux à mettre en œuvre, et doivent être réservés à des cas d'utilisations où ils apportent quelque chose.

Au fait, vous connaissiez le fizz-buzz en TensorFlow ? Vous voyez bien qu'il y a pire que moi ...

Bref. Un projet sera peut-être plus fun s'il est labellisé #data - surtout si c'est la seule façon d'obtenir un budget ... - mais de grâce, n'en faites pas une religion. Ce n'est pas forcément pertinent et ça vous coûtera plus cher.

Notes

[*] Sûrement la conséquence malheureuse d'une honteuse déformation professionnelle liée à des tendances schizophrènes.
[**] D'ailleurs, si vous avez un projet de ce type, je serai même prêt à vous faire un prix.
[***] Non, son vrai langage est la logique et l'analyse, qu'il transcrit en code informatique.

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly