Mes erreurs de stagiaire data scientist
Il y a maintenant 5 ans, je commençais mes études d’ingénieur, plein de doutes, de craintes, sans savoir ce qui ressortirait de cette machine à façonner des cerveaux. Pendant 4 ans et demi d’élevage industriel, j’ai finalement produit un foie gras de connaissances qui m’a permis d’apposer le tampon “Data Scientist Intern” (notez les majuscules) sur mon CV. Le Saint-Graal pour les étudiants comme moi qui ont façonné un imaginaire du monde des données.
Après avoir englouti des manuels de PascalCC++SQLHTMLPHPCSSPostgreSQLJavascriptReactNodeGitMongoDBPythonRAWSRESTBERTCNN et autres gros mots de l’informatique, j’ai pu découvrir la vraie utilisation de ces outils dans un cadre professionnel.
Je me suis donc retrouvé Stagiaire Data Scientist dans une marketplace du tourisme local et sur mesure, leader sur son marché.
Durant les études, on “mène sa barque”, on est le capitaine de son stand-up paddle. Faire un stage dans une PME de 220 employés revient à se faire téléporter au rang de mousse… d’un paquebot. Et évidemment, on commet des erreurs. Erreurs que je présente ici !
Vouloir changer le monde
Du haut d’un stand-up paddle, changer de direction, accélérer, faire une pause ou changer la rame de côté se fait en un brin de temps. Dans un paquebot, les choses sont plus compliquées.
En arrivant dans ma PME du tourisme, je me voyais déjà automatiser les processus de réservation, créer des algorithmes de suggestions de voyages personnalisés, créer des réponses automatiques pour des messages spécifiques, ajouter du deep learning ici, là et un peu partout.
Mais en vérité, dans une PME, comme dans un paquebot, il faut respecter les process : le mousse (moi) voudrait accélérer ? D’accord, mais pour quoi faire ? Quel est l’intérêt business si ce n’est un délire du nouveau mousse ? Demandons l’avis du contremaître, du chef de service, du responsable technique, du superviseur en chef, du lead of speed, du head of speed, du fioul supervisor, du consultant en chef, du consultant moteurs… S’ils valident la demande du mousse, nous en parlerons aux quatre co-capitaines qui émettront l’idée au capitaine, qui pourra valider la demande et l’ordre sera transmis en sens inverse à toutes les équipes. A raison d’une réunion d’équipe par semaine, le paquebot devrait accélérer de quelques noeuds l’année prochaine.
Cette métaphore, peut-être exagérée, représente les difficultés de prises d’initiatives lorsque l’on rejoint une grande entreprise. Les process, les réunions, les pressions et responsabilités retirent l’envie d’avoir des envies. La prise d’initiative est possible au sein de l’équipe ! Mais pour qu’elle ait un impact sur l’entreprise : sortons les rames ! Car la réalité est plus complexe et les enjeux plus importants que ce que l’on imagine avant d’avoir mis les pieds dans le paquebot.
Aux futurs Data Scientist Intern de PME ou multinationales, je recommanderais de rester humble et de ne pas se faire de films. Notre impact en tant que stagiaire est “miniable” (minime+minable).
Vouloir foncer sur les algorithmes
Premier jour : “J’espère que mes compétences Python seront suffisantes pour manipuler les données et sortir une belle prédiction avant ce soir !”
A la fin du premier mois, je n’avais toujours pas lancé un algorithme ML.
Parce qu’avant d’utiliser les données d’une entreprise, il faut connaître l’entreprise ET ses données… Une entreprise qui donne de la valeur à ses recrues prend le temps de présenter les collègues, l’organisation, les process, les valeurs de l’entreprise. Elle prend le temps pour répondre aux questions. Une fois ces éléments clairs, le jeune data scientist doit se familiariser avec les données, comprendre leurs sources, connaître leurs structures, comprendre les enjeux et raisons de leur présence. Tout cela ajouté à la formation aux outils et aux procédures de sécurité. Bref, une sacrée dose d’informations à encaisser avant de toucher le moindre algorithme.
Cette fougue, cette impatience de la jeunesse est le pain quotidien des tuteurs de stage : les algos viendront, mais plus tard.
Espérer des résultats exceptionnels, tout de suite
Tout étudiant en data science a rêvé d’iris, de Sepal.length, Petal.width ou de papillons au cours de ses études. Les cas étudiés en cours nous offrent d’ailleurs des résultats de la sorte :
Mais lors de mon premier projet en conditions réelles, mon nuage de points ressemblait à cela :
C’est une réalité à laquelle nous ne sommes pas confrontés en cours. Les données d’entreprises ne sont pas pré-mâchées pour que l’on obtienne de belles droites. Pire ! Les données ne sont même pas pré-selectionnées ! En entreprise, il n’y a pas 4 colonnes avec pour consigne : “Identifiez les deux classes de fleurs à partir de ces données”. En entreprise, il y a 100 colonnes et une consigne : “Répondez aux besoins marketing avec ces données”. Et évidemment, l’information nécessaire n’est pas contenue dans ces colonnes. Le Feature Engineering est alors une étape essentielle qui n’est pas enseignée en classe. (Les professeurs ne sont pas à blâmer. Avec peu d’heures de cours et peu de ressources, il faut sélectionner.)
Ces deux camemberts résument parfaitement ce que l’on voit en cours vs la réalité :
Le problème d’un data scientist ce n’est pas l’algorithme, c’est la donnée.
Produire, produire, produire
Avec mon passif de développeur full-stack, j’étais obsédé par la rapidité. “Donne-moi des tickets Trello, je vais les enchaîner”. Mais en data science, le ticket Trello ressemble à “Identifier des classes de consommateurs”.
Avec un tel ticket, je me jetais sur les données, clic, nettoyage, hop, sélection des algos, une boucle for avec 4–5 algos ; en 1 heure le tour était joué, 90% d’accuracy : “Il est où mon prochain ticket ?”.
Mais la logique d’efficacité, de production et de rapidité du développeur full-stack ne s’applique pas aux data scientists. Challenger le problème, comprendre, intégrer, saisir, interpréter, concevoir, piger son intérêt et les objectifs business latents sont essentiels. De plus, pour chaque projet, une veille technologique est nécessaire afin de connaître les dernières actualités du milieu. En tant que débutant, il est en plus nécessaire d’apprendre sur les meilleures pratiques et de remettre en question l’efficacité de son code.
Si je devais recommencer mon stage, je demanderais à mon maître de stage le temps que je dois allouer à chacune de ces tâches : Comprendre le problème, Veille technologique et recherche d’algorithmes adaptés, Regroupement et nettoyage des données, Feature engineering, Paramétrage des algorithmes. Demander le temps alloué permet de ne pas se presser et de délivrer des conclusions qualitatives : Practice slowly, learn fast.
ACCURACY ACCURACY ACCURACY
J’ai encore en mémoire un ami (coucou Louis) qui me parlait de l’accuracy de son algorithme lors de nos études, algorithme à rendre le lendemain. Son accuracy dépassait la mienne de 10 % et je n’avais pas le temps de le retravailler.
Les meilleurs étudiants en data science se tatoueraient leur accuracy sur le front s’ils le pouvaient.
Les challenges Kaggle sont évalués sur l’accuracy, les notebooks Kaggle se vantent de l’accuracy directement dans les titres, et même de supers articles Medium comme celui-là essaient d’attirer les lecteurs avec l’accuracy.
L’accuracy est pratique pour communiquer de façon intuitive et pour donner une idée de l’efficacité d’un algorithme. Mais au sein de l’équipe data, l’accuracy n’a aucun sens. Mon maître de stage me disait même : “Je m’en fous de l’accuracy, tu as combien en précision ?”.
Pourquoi cela ? Pour vous donner l’intuition de la raison. Imaginez un ensemble de tests contenant 1 000 opérations bancaires. Parmi ces opérations, 40 sont des fraudes. Vous lancez votre algorithme de détection de fraude : Accuracy : 98%. C’est bien ! Mais en réalité, votre algorithme n’a détecté que 20 fraudes sur 40, il n’a fait le travail qu’à moitié. Malgré sa belle performance de 98% de réussite, il ne pourra jamais être utilisé en production. L’accuracy est nécessaire pour la communication, mais non suffisante pour l’évaluation.
A la différence des études et des coqs des amphis, les équipes data ne s’intéressent pas à l’accuracy mais à d’autres métriques à découvrir dans cet article.
Conclusion
Le monde de la data science n’est pas un long fleuve tranquille que l’on suit avec notre pagaie. L’océan sur lequel on navigue est source de nombreux apprentissages. De la théorie à la pratique, la vague est énorme, avec parfois des désillusions.
Le métier de data scientist demande des compétences techniques et une compréhension du business, du marché et des enjeux. Cet aspect n’est pas toujours abordé au cours des études, et encore moins durant les cours de data science qui se focalisent sur l’aspect mathématique et technique.
J’espère qu’avec ces quelques points, vous démarrerez votre expérience avec un meilleur recul que celui que j’avais quelques mois auparavant.
