Prédire la probabilité de réussite au code de la route : une rétrospective sur notre premier algorithme de machine learning en production

Introduction

Quoi de plus spontanée et sincère qu’une discussion entre clients sur les réseaux sociaux à propos de votre entreprise et de ses services ? Ces échanges constituent une mine d’information qu’il faut savoir utiliser pour améliorer l’expérience utilisateur. Nous en sommes convaincus chez Ornikar, et c’est ce qui nous a amené à travailler sur notre tout premier projet de machine learning (ML).

En effectuant notre veille habituelle, nous avons constaté que les utilisateurs de notre plateforme de révision du code de la route se regroupaient sur des communautés en ligne afin d’évaluer leur niveau et savoir s’ils étaient prêts à passer l’examen, et nous nous sommes dit que c’était l’occasion d’améliorer notre produit. Nous avions a priori toutes les données qu’il fallait pour aider nos centaines de milliers d’utilisateurs mensuels à identifier le moment où ils auraient le plus de chance de réussir l’examen : l’historique de révision de chaque élève et les résultats aux examens de ces dernières années.

Pour valider la faisabilité de l’idée avec l’état actuel de nos données et nos compétences techniques, nous avons commencé par organiser un hackathon au sein de l’équipe Data, et nous avons pu faire tourner en production notre premier algorithme de ML quelques mois plus tard. Dans cet article, nous allons revenir sur toutes les étapes qui nous ont permis de mener à bien ce projet.

Vous avez dit machine learning ?

À la fin de l’année 2020, nous avons donc organisé un hackathon avec l’équipe Data, qui était alors constituée de 4 personnes : deux Data Analysts, un Data Scientist et un Head of Data. Ce hackathon nous a permis de commencer à faire l’état des lieux des données à notre disposition, de les récupérer depuis nos différentes bases de données et d’explorer les pistes que nous avions en tête afin de confirmer ou infirmer nos hypothèses sur les variables les plus susceptibles d’expliquer une réussite à l’examen. Nous avons également comparé quelques algorithmes de ML entraînés sur les variables pertinentes, préalablement historisées, afin de valider la capacité de généralisation du problème posé à partir des exemples dont nous disposions.

L’idée initiale ayant été trouvée par l’équipe Data en observant les données, nous avons ensuite rapidement enclenché des discussions avec les équipes Produit et Design pour transformer le concept en fonctionnalité concrète pour nos utilisateurs. Une étape essentielle pour nous permettre de bien avoir en tête les contraintes techniques. Nous avons également défini à ce moment-là les indicateurs de suivi pour évaluer le succès ou non de ce premier projet de ML.

À la fin de cette étape, nous avions validé plusieurs hypothèses :

• Nous étions capables de prédire la réussite à l’examen d’un élève en analysant ses activités sur la plateforme.
• En conseillant à nos élèves de continuer à réviser avant de passer l’examen, ils le feraient.
• Tout cela nous permettrait d’augmenter le taux de réussite global de nos élèves à l’examen.

Feu vert !

Tous les feux étaient au vert et les données disponibles en quantité avec plusieurs centaines de milliers d’activités effectuées chaque jour sur notre plateforme de révision du code de la route. Il ne nous restait plus qu’à utiliser l’historique des révisions et à les confronter aux résultats de l’examen du code de la route pour formuler un problème de classification binaire sur l’obtention ou non de l’examen.

Mais cela s’est révélé plus un peu compliqué que prévu à mettre en place car plusieurs typologies d’élèves utilisent notre plateforme : certains révisent entièrement leur code de la route avec notre produit, tandis que d’autres l’utilisent plutôt en complément d’une auto-école traditionnelle.

Pour prendre en compte ce facteur, nous avons décidé de construire des variables relatives au début du parcours pour essayer de déterminer le niveau initial de l’élève qui rejoint notre plateforme à travers la quantité et la qualité des activités réalisées peu de temps après l’inscription.le score médian d’une série de révision du code.

Nous avons ajouté à cela des variables liées à :

• la performance au global,
• la régularité de l’élève,
• la dynamique des dernières semaines, car beaucoup d’étudiants parviennent à monter rapidement en compétence en bachotant à l’approche de l’examen.

Enfin, nous avons ajouté deux variables supplémentaires, en nous basant sur des études réalisées préalablement par les Data Analysts:

• le type de produit acheté (code, code et conduite)
• son parcours administratif

Il aurait aussi été intéressant de pouvoir analyser les réponses de l’utilisateur pour chaque question de code, mais cette donnée n’était malheureusement pas facilement disponible à l’époque.

La modélisation

Après avoir comparé plusieurs modèles, nous avons fait le choix pragmatique d’utiliser le framework LightGBM (LGBM) de Microsoft qui se base sur du gradient boosting et des arbres de décision. Il a l’avantage de donner des résultats de référence sur les problèmes de type tabulaire, de s’intégrer facilement avec l’écosystème de Scikit-learn, ce qui facilite son déploiement, et de fournir des prédictions nativement interprétables. Une fois l’algorithme choisi et les centaines de milliers d’observations classiquement séparées en un jeu de données d’entraînement et de test, nous avons enfin pu commencer son entraînement.

Nous avons effectué une recherche des hyper paramètres optimaux du modèle via une recherche aléatoire (random search), notamment sur le nombre de feuilles (num_leaves) et la profondeur de l’arbre (max_depth) qui contrôlent la complexité du modèle et qui sont très importants pour limiter le surapprentissage qui peut vite survenir sur un algorithme de type LGBM qui grandit par feuille. Puis nous avons complété cela avec de l’échantillonnage d’observations et de variables (respectivement bagging_fraction et feature_fraction) pour à nouveau limiter le surapprentissage et améliorer ses capacités de généralisation.

En guise de contrôle, nous avons observé la distribution normalisée en pourcentage de probabilité des prédictions de l’algorithme en fonction d’exemples pour lesquels nous connaissions l’issue de l’examen. Et nous étions plutôt satisfaits de la tendance qui se dégageait : nous retrouvions bien que plus la probabilité de succès de l’algorithme était grande en abscisse, plus la proportion d’examens réussis était élevée (proportion de vert en ordonnée).

Nous avons ensuite analysé les prédictions de l’algorithme grâce au package SHAP qui propose une approche basée sur la théorie des jeux. Cela nous a permis de déterminer les variables les plus prépondérantes dans le choix de l’algorithme et l’influence de la valeur d’une variable donnée sur ce choix.

Nous avons ainsi observé que :

• Un nombre de séries élevé avec une bonne performance juste avant l’examen conditionne un résultat positif
• De manière générale, une régularité dans la performance témoigne d’un bon apprentissage

Déploiement

Une fois confiant sur la précision de notre algorithme, nous avons enfin pu le déployer en production. Pour permettre aux Data Analysts et Data Scientists de parler un langage commun, nous avons fait le choix d’utiliser de manière extensive l’outil dbt pour la transformation de données en SQL, ce qui a permis de mettre en commun les transformations de données métier. L’équipe Data Engineering étant encore en cours de structuration à l’époque, nous avons préféré tirer au maximum parti de cet écosystème de transformations dbt, plutôt que d’orchestrer avec Airflow par exemple, ce qui nous a poussé à choisir un fonctionnement par batch plutôt qu’en temps réel. Enfin, nous avons déployé le web service contenant le modèle de ML en tant que Cloud Function pour déléguer la scalabilité et le déploiement côté Google Cloud Platform et garantir l’autonomie des Data Scientists.

Le fonctionnement en production, toujours d’actualité aujourd’hui, est le suivant:

Toutes les heures, nous copions les bases de données de production des développeurs. Les variables nécessaires à la prédiction de l’algorithme pour les élèves ayant effectué au moins une activité de révision sur la plateforme de code sont créées en même temps que les transformations des Data Analysts et sont ensuite sauvegardées dans une table BigQuery dédiée grâce à dbt.

Une fois cette étape achevée, le webservice se déclenche et récupère les observations précédentes qui sont prédites par batch par l’algorithme de ML. Cet algorithme sauvegarde les prédictions dans une table BigQuery pour des analyses ultérieures d’une part, et les dépose dans un stockage cloud qui permettra aux développeurs backend de les récupérer pour les afficher dans le produit d’autre part.

A la rencontre des utilisateurs

Un des challenges que nous avons rencontré lors du partage de la fonctionnalité auprès de nos utilisateurs a été de se mettre d’accord sur l’endroit où afficher la prédiction de notre algorithme. Il fallait en effet réussir à mettre suffisamment en avant ce taux de probabilité de réussite à l’examen pour qu’il ait un réel impact sur les élèves, sans pour autant leur faire de fausses promesses (d’autant plus que le taux n’est mis à jour qu’une fois par heure).

Nous avons finalement choisi d’afficher la prédiction sur la page qui permet de se renseigner sur la réservation d’une place pour l’examen du code de la route. Cette prédiction est matérialisée par une jauge plus ou moins remplie selon la probabilité de réussite estimée. Nous avons pris la décision de ne pas afficher le score sur 100 de manière brute pour ne pas créer de confusion auprès des élèves et nous laisser une marge de manœuvre sur les bornes délimitant les zones rouge, orange et verte. Si un élève est considéré comme étant prêt à passer l’examen, il sera encouragé à réserver sa place. Le cas échéant, nous l’encourageons à poursuivre sa formation, sans l’empêcher pour autant de s’inscrire à l’examen s’il le souhaite.

Cette fonctionnalité est disponible en production depuis le début du deuxième trimestre 2021.

Un an après

Un an après la mise en place de cette fonctionnalité, il est maintenant l’heure de faire le bilan ! Ce premier projet de ML a sans aucun doute construit les fondements d’une collaboration solide entre les équipes Data, Produit, Design et Cloud. Une gestion de projet efficace et des échanges constants nous ont permis de transformer une idée en une fonctionnalité en seulement un trimestre, alors que nous n’avions aucune expérience à l’époque sur le ML et que l’équipe Data était très restreinte.

Cette équipe a bien grandi depuis puisqu’elle compte dorénavant une douzaine de personnes. Nous avons également grandement amélioré notre outillage avec notamment dvc pour versionner de manière plus étroite notre code, nos données et nos modèles, et l’utilisation d’Airflow pour orchestrer nos pipelines de ML, ce qui nous permet d’augmenter considérablement le champ des possibles. Nous avons notamment lancé des travaux à propos de l’apprentissage personnalisé pour le code de la route ainsi qu’une vérification automatique des pièces administratives à la souscription d’une nouvelle assurance automobile (car oui, nous ne proposons pas seulement de réviser pour passer le code de la route et le permis de conduire). Grâce à cette première expérience réussie de ML, nous pouvons aborder ces projets futurs plus sereinement !

Vous avez aimé cet article ? N’hésitez pas à nous laisser un commentaire. Et si nos projets data vous intéressent, jetez un œil à nos offres d’emploi. On recrute !