Marc 00:00:59 – 00:01:31 : Aujourd’hui, je reçois Alexandre Sayard, Data Scientist puis Product Manager chez Lyft. Lyft est une plateforme de VTC concurrent d’Uber avec qui il se partage le marché américain. Bonjour Alexandre. 

Alexandre 00:01:31 – 00:01:32 : Bonjour Marc. 

Marc 00:01:33 – 00:01:41 : Alors Alexandre, est-ce que tu peux nous parler de Lyft, nous dire qu’est-ce que vous faites exactement ? 

Alexandre 00:01:41 – 00:02:19 : Bien sûr. Je pense que tu l’as bien résumé. On est avant tout une plateforme de ride share. Comme Uber, qui est aussi présent en Europe, notre objectif, c’est de matcher des passagers qui cherchent à faire des courses avec des chauffeurs qui cherchent à générer des revenus avec leurs véhicules. La différence principale entre Uber et nous, c’est qu’on est essentiellement focalisé sur la mobilité. Donc, on n’a pas lancé de business unit pour faire de la livraison de repas. Et on s’est focalisé sur la micro-mobilité en plus du ride share avec des opérations de vélo. Et comme tu l’as dit, on se partage le marché américain. On est le petit Uber présent aux États-Unis et au Canada. 

Marc 00:02:21 – 00:02:35 : OK. J’ai une petite parenthèse. Tu as mis pas mal de choses sur le marché biface et compagnie. 

Alexandre 00:02:37 – 00:02:38 : On peut creuser ? 

Marc 00:02:38 – 00:03:00 : Je peux peut-être te relancer là-dessus. Ouais, soit je… Soit tu enchaînes en mode tu développes, peut-être. Parce que sinon, c’est vrai que ça veut dire que je te pose la question. 

Alexandre 00:03:00 – 00:04:54 : Oui, tu as raison. Donc, notre principe, c’est de matcher les passagers qui cherchent à faire des courses avec les chauffeurs qui cherchent à les donner. Et donc, ça donne lieu à des problématiques de growth et d’expérience sur ces deux côtés de la plateforme. On est une plateforme biface et donc, il faut qu’on fasse attention à… à ses deux côtés. Du côté passager, qu’est-ce que ça veut dire ? Il faut qu’on soit capable… Je vais reprendre. Je pense que c’est plus simple de commencer par les chauffeurs. Du côté chauffeur, Ce qu’on cherche à faire, c’est de faire en sorte qu’on a assez de chauffeurs pour servir la demande à tout instant. Cette demande est distribuée temporellement et spatialement. Il faut qu’on fasse en sorte d’avoir assez de chauffeurs pour servir cette demande. Donc on va utiliser des leviers d’activation pour dire aux chauffeurs de se connecter en temps réel car on attend un pic de demande par exemple. On va aussi utiliser différents leviers marketing pour faire en sorte que notre flotte se renouvelle, car c’est malheureusement un business où le churn est assez rapide. Et donc, on doit être constamment en train d’activer ces leviers pour faire en sorte de servir cette demande. Côté passagers, on est en compétition sur quasiment chaque session passager. On est en compétition avec Uber. On est en compétition sur le prix, on est en compétition sur l’ITA et pareil qu’avec Uber, on va peut-être utiliser des mécanismes comme les coupons pour être plus compétitifs sur le prix et toujours sur cette idée de densité de chauffeur. Plus on va être dense, plus on va être capable d’être compétitif sur l’étier. Et c’est quelque chose qui va être le premier driver de convertir la volonté du passager à prendre la course. 

Marc 00:04:54 – 00:05:13 : Alors peut-être pour bien comprendre l’état de la concurrence et des différents marchés, sur le rôle des chauffeurs, parce que les chauffeurs ont les deux applications Uber et Lyft… Si on a une proportion à avoir en tête de gens qui ont les deux, qu’est-ce que ce serait ? 

Alexandre 00:05:13 – 00:06:01 : Oui, c’est une excellente question. Alors, je n’ai pas de chiffres. Et d’ailleurs, je pense que c’est assez compliqué à mesurer. Mais il faut imaginer que les chauffeurs comme les passagers, ce sont deux populations pour lesquelles il est très difficile de créer de la loyauté. On se rend compte que malgré tous les efforts qu’on peut mettre dans la construction de features, l’écoute et tous les interviews que nos user researchers mènent, Finalement, les grands drivers pour les chauffeurs et les passagers, ça va être la rémunération et le prix. Je pense qu’il n’est probablement pas faux de dire que quatre chauffeurs sur cinq ont au moins les deux applications installées. Il reste des cohortes, il subsiste des cohortes de chauffeurs et de passagers qui sont loyales à une plateforme, mais c’est quelque chose qui est très rare. C’est pour ça qu’on est constamment en compétition sur les deux. 

Marc 00:06:02 – 00:06:13 : Aucun moyen de jouer sur des incentives à ne pas avoir l’autre application ouverte. Vous ne pouvez pas tellement le savoir d’une certaine façon que l’autre application est ouverte aussi, j’imagine. 

Alexandre 00:06:13 – 00:08:17 : Alors, il y a plusieurs signaux qu’on pourrait essayer de prendre en compte. Pour les chauffeurs, c’est assez visible finalement. Vous pouvez étudier assez concrètement ce qu’on appelle un « shift ». Un shift, c’est un ensemble de courses qui a été donné par un chauffeur, par exemple au sein d’une journée, et on peut en identifier des patterns. Je m’excuse pour le franglais, c’est très difficile de parler du boulot en français, j’ai fait un effort immense en essayant d’écrire, mais ça va ressortir à quelques moments. Donc on peut identifier des patterns et voir par exemple une succession de courses données par le chauffeur, qui constitue un bloc. Ensuite, vous pouvez avoir un espace d’une demi-heure, 45 minutes, puis la reprise de course qui s’étale sur une après-midi ou d’une matinée. Là, vous avez une preuve quasi évidente de ce qu’on appelle dual apping, et donc probablement d’un passage sur l’autre application. Pour le chauffeur, c’est assez facile. On peut étudier cette donnée de shift ou de bloc pour avoir une idée de qui passe d’une plateforme à l’autre. Pour les passagers, il y a probablement aussi un autre proxy qui est à quel point votre utilisateur avance dans le funnel lorsqu’il ouvre l’application. D’abord, il va ouvrir l’application, puis il va entrer à une destination, regarder les prix. Là, vous pouvez utiliser toute la donnée client qui nous revient de l’application en elle-même pour estimer si l’utilisateur s’est vraiment posé la question. très souvent quand on utilise le ride share vous avez la volonté d’aller quelque part. vous n’êtes pas en train de regarder les prix pour avoir une information et construire un dataset même si c’est quelque chose qui arrive. je peux raconter une anecdote plus tard là dessus. donc si vous voyez que l’utilisateur s’arrête au moment du prix il y a de bonnes chances qu’il soit allé commander chez la compétition et c’est d’ailleurs un signal qu’on utilise très souvent pour construire des élasticités ou la loyauté. 

Marc 00:08:18 – 00:08:45 : Ok, super intéressant. Alors du coup, du côté chauffeur, si je continue mon raisonnement, est-ce qu’il n’y a pas des moyens d’incentiver, de motiver ? Moi aussi, j’ai essayé de faire l’effort de parler français. Motiver le chauffeur à rester sur l’application, je ne sais pas, par exemple, en changeant la commission, je dis n’importe quoi, mais en changeant la commission en fonction du nombre de rails dans la journée ? 

Alexandre 00:08:45 – 00:11:36 : Tout à fait. On y revient. Je disais tout à l’heure que le levier principal sur lequel on pouvait jouer, c’était les revenus pour les chauffeurs et le prix et l’ITF pour les passagers, si je schématise, évidemment. Pour les chauffeurs, quelque chose qui est très important… c’est la transparence des revenus. Initialement, et c’était pareil en France, quand Uber s’est lancé, y compris leurs autres petits concurrents, on parlait d’une commission fixe, c’était assez clair. Et puis avec la densité qui augmente, la diversité des courses, finalement la prolifération de plein de sortes d’offres, de modes plus ou moins luxe, etc., c’est devenu un peu plus compliqué, un peu plus opaque de traquer la commission. les chauffeurs ont perdu la capacité de vraiment savoir le lien entre ce que le passager payait et ce que eux touchaient. Donc une des initiatives, deux initiatives que nous avons mises en place et qui ont été d’ailleurs assez médiatisées aux Etats-Unis, c’est de rendre aux chauffeurs la garantie d’un revenu par ce qu’on a appelé un commitment à recevoir une certaine fraction de ce que leurs passagers payent. Ça, c’est quelque chose que nous avons lancé l’année dernière. où chaque semaine, il est fait un état des lieux des courses qu’ont donné un chauffeur. On regarde combien ont payé les passagers. Et ensuite, on regarde ce que le chauffeur a perçu sur toutes ces courses. Et la somme de ses revenus doit être au moins supérieure ou égale à un certain seuil par rapport à ce que les passagers ont payé. Donc ça, c’est la transparence qui leur permet de les assurer qu’ils reçoivent une fraction juste et équitable de ce que les passagers ont payé. Ça paraît faible et en termes de data science, il n’y a pas de data science, mais c’est quelque chose qui a eu un impact très puissant dans la communauté parce que ça permet de construire la confiance et de rétablir un peu ce lien qui s’était perdu. Donc ça, c’est la première initiative. Et la deuxième, elle est un peu antérieure, mais elle relève du même effort un peu global de redonner de la transparence. C’est que nous avons fait un grand pivot que Uber avait fait également ou a fait plus ou moins au même moment. Je crois d’ailleurs que nous avions été les premiers, ce n’est pas certain. Nous avons décidé de… offrir aux chauffeurs la possibilité d’accepter ou de refuser une course et de leur indiquer le montant qui était associé. Quelque chose qui n’était pas du tout historique sur les plateformes. On vous proposait une requête pour aller d’un point à un point B en tant que chauffeur et vous deviez l’accepter, sous peine d’être pénalisé si cela arrivait trop rapidement. Maintenant, on vous donne la possibilité de voir le prix de cette course, donc combien vous allez toucher, de voir les détails et de l’accepter ou de la refuser. Donc pareil, volonté d’établir ce lien. 

Marc 00:11:38 – 00:12:34 : Ok, hyper intéressant. Et c’est des évolutions qu’on n’a pas forcément dans le grand public, qu’on ne connaît pas forcément dans le grand public. De l’autre côté, tu as parlé de l’ETA, donc Estimated Time of Arrival, l’heure d’arrivée estimée. Ça, c’est un facteur de concurrence. Le fait de regarder… Je raisonne un peu bêtement, mais je me dis… Le fait que Uber ou Lyft annonce un temps plus faible que l’autre, pour moi, c’est plus une question de performance de leur algo, de prédiction de trajectoire, etc. Mais ça ne change pas la réalité. La voiture, c’est une voiture. Les rues, c’est les mêmes. Est-ce que tu peux nous en dire un peu plus sur cette ETA comme facteur de concurrence ? 

Alexandre 00:12:34 – 00:14:55 : Oui, c’est une question très intéressante. C’est effectivement un facteur de concurrence, car il faut imaginer qu’il y a quand même pas mal de cas d’usage pour le ride share. Si je schématise, il y a deux grands cas d’usage qui s’opposent. C’est ce qu’on appelle le commute. C’est des gens qui vont au travail le matin et le soir et qui… soit parce que c’est payé par le boulot, donc là on est sur un peu un business ride, ou des gens qui, pour des raisons x ou y, ne peuvent pas prendre les transports publics. Et le deuxième grand cas d’usage, c’est le social, où là, probablement, les contraintes sont un peu moins élevées. L’idée, c’est de sortir, retrouver des amis, etc. Si vous prenez le cas du commute et notamment les gens qui travaillent pour le business, peut-être qu’ils vont à l’aéroport, peut-être qu’ils sont en déplacement pour un rendez-vous pro. Donc là, la contrainte de temps devient assez importante. Donc on a des signaux qui nous montrent que c’est quelque chose que les utilisateurs cherchent. Et même nous avons été plus loin, nous avons créé des offres qui permettent de répondre à cette demande. ou pour un prix différencié, vous avez accès à une voiture qui est plus proche. Ce qui fait qu’on a segmenté un peu notre portefeuille d’offres. Vous pouvez payer plus cher pour avoir une voiture qui est plus rapide. Vous pouvez aussi payer moins cher, et c’est là que ça devient très intéressant. Vous pouvez payer moins cher si vous êtes flexible sur le temps. C’est-à-dire que souvent, les gens qui vont à l’aéroport, ils ont leur entreprise qui leur rembourse la course. Donc, peu importe qu’il y ait quelques euros ou dollars en plus, ils peuvent se le permettre. Mais vous avez beaucoup de gens qui souhaiteraient prendre un taxi ou le ride-share de nuit parce qu’il est tard, qu’il n’y a plus de transport public ou que ce sont des courses longues. Mais le principal frein, c’est le prix. Donc nous avons créé un peu à l’inverse de cette offre différenciée, une offre qu’on appelle « attendez et économisez de l’argent », « wait and save » en anglais, ou pour un certain rabais sur le prix initial. on vous garantit une voiture dans un intervalle de temps beaucoup plus large et qui n’arrivera pas immédiatement. Donc ça permet, si vous avez de la flexibilité et que vous êtes prêt à faire un compromis sur cette ETA, ça vous permet d’économiser et peut-être de vous offrir ce service que vous n’auriez pas pu. 

Marc 00:14:56 – 00:15:16 : D’accord. Donc, il y a l’arrivée de la voiture. Effectivement, ça, c’est quelque chose. Est-ce qu’on est servi en priorité ou non pour les prochaines voitures qui passent dans le quartier ? Mais sur la deuxième partie, celle qui constitue le trajet, il n’y a pas tellement de façon d’anticiper sur le fait que tel ou tel chauffeur sera plus rapide ? 

Alexandre 00:15:16 – 00:17:44 : Tout à fait. Quand je parlais d’OTR, c’était vraiment le moment où la voiture arrive en bas de chez vous. C’est cette métrique-là que l’utilisateur regarde. Effectivement, après, vous êtes sur quelque chose de parfaitement similaire. Peu importe le mode. Je dirais même d’ailleurs que vous ne voulez pas que votre chauffeur aille trop vite. Sinon, on a une des plaintes qu’on reçoit le plus souvent, c’est le chauffeur allait trop vite. Donc non, non, sur la partie, tout à fait, sur la partie entre chez vous ou l’endroit où vous faites la requête, l’endroit où vous voulez être déposé, là-dessus, on ne crée pas de distinction. On avait essayé de le faire sur un sujet très intéressant, d’ailleurs, de data science et d’analytics, qui était de dire… notamment dans les villes assez congestionnées où le réseau routier est assez complexe avec des sens interdits et beaucoup de densité. Prenez par exemple Manhattan à New York. On avait essayé d’envisager de faire gagner du temps en faisant marcher l’utilisateur à l’arrivée à sa destination ou quand la voiture vient le chercher. Parce que là, vous avez des optimisations assez incroyables à faire, soit en traversant la rue, soit en marchant d’un bloc à l’autre. Vous pouvez gagner parfois trois minutes sur l’arrivée finale à destination. Et c’est d’ailleurs justement là que le trade-off que tu as mentionné est intéressant. C’est que parfois, on disait aux utilisateurs… vous allez perdre une minute sur le moment où la voiture vient vous chercher mais vous pouvez en gagner 4 sur l’arrivée finale parce que vous partirez pas du même point. et en fait ça c’est quelque chose qui qualitativement et on l’a vu quand on lançait les produits ça marche pas très bien parce que Ce qui intéresse les gens, c’est quand est-ce que la voiture arrive ? Évidemment, on s’ajoute à ça des problématiques opérationnelles et de communication, c’est-à-dire que c’est quelque chose de complexe de dire à deux personnes de se retrouver dans une ville en pleine journée avec le trafic et tous les stimuli. Quand en plus vous rajoutez la notion de marche pour quelqu’un qui ne connaît pas forcément la ville, tous les aléas qui peuvent arriver, c’est un produit qui, sur le plan théorique, a d’énormes bénéfices et ça marcherait très bien pour toutes les grandes villes. À Paris, je pense que ça aurait aussi une utilité, mais c’est quelque chose qui n’a jamais réussi à être pérennisé à cause des problématiques opérationnelles et de la difficulté à faire accepter ce petit sacrifice. 

Marc 00:17:44 – 00:18:00 : Oui, et puis ça doit être facile de se faire comprendre par l’utilisateur l’option qui a une certaine complexité. J’imagine que certains utilisateurs auraient aimé que ça continue, cette feature, mais que c’est compliqué de faire adopter ça à tout le monde. 

Alexandre 00:18:00 – 00:18:03 : Oui, c’est ça. On a eu du mal à le pérenniser. 

Marc 00:18:05 – 00:18:11 : Alors, quel est le rôle de l’équipe Data, Data Science, Data Engineering ? Comment c’est organisé? chez Lyft ? 

Alexandre 00:18:11 – 00:20:11 : Oui. Alors, si je devais résumer le rôle de l’équipe data chez Lyft, je dirais qu’il y a deux grandes missions. La première mission, c’est de formuler des hypothèses. C’est la partie un peu plus exploratoire, analytics de notre métier, qui est sur la base des données qu’on génère et qu’on collecte et qui sont analysables. Quelles sont les choses qu’on peut améliorer dans notre produit ? Que ce soit côté chauffeur, côté passager, on a beaucoup parlé, au sein de la marketplace dont le rôle est de faire le matching. Quelles sont les choses que nous pouvons améliorer ? Donc ça, c’est la première responsabilité. Et la deuxième responsabilité, c’est la prise de décision. La prise de décision, elle peut prendre plusieurs formes. J’aime bien la classer en deux grandes catégories. Il y a peu de décisions importantes. Et souvent, ce qu’on fait appel… Pardon, les… Les connaissances auxquelles on va faire appel, ça va souvent être les statistiques. Donc quand on génère autant de volume que notre plateforme et qu’on veut tester les hypothèses qu’on a formulées, on va faire des expériences, on va mesurer et essayer de diagnostiquer ce qui se passe. Ça, c’est quand on est dans le domaine de pas beaucoup de décisions, mais qu’elles sont importantes. Et quand on a beaucoup de décisions à faire, et comme souvent quand on fait du matching comme chez Lyft, on va avoir beaucoup de décisions à prendre en temps réel, là on arrive dans le domaine du machine learning, de l’IA au sens large. Et c’est le rôle des data scientists de formuler ces hypothèses, de convaincre les différentes parties prenantes que peut-être il y a des choses à changer. Et une fois qu’on a enclenché tous ces mécanismes, aider à la prise de décision, soit avec des statistiques, soit avec du machine learning, soit avec de l’inférence. C’est ça notre rôle. Ok. 

Marc 00:20:12 – 00:20:17 : Tu avais quelques exemples à nous donner de décisions comme ça prises par l’équipe Data, grâce à l’équipe Data ? 

Alexandre 00:20:17 – 00:21:54 : Oui. Alors sur la décision par exemple, il y a quelque chose sur lequel j’ai travaillé qui est quand un passager décide d’annuler sa course. Quand un passager décide d’annuler sa course, il y a pas mal d’enjeux. On pourra creuser tout à l’heure. mais il faut décider si on charge des frais d’annulation et c’est quelque chose qu’on doit faire en temps réel puisqu’il faut le montrer dans l’application lorsque le passager décide d’annuler. donc ça c’est typiquement quelque chose qui va probablement impliquer du machine learning. ça c’est un exemple de décision. dans la partie on en prend beaucoup en temps réel. dans la partie on n’en prend pas beaucoup. c’est très important. Plus récemment, on a décidé de lancer de la publicité dans l’application. On s’est rendu compte que ça pouvait être un levier pour augmenter nos marges. Uber et Lyft se sont mis à faire ça. On travaille directement avec des agences ou des entreprises en direct qui veulent faire du marketing sur notre plateforme. on a dû décider où est-ce qu’on allait les positionner. Donc il y avait plusieurs hypothèses. Est-ce qu’il faut les mettre avant la requête ? Est-ce qu’il faut les mettre après la requête ? À quel moment exactement on veut les impliquer dans le flow ? Quelle taille doivent-elles faire ? Là, on ne peut pas tout tester. Il y a des intuitions, on mène des entretiens, on utilise des expertises métiers et on teste avec des expériences, avec des statistiques. On fait en sorte de ne pas dégrader le business. Et c’est ça qu’on va ensuite recommander pour que les ingénieurs implémentent la solution finale. 

Marc 00:21:55 – 00:22:21 : Je reprends ton premier use case pour bien l’expliciter. Donc, frais d’annulation, on peut prendre la décision d’en mettre, de ne pas en mettre, de mettre un montant qui varie. Qu’est-ce qu’on recherche à optimiser ici ? Finalement, le revenu, les chances d’annulation ? Si on devait poser le problème mathématiquement de machine learning, finalement, qu’est-ce que c’est ? 

Alexandre 00:22:21 – 00:26:20 : C’est une excellente question. Et je pense qu’avant même de s’attaquer à la formulation mathématique, il faut essayer de comprendre quelles sont les priorités de l’entreprise à ce moment-là. Car à l’époque où j’ai travaillé sur ces sujets, c’était un moment où on avait la pression pour générer du profit court terme. Donc il y avait possibilité, si on avait voulu, je ne dis pas que c’est ce qu’on a fait, mais d’optimiser cette fonction pour générer plus de revenus. Parce que ce qu’on reçoit de la part des passagers n’est pas forcément égal à ce qu’on va payer aux chauffeurs. Donc effectivement, ce qu’on cherche à maximiser, ça va être la valeur pour l’entreprise. Et historiquement, ce qu’on a fait, c’est qu’on essaie de décomposer le problème et de comprendre toutes les conséquences de nos décisions. Quand vous décidez de charger un frais d’annulation, le premier impact qu’on peut quantifier, c’est quelle est la probabilité que votre utilisateur décide finalement de ne pas annuler, puisqu’il voit sur l’écran « si vous annulez, vous allez devoir payer 5 euros, 5 dollars ». Donc on peut calculer une probabilité que finalement ce passager décide de continuer avec la course. C’est d’ailleurs quelque chose d’assez fréquent parce que beaucoup de passagers passent des recettes sur à la fois Uber et Lyft pour voir qui serait le premier chauffeur qui arrive. Donc les frais d’annulation permettent d’éviter ce genre de comportement. Donc ça, c’est la première chose qu’on peut quantifier. Cette probabilité incrémentale de conversion de la course. Et vous pourriez ensuite imaginer que si on charge des frais infinis, ce terme-là va être très grand. Vous allez convertir toutes vos courses. C’est la première chose qu’on peut quantifier. Mais ensuite, il faut essayer de décomposer le problème avec d’autres éléments. Ce que vous pouvez comprendre également, c’est que lorsqu’un passager doit payer les frais d’annulation, il y a de bonnes chances qu’il contacte le support. Donc vous allez avoir des coûts. sur les frais qui vont être générés par notre équipe support de s’occuper de cette requête. Est-ce qu’on doit peut-être même rembourser les frais qui ont été chargés ? Dans ce cas-là, vous vous rendez compte qu’en fait, vous avez chargé 5 euros et vous devez reverser 5 euros, donc c’est une opération nulle. Et au-delà de ça, vous avez même des coûts humains qui sont parfois engagés. Donc, vous avez perdu de l’argent. Deuxième élément à prendre en compte, les coûts de support. Troisième élément, on a montré, et ça a pris des années de construire ces connaissances, mais on sait que lorsqu’on prend des décisions comme charger un frais d’annulation, au-delà de l’impact de court terme que j’ai mentionné, la probabilité de convertir la course et la probabilité d’engager des frais de support, vous avez aussi un impact de long terme. C’est difficilement mesurable quand on fait des expériences qui s’étalent sur plusieurs semaines, mais ça fait partie des choses que des experts chez Lyft, qui sont souvent focalisés sur ces concepts d’inférence causale, ils utilisent des méthodes dont on pourrait parler plus tard, mais qui permettent de quantifier l’impact sur la rétention des utilisateurs. Combien de courses vous allez perdre si Lyft ou Uber vous fait payer 6 ou 7 euros parce que vous avez attendu deux minutes de trop ? Donc ça, c’est le troisième terme à prendre en compte. Vous vous rendez compte qu’en fait, à chaque fois que vous prenez cette décision, peut-être que vous ajoutez un impact négatif au long terme. Tout ça, finalement, vous le transcrivez en un impact monétaire et en fonction des priorités du business, en fonction de quel est l’output que vous voulez pour votre système, Vous pouvez attacher des poids à chacune de ces composantes et construire quelque chose qui vous permet d’optimiser ce système. Soit on creuse ça, mais après… Je ne sais pas où tu veux… 

Marc 00:26:22 – 00:27:23 : J’ai très envie de creuser cette histoire d’inférence causale. Comment est-ce qu’on résout cette question d’influence sur le long terme, d’avoir chargé des frais d’annulation sur une sorte de rétention, de retour ? de l’utilisateur, puisqu’il n’y a pas de client loyal, on l’a vu, mais il y a peut-être des clients qui ont une dent contre Lyft et qui ne veulent pas revenir contre Lyft si on les a pénalisés avec des frais d’annulation. Et en même temps, c’est quelque chose de très long terme. Il faut des grandes populations pour tirer des leçons. On sent que si on veut faire des statistiques, on va avoir besoin quand même de mettre beaucoup de monde dans la boucle. Et puis, peut-être que quelqu’un qui a utilisé Lyft un jour n’aura pas besoin de Lyft le lendemain. Et ce n’est pas qu’il a une dent contre Lyft. Donc, très curieux de savoir comment on résout cette question d’inférence causale. 

Alexandre 00:27:24 – 00:32:01 : Oui. Alors, il faut savoir que ce sont les problématiques sur lesquelles j’ai travaillé en tant que membre du projet, mais plus dans la partie « quelles sont les expériences qu’on veut quantifier ? » « Où est-ce que la data vit ? » « Comment interpréter cette data ? ». J’ai pu travailler avec des personnes dont le métier et 100% de leur temps étaient consacrés à répondre à ces questions. Je ne pourrais pas forcément m’étaler en très grande longueur sur les techniques qui sont utilisées. mais peut-être de manière plus générale sur comment on fait en sorte de comprendre comment nos utilisateurs réagissent de manière causale, avant même de faire des méthodes avancées, il y a quelque chose qu’on peut faire qui est de mettre de côté certains utilisateurs, finalement de faire comme une expérience de long terme, où certains utilisateurs vont avoir une expérience différente de la majorité. On peut leur laisser cette possibilité pendant 6 mois, 12 mois, de construire un dataset, et nous on appelle ça un holdout, donc on les met de côté, et ils ne vont pas bénéficier de la même expérience que les autres utilisateurs. Donc ça, ça nous permet de manière très claire d’avoir une randomisation entre nos utilisateurs et d’avoir une réponse causale à certains sujets. En l’occurrence, ça c’est une approche qu’on n’a pas voulu faire avec les frais d’annulation. Parce qu’il y a des coûts qui sont engagés à charger à répétition des frais d’annulation sur le même utilisateur. Donc on n’a pas pu se dire qu’on allait mettre 2, 3, 5% de nos utilisateurs dans cette mauvaise expérience pour mesurer le coût agrégé d’un frais d’annulation à répétition. En revanche, pour d’autres expériences, c’est quelque chose que nous avons utilisé. Par exemple, pour l’impact des publicités, nous avons décidé de mettre de côté une fraction de nos utilisateurs qui seraient protégés des publicités et de comparer cette population au reste de la population qui, elle, n’avait pas été protégée. Ils nous ont pu apprendre des choses assez fascinantes sur comment ils réagissent aux publicités, est-ce qu’ils décident d’annuler plus et moins, et qui sont des réponses causales. Pour revenir à l’exemple des frais d’annulation, ce qu’on fait, c’est qu’on utilise des méthodes avancées dont moi, je ne suis pas les personnes qui l’implémentent, mais c’est des choses comme le S-Learner, T-Learner, le AIPW qui est un estimateur qui fonctionne avec l’idée de Propensity Matching. Donc on essaie de recréer deux populations identiques qui présentent les mêmes caractéristiques d’avoir le traitement. Donc le traitement dans notre étude causale pour le frais d’annulation, c’est est-ce que vous avez été chargé un frais de 5 euros, 5 dollars ? Évidemment, il y a un billet. C’est-à-dire que si on prend juste les deux populations et qu’on les compare, on va se rendre compte que peut-être notre estimation de l’impact sur la rétention des utilisateurs et leur course prochaine, leur course future dans les six prochains mois, peut-être va même nous donner l’inverse de l’intuition. Ça, c’est juste lié au fait que les deux populations ont des caractéristiques très différentes. Donc, il va falloir reconstruire un dataset pour les rendre comparables. C’est là que les méthodes causales d’estimation rentrent en jeu. Il y a plusieurs écoles. Il y en a qui passent directement par du machine learning. Vous construisez deux modèles pour prédire votre comportement d’utilisateur à horizon 6 mois. Un où la personne avait été chargée un frais, un autre où la personne n’avait pas été chargée un frais. Ça, c’est le Tea Learner. Il y a d’autres modèles qui reposent plus sur cette idée de Propensity Matching. Et pour ça, on va essayer de prédire la probabilité d’un utilisateur à être traité, donc à recevoir le frais, et on va les regrouper en cohortes. Donc, si vous avez une probabilité moyenne d’être traité, on va vous comparer contre les utilisateurs qui ont cette même probabilité. Voilà, ça, c’est les deux grandes familles. Pour l’aspect annulation, c’est sur ces méthodes que nous avons reposées, car nous refusions à mettre une population de côté et qu’elle subisse à répétition ces mauvaises expériences. 

Marc 00:32:02 – 00:32:17 : Ok, hyper intéressant. Est-ce qu’il y a d’autres exemples d’analyse faites par la team data que tu aurais envie de nous partager ? 

Alexandre 00:32:17 – 00:36:44 : Oui, puisqu’on a discuté des frais d’annulation côté passager, un sujet connexe mais qui est intimement lié, c’est la compensation financière des chauffeurs lorsqu’un passager décide d’annuler sa course. Est-ce qu’on va les payer ? Et si oui, de quel montant ? Historiquement, c’était un frais fixe. C’est-à-dire que lorsqu’un passager annulait, le chauffeur recevait un frais d’un certain montant et il semblait, en étudiant les contacts au support, les remontées du terrain et après certaines interviews, que les chauffeurs n’étaient pas satisfaits de ce modèle. Une hypothèse qui a été émise, c’est que peut-être la compensation n’était pas alignée avec l’effort fourni. Parce qu’en tant que chauffeur, parfois, vous pouvez conduire pendant 15 minutes sur l’autoroute. Ça peut être extrêmement compliqué. Il peut y avoir du trafic. Et puis, après 15 minutes d’effort 20, votre passager annule. Et là, si vous recevez 4 euros, ça vous paraît peut-être trop faible. Donc, ce qu’on a décidé de tester, c’était est-ce que si on paie les chauffeurs en fonction de la durée et du temps qu’ils ont passé sur cette course même avortée, potentiellement, est-ce qu’ils seront plus satisfaits ? Et alors là où c’est très intéressant, c’est que lorsqu’on a mis en place ce test, on s’est rendu compte que la compensation moyenne… allait diminuer. C’est-à-dire que le frais fixe était finalement assez élevé. Et lorsqu’on somme ça et qu’on compare à notre nouveau modèle de compensation, les chauffeurs allaient perdre en compensation. Mais on a décidé de tester ça. Alors comme c’est lié à la compensation financière des chauffeurs, il y a beaucoup de régulations et d’aspects légaux qui rentrent en jeu. Donc on n’a pas pu faire un vrai test, AB test, avec deux populations différentes, justement toujours dans cette idée de comprendre parfaitement l’impact causal de notre changement. Donc, on a décidé de déployer ce changement par vagues de régions. Et ensuite, l’idée était d’appliquer un groupe de contrôle synthétique pour comparer la première vague qui avait bénéficié de ce changement aux vagues qui, finalement, n’avaient pas eu ce changement. Alors, cette approche n’a pas fonctionné. Ce qui est intéressant, c’est pourquoi elle n’a pas fonctionné. Elle n’a pas fonctionné parce que nous n’avions pas été mis dans la boucle à temps. Donc, lorsque l’équipe Legal Product a mis en place le plan de déploiement, ils n’ont pas pensé à nous consulter pour faire en sorte que les régions qui étaient sélectionnées pour faire partie de la vague 1 allaient nous permettre de construire ce groupe de contrôle synthétique. Donc, ça a été un petit peu panique à bord puisqu’on a on n’avait plus vraiment de moyens à notre disposition pour concrètement mesurer l’impact de cette disposition, qui avait un gros changement sur la compensation financière des chauffeurs. Donc, il y a quelque chose avec beaucoup de visibilité et que l’entreprise scrute. Donc là, il a fallu être créatif, puisqu’on nous a quand même demandé de faire une recommandation sur l’efficacité de ce changement, en n’oubliant pas que les chauffeurs perdaient à la rémunération totale. Donc, ce qu’on a fait… C’est scientifiquement pas puissant du tout, mais quand vous faites des changements comme ça qui impliquent potentiellement des répercussions importantes, on peut regarder ce qui se passe pré-changement et post-changement et essayer de voir si vous avez des discontinuités qui sont introduites. Donc, en expliquant un petit peu le concept des concepts statistiques assez simples comme standard deviation, quel est le bruit naturel que nous avions dans les métriques qui nous intéressaient à l’époque, qui était le taux de requête au support et le taux d’annulation des chauffeurs qui permettait de caractériser l’efficacité du changement. on a pu montrer qu’il y avait d’immenses discontinuités qui avaient été introduites dans ces métriques et qu’on voyait des taux de réduction sur, par exemple, la fréquence de contact au support qui était extrêmement important, avec des chutes de plus de 5 ou 6 standards d’aviation par rapport à ce qui se faisait avant l’introduction de notre changement. Ça a suffi à convaincre les différentes parties prenantes et on a pu utiliser ça pour le reporting et justifier la décision de déployer ce changement. 

Marc 00:36:46 – 00:37:03 : Ok. Tu as une opinion sur la conciliation entre la vitesse d’exécution et avoir la culture de tout déployer avec des tests ? Tu veux nous parler un peu de cette opinion que tu as développée ? 

Alexandre 00:37:03 – 00:39:25 : Oui. Alors, elle s’est développée au fur et à mesure de mes années chez Lyft. Je pense que quand j’ai rejoint, c’était l’année de l’IPO, c’était pré-Covid, c’était encore un peu l’âge d’or de ces grandes entreprises de tech américaines. Et je pense qu’il y avait dans la tête de beaucoup de gens une certaine façon de faire les choses. Et ça passait toujours par, quand on veut déployer un changement, une nouvelle feature, il faut faire une expérience. Il faut qu’on mesure l’impact sur tous nos utilisateurs. Et c’est vrai qu’avec l’échelle que Lyft a, on mesure souvent quelque chose lorsqu’on introduit un changement. Mais ça introduisait finalement beaucoup de lenteur. Et quelque chose que j’ai réalisé, c’est que parfois, cette volonté de faire des expériences n’était pas vraiment le fruit de la nécessité de prendre une décision, mais tout simplement de… mesurer l’impact d’un changement sur une partie du funnel utilisateur ou peut-être même pour qu’une personne puisse écrire dans une review pour un dossier supérieur qu’il avait eu tel ou tel impact. mais on ne changeait pas fondamentalement le fonctionnement de l’entreprise ni la direction de l’entreprise. donc au fur et à mesure des années ce que j’ai observé et que j’ai contribué à ma petite échelle à mettre en place c’était de parfois accepter que lorsque la décision était déjà prise on ne mesure pas puisque l’expérience ne va pas particulièrement influer sur ce qui va se passer après. à partir de là je ne vois pas l’intérêt de mesurer pour mesurer. Parfois, lorsqu’il y a une très grande certitude et beaucoup d’enjeux financiers en cours, peut-être qu’au lieu de faire un test 50-50, on accepte de perdre un peu en pouvoir statistique et on se dit « on déploie à 95% de nos utilisateurs, on garde un petit groupe qu’on met de côté ». On garde ça pendant 8 semaines, on fait l’analyse qui nous permet de dire, voilà, vous allez être capable de détecter tel effet, tel effet, tel effet sur telle métrique. Et au bout de 8 semaines, on se reparle, on fait le point et on décide d’exposer 100% de l’utilisateur. Donc ça, c’est les deux grands changements. 

Marc 00:39:25 – 00:39:32 : Et puis si on a suffisamment d’utilisateurs comme Lyft, finalement 5% c’est déjà un volume suffisant pour faire des stats. 

Alexandre 00:39:32 – 00:40:03 : C’est ça. Après, vous avez parfois des expériences qui touchent à un certain aspect de notre expérience utilisateur. Par exemple, quand je travaillais sur les frais d’annulation, Certes, Lyft a de l’échelle, mais les frais d’annulation, ce n’est pas quelque chose que tous les passagers vont nécessairement être exposés à. Vous avez déjà un facteur 10% qui s’applique. Lorsque vous parlez de 95% de 10%, vous êtes déjà sur des échelles un peu plus petites. 

Marc 00:40:03 – 00:40:13 : Lyft Pink, c’est un programme de fidélisation. Est-ce que tu peux nous parler aussi de tes travaux dans le cadre de ce feature ? 

Alexandre 00:40:13 – 00:43:39 : Oui, alors on en a parlé tout à. l’heure. C’est difficile de fidéliser les utilisateurs. Clairement, les choses qui le regardent en premier sont le prix et les ETA. Mais il y a eu depuis globalement 2-3 ans un effort pour faire en sorte que les utilisateurs reviennent plus souvent chez nous. On a créé ce programme LeafPink qui donne des avantages à l’utilisateur moyennant une contribution mensuelle, chose qui est finalement assez fréquente dans d’autres SaaS. On essaie d’avoir un revenu fixe en disant que tous les mois, pensez à Netflix, pensez à Prime, l’idée c’est d’avoir au moins cette base pour vos utilisateurs en contrepartie de certains avantages. Ce qu’on a fait avec Pink, ça reboucle avec ce qu’on disait tout à l’heure, c’est qu’on leur a permis d’avoir, sans frais additionnels, cette rapidité et un accès à ces ETA plus rapides. On a parlé tout à l’heure d’une offre où les voitures arrivaient plus rapidement chez vous ou là où vous faites la requête. Donc pour tous les utilisateurs Pink, c’est vraiment le bénéfice principal, c’est qu’ils ont accès à ça et donc ils gagnent en moyenne entre 2 et 3 minutes pour 0$ incrémental cette offre. Donc on a mesuré, toujours en travaillant de manière très étroite avec des spécialistes d’inférence causale, on a mesuré qu’après l’achat de la subscription à LeafPink, il y avait un effet de fidélisation. C’est pour ça que ça existe toujours. qu’on essaie de convertir au maximum et qu’on fait beaucoup de marketing en interne, c’est-à-dire une fois que les utilisateurs sont déjà chez nous, on essaie de les upsell et on essaie aussi de les acquérir à l’extérieur. Donc on a montré qu’il y avait cette augmentation de la fréquence de course qui avait lieu après le sign-up. La difficulté, c’est que lorsque vous faites au sein du marketplace comme Lyft, vous décidez d’offrir des avantages à certains utilisateurs. Il faut imaginer les externalités négatives qui vont exister pour le reste de vos utilisateurs. Et aujourd’hui, je n’ai pas le chiffre en tête, mais Pink reste une minorité de nos utilisateurs, car tout le monde n’est pas prêt à payer 10 euros, 10 dollars par mois pour s’offrir ce genre de service. Donc, vous savez qu’en disant à tous vos utilisateurs Pink qu’ils auront accès gratuit à cette offre plus rapide, forcément, vous avez des conséquences négatives pour le reste d’utilisateurs. C’est le fast pass Disney. Oui, exactement. Si tout le monde finit par le prendre… D’ailleurs, c’est intéressant parce que ça montre bien que ce bénéfice-là n’est pas pérenne si Ping devient prime pour le ride share. Parce que le jour où… Ou alors, il va falloir travailler la densité du réseau. Mais si 50% de nos utilisateurs décident de sign up pour ce programme… on ne va pas être en mesure d’offrir des ETA plus bas à tout le monde. Donc ça marche bien lorsque vous avez vraiment uniquement un petit sous-groupe, mais sinon il va falloir se réinventer, il va falloir être un peu plus créatif sur le bénéfice. 

Marc 00:43:43 – 00:44:01 : Tu nous as parlé un petit peu des pubs dans l’app Leaf Media. Pourquoi mettre des publicités dans l’app ? Quelles sont les questions sous-jacentes qui ont pu se poser et auxquelles vous avez pu répondre en regardant les données ? 

Alexandre 00:44:01 – 00:52:09 : Tout à fait. Pour répondre à ta première question, pourquoi nous avons décidé de mettre des pubs dans l’app ? Moi, je dirais plutôt que la question, c’est pourquoi nous… Je dirais plutôt que la question, c’est pourquoi nous ne l’avons-nous pas fait avant ? D’accord. J’imagine que… Tu es sans doute familier du fait que Uber et Lyft, historiquement, ont eu du mal à générer des profits. Ce sont deux boîtes cotées et on voit bien que financièrement, il y avait des efforts à faire. Donc mettre de la publicité dans l’app, c’est tout simplement un moyen de générer des revenus supplémentaires et de permettre de bénéficier encore mieux de nos effets d’échelle. Donc c’était tout simplement une raison financière. Et c’est aussi assez commun finalement dans beaucoup de services qui existent aujourd’hui. Le principal frein au ride share, c’est le prix. Comment on fait pour rendre ce service plus abordable ? Ça nous permet, un, sur toutes les courses qui existent déjà, d’augmenter nos marges. Et dans la vision un peu long terme, ça peut aussi faire office de subvention à cette commodité. On n’y est pas encore, puisque aujourd’hui, c’est une business unit qui a un an et demi. Mais dans la vision de long terme, c’est un peu comme ça qu’on l’envisage. Quelles ont été les questions qui se sont posées ? La première question qui s’est posée, c’est « Vous ajoutez de la friction dans un flot qui a déjà beaucoup d’informations. L’objectif principal de l’utilisateur n’est pas d’être exposé à du contenu marketing, à des publicités. ». Le premier écueil que nous avons essayé d’éviter, c’est le syndrome de « j’ouvre une page web et je vois de la publicité partout, je n’arrive pas à trouver mon information, donc je la quitte ». Ça, ça a été le premier risque qu’on s’est efforcé d’éviter. Pour ça, on a, comme souvent, et cette fois je pense que c’était justifié, réalisé des expériences où on a introduit de la publicité à plusieurs endroits du flot et on a essayé de mesurer quel était l’impact sur nos métriques business, donc la capacité des utilisateurs à regarder le prix et à convertir cette demande en une course. le nombre de courses qui étaient effectuées au total et de faire en sorte qu’on ne dégradait pas nos métriques business. Donc ça c’est la première chose qui s’est posée. Il y a un framework intéressant qu’on a utilisé. Donc je parlais tout à l’heure de le data scientist quand il prend peu de décisions et qu’elles sont importantes, il va faire appel aux stats. Là, clairement, il y avait probablement un trade-off qui allait se poser, car c’est sûr qu’introduire de la publicité, ça ne plaît pas à tout le monde. Il y a peut-être des utilisateurs qui vont décider de ne pas faire appel à nos services. Donc, on allait devoir concilier ces deux objectifs. On avait une idée plus ou moins globale de combien allait nous rapporter l’aspect média en termes de revenus. Donc on s’est fixé une marge de manœuvre sur combien nous étions prêts à perdre en termes de courses, en termes de revenus générés via les courses. Et donc on peut décider de cette marge comme un pourcentage et on peut utiliser un test statistique qui, au lieu de mesurer est-ce qu’une métrique a bougé ou pas ? on mesure ce qu’on appelle la non-infériorité. Ce test-là, quand il rejette l’hypothèse nulle de non-infériorité, on sait qu’on n’a pas dégradé la métrique business de plus de x%. et ce x% avait été choisi de manière très scientifique et il correspond exactement à un ordre de grandeur qui était ce que nous on pouvait générer avec le revenu. donc ça c’est un preneur qu’on utilise souvent lorsqu’on prend des décisions importantes et qu’on a probablement un trade-off qui va se poser. Ça, ça a été le premier grand axe. Le deuxième grand axe sur lequel on travaille activement, c’est l’aspect ciblage. À qui montrer les publicités ? C’est une des grandes choses que les agences et les entreprises cherchent quand elles dépensent de l’argent sur leur budget. marketing, c’est à qui je vais montrer mon contenu. Lyft est intéressant pour eux parce qu’on a des données qu’on appelle « first party », qui sont les données de Lyft, qui sont intéressantes avec notamment les données de localisation, c’est-à-dire probablement on peut savoir où est-ce que vous habitez, on peut savoir où est-ce que vous travaillez, quels sont vos patterns de déplacement, est-ce que vous bougez toute la semaine, vous allez au bureau, est-ce que le week-end vous êtes plutôt du genre à rester chez vous ? On a des données qui sont assez intéressantes et qui sont physiques, qui sont assez différentes finalement des cookies et de toutes ces choses qui étaient collectées sur le web et sur les smartphones. Mais ça ne suffit pas. Clairement, avec ces données-là, on ne construit pas une image parfaite de nos utilisateurs et ça ne suffit pas pour les agences et les entreprises en termes de ciblage. Donc, on est obligé de faire appel à des entreprises qui, elles, vendent des données qu’on appelle third party et qui, celles-ci, sont souvent parcellaires parce qu’elles sont construites souvent à partir de machine learning. Comme tout modèle, ce ne sont pas des prédictions parfaites. Il y a une marge d’erreur évidente. Et ensuite, il faut réconcilier ces données et faire partie avec nos utilisateurs à nous. Donc, vous n’avez pas forcément un match sur le dataset que vous avez acheté. Et peut-être aussi que sur le dataset que vous avez acheté, telle colonne est vide pour tel utilisateur, mais une autre colonne ne l’est pas. Donc, quand vous mettez tous ces facteurs bout à bout, ça ne permet pas de répondre à tous les besoins des agences et des entreprises qui souhaitent faire de la pub sur Lyft. Donc là, il faut être assez créatif pour essayer finalement de remplir cette matrice avec vos utilisateurs et vos différentes colonnes en fonction du cas d’usage. Il y a un cas d’usage qui est intéressant, quelque chose qui est assez en boum aux États-Unis maintenant, et on peut débattre de si c’est bien ou pas, c’est les paris sportifs. Les paris sportifs, ils matraquent le budget marketing. Mais il y a beaucoup de contraintes légales. C’est-à-dire qu’on ne peut pas montrer ce genre de contenu à des mineurs. Ils ont des états sur lesquels ils sont très spécifiques. Alors pour nous, les états, c’est facile puisqu’on sait où les gens sont. Donc on peut facilement dire oui ou non. Mais pour l’âge, ce n’est pas simple. Pour l’âge, ce n’est pas simple parce que lorsque l’utilisateur décide de créer un compte Lyft, on ne demande pas l’âge. Donc on a besoin d’avoir avec une grande certitude si les gens sont des majeurs ou pas. Majeur aux Etats-Unis, c’est 21 ans. Et on n’a pas forcément de bonne heuristique pour déterminer ça. Donc ce qu’on a fait, et alors ce n’est pas du tout compliqué en termes de… Il n’y a pas de machine learning, c’est purement une règle. Mais on a pris tous nos utilisateurs et on a vu ceux qui étaient sur la plateforme depuis plus de 5 ans. On a choisi 5 ans parce que pour utiliser Lyft, il faut avoir 16 ans. C’est dans les conditions générales d’utilisation. Vous ne pouvez pas avoir de personnes plus jeunes que ça. Donc, s’ils ont signé… S’ils ont… S’ils ont créé un compte Lyft il y a plus de 5 ans, à priori, ils ont plus de 21 ans. Et on utilise ça, et ça nous permet de passer d’un ciblage qui était assez parcellaire, parce que quand on achète ça à des third parties, on a 10-20% de notre base d’utilisateurs qui est couverte. Avec ces touristiques, on triple ou on quadruple. Donc c’est extrêmement peu compliqué en termes de data science. Mais ça a un impact énorme. Ça a un impact énorme parce que ça permet de débloquer des budgets immenses. Et toute notre équipe sales qui était contrainte par des idées d’inventaire, d’un coup, elle peut signer beaucoup plus de contrats. 

Marc 00:52:09 – 00:52:15 : Qu’est-ce que l’IA générative a changé pour vous ? 

Alexandre 00:52:15 – 00:54:20 : Elle a changé… Elle a changé d’abord la productivité du travail. Si je réfléchis à comment j’utilise l’IA générative au travail aujourd’hui, dans mon quotidien, c’est des intégrations avec Slack, donc des fonctionnalités assez intéressantes comme, par exemple, chercher dans l’historique d’une vieille channel Slack. Vous savez quelque chose à y discuter, vous ne savez plus où. résumer des longues. donc il y a le concept des threads. résumer une longue thread pour savoir ce qui s’est dit et quel était le point de vue des différentes parties prenantes ça c’est intégré à Slack. c’est intégré à Slack. en fait on a une équipe j’aurais pu le mentionner tout à l’heure sur la partie comment on s’organise. l’équipe data. on a une équipe ML Platform qui s’occupe d’offrir des fonctionnalités ML, à la fois pour le développement en cloud d’algorithmes pour les assassinatistes, mais aussi, notamment depuis que OpenAI a un peu explosé, fait en sorte qu’on ait accès de manière facile et sans friction à l’IA générative. On a un proxy d’OpenAI qui est intégré à Slack et qui a ces fonctionnalités. Utilage de Slack, première chose. Grande base de données gigantesque sur Lyft avec différents assistants qui fonctionnent avec des rags et qui ont des connaissances assez spécifiques sur plusieurs sujets. Ça peut être par exemple sur le sujet des compensations chauffeurs. Donc là, ils ont été nourris et ils ont accès à tout ce corpus documentaire et vous pouvez appeler un assistant spécialiste de ça. Un autre exemple qui est assez intéressant, c’est pour tout ce qui est revue de performance, écrire les revues de vos collègues, etc., pour qu’ensuite leur notation soit faite, etc. Là, on avait créé des assistants qui sont spécialistes des compétences à tous les niveaux, selon certaines fonctions et certaines organisations. 

Marc 00:54:20 – 00:54:23 : Avec quels outils ? 

Alexandre 00:54:23 – 00:54:25 : Là, c’était aussi OpenAI. 

Marc 00:54:25 – 00:54:36 : C’est du pur développement sur du OpenAI. Pas d’outils comme Slack, par exemple. C’était l’outil de Slack. Là, ici, on parle vraiment de développement spécifique interne à Lyft. 

Alexandre 00:54:36 – 00:54:52 : L’outil de Slack, ce n’était pas celui de Slack. En fait, il a intégré un chatbot sur Slack, mais c’est notre équipe qui développe un proxy d’OpenAI. Donc, il n’y a pas de problème d’authentification, etc. Mais je ne pense pas que ce soit le bot de Slack. 

Marc 00:54:52 – 00:54:54 : D’accord, c’est que des outils internes. 

Alexandre 00:54:54 – 00:57:56 : c’est que les outils internes et donc en l’occurrence pour cette idée de revue de performance etc. c’est pareil un proxy d’OpenAI qui est nourri avec du coup un corpus de documents qui sont les compétences requises à tous les niveaux pour toutes les fonctions. et ça nous a fait gagner un temps fou. Sur le dernier cycle, nous, tous les ans, on écrit nos propres revues de performances et celles des collègues avec qui nous avons travaillé de manière assez proche. Et ça a permis de gagner un temps fou, quelque chose qui prend d’habitude de nombreuses heures. Et c’est très engageant en termes de temps. Là, on a pas mal accéléré. Mais bon, tout ça, c’est finalement autour de notre travail et donc productivité du travail. En tant que data scientist, ça m’a permis de gagner du temps sur certaines tâches un peu répétitives de SQL. Il y a toujours dans votre portefeuille de mission ces 5-10% de petites questions ad hoc qui viennent d’une partie prenante. Et parfois, vous n’avez pas forcément la query, elle n’est pas forcément accessible facilement. Mais vous savez vaguement quelle est la table et quel est le field. Donc là, on commence à avoir quelque chose qui ne fonctionne pas trop mal pour faire du text-to-sequel. Et là, pareil, ça peut marcher très bien avec directement l’interface OpenAI que nous avons sur Slack. Ça va appeler un assistant spécifique et ça va m’ouvrir une fenêtre sur laquelle j’aurais pu, par exemple, sur Presto, avec la version SQL de ma question au langage naturel. Donc là-dessus, on gagne pas mal de temps. Enfin, tout ça, c’est productivité du travail. En termes de produits, il y a deux cas d’usage qui ont été mis en place et on en travaille sur d’autres. Le premier que nous avons mis en place, c’est tout ce qui est détection de fraude, phishing. Il y a pas mal de communications qui ont lieu entre notre centre Lyft, entre le serveur et les populations de chauffeurs et de passagers, avec des notifications, des SMS. Donc là, il y a pas mal de phishing. Je sais qu’on a intégré l’IA générative ici. Le deuxième cas d’usage, c’est tout ce qui est traduction des différents contenus sur nos applications. Sur notre population de chauffeurs notamment, aux États-Unis, il y a une grande proportion de chauffeurs qui sont d’origine hispanique ou qui parlent espagnol, donc c’est la première langue. Donc toute notre application doit être compatible avec l’espagnol. Et il faut imaginer que lorsque vous lancez un nouveau feature, il faut que tous les strings, tous les docs, toute la partie texte soit traduite. 

Marc 00:57:56 – 00:57:57 : Oui. 

Alexandre 00:57:57 – 00:59:25 : Avant, on faisait appel à une équipe de traducteurs. C’était extrêmement long comme process. Il fallait une semaine pour que votre pull request soit validé et puisse être déployé. Et là, on a intégré l’IA générative pour faciliter ce process. J’imagine qu’il y a des contraintes sur la longueur, la complexité, mais ça nous permet d’automatiser et d’aller beaucoup plus vite sur ce genre de choses. Et le dernier cas d’usage sur lequel on travaille, mais qui n’est pas déployé à ma connaissance aujourd’hui, ça va être tout ce qui est interaction avec le support. Il y a beaucoup de requêtes. On a parlé des frais d’annulation tout à l’heure. Ça génère beaucoup de requêtes au support, que ce soit côté chauffeur, côté passager. Aujourd’hui, on avait des petits bots qui fonctionnaient avec des règles très simples, mais qui ne répondaient pas du tout aux besoins de nos utilisateurs. Donc là, il va y avoir quelque chose d’assez puissant à faire sur comment gérer ces interactions. Je pense même à quelque chose de probablement un peu plus long terme, mais… il y a une volonté de la part des utilisateurs d’avoir quelqu’un au bout du fil. Ça, c’est vrai probablement pour tous les centres d’appel, etc. Mais on voit déjà ce qu’on est capable de faire avec l’IA générative pour les voix. Donc, j’imagine que ça peut être une opportunité pour nous de créer un service support avec la possibilité pour les chauffeurs qui aiment bien avoir quelqu’un au bout du fil, plutôt que de les rediriger toujours vers un chatbot ou quelque chose qui est plus texte. 

Marc 00:59:32 – 00:59:41 : Quel invité aimerais-tu entendre sur le micro de Data Driven 101 dans un prochain épisode ? 

Alexandre 00:59:41 – 01:00:03 : Alors, je ne sais pas en termes d’invités, mais on parle pas mal de Nabla en ce moment. Puisque tu parlais d’IA générative, j’ai l’impression qu’ils ont pas mal de traction sur leurs produits avec les médecins et comment on automatise les tâches, etc. Et on fait en sorte que les médecins se focalisent sur ce qu’il y a pour de la valeur ajoutée. Donc, je ne sais pas si vous avez déjà reçu quelqu’un… 

Marc 01:00:04 – 01:00:08 : Non, je suis Samuel Humeau de chez Nabla, donc tu es servi. 

Alexandre 01:00:08 – 01:00:14 : Je suis servi, d’accord. 

Marc 01:00:15 – 01:00:32 : Merci Alexandre. Merci Marc. Vous venez d’entendre Alexandre Sayar, Product Manager chez Lyft. Dans le prochain épisode, je recevrai Alexandre Sayar, Data Scientist puis Product Manager chez Lyft pour nous parler de data et d’IA appliquées au domaine des VTC. Je vais la refaire parce que je n’ai pas mis de pause. 

Alexandre 01:00:32 – 01:00:34 : Tu peux dire Data Scientist, je pense. 

Marc 01:00:35 – 01:01:07 : Vous venez d’entendre Alexandre Sayar, Data Scientist chez Lyft. Dans le prochain épisode, je recevrai Alexandre Sayar, Data Scientist chez Lyft pour nous parler de data et d’IA appliquées au domaine des VTC. A très vite ! Top. On a pas mal débordé, mais c’était hyper intéressant. 

Alexandre 01:01:07 – 01:01:13 : Je suis désolé, j’avais l’impression d’être super long. Non, non, mais on a creusé, donc c’est…