Hugo : Ben, bienvenue dans DataFramed.
Ben : Merci, Hugo, je suis ravi d’être là et j’ai hâte d’échanger avec vous aujourd’hui sur Convoy et la data science.
Hugo : Tout à fait. C’est un plaisir de vous recevoir et, dans notre exploration continue sur DataFramed de ce qu’est la data science et de ce qu’elle peut devenir, je suis très enthousiaste à l’idée de parler aujourd’hui de votre travail chez Convoy et du rôle que la data science peut jouer pour transformer en profondeur le transport routier, sans doute l’un des secteurs les plus structurants en Amérique du Nord. Mais d’abord, parlons de vous.
Ben : Avec plaisir, merci.
Qu’est-ce qu’un data scientist ?
Hugo : On me demande souvent ce que font réellement les data scientists. Ben, vos collègues pensent que vous faites quoi, exactement ?
Ben : Excellente question. Le terme « data scientist » est assez flou. Il veut dire des choses différentes selon les personnes. Je viens à la data science avec un double bagage en sciences naturelles et en sciences sociales. J’ai aussi fait un détour par la Silicon Valley avant de faire un doctorat en économie. Concrètement, je passe une moitié de mes journées en réunion à parler de la science qui sous-tend notre plateforme, de notre approche de la data science ici, ou de sujets précis comme la conception d’expériences. Je consacre environ la moitié de mon temps au mentorat d’autres data scientists : aider un profil junior à concevoir une expérience pour une campagne ou, par exemple, construire un modèle de survie pour analyser la rétention client.
Puis je passe une autre « moitié » de mon temps en contribution individuelle, à réfléchir aux leviers qui pilotent notre plateforme et à essayer d’avoir de l’impact en éteignant l’incendie du moment. Donc, des sujets comme les enchères, le matching, la tarification, ce genre de choses. Toute personne sachant compter remarquera que cela fait trois moitiés, mais je travaille dans une startup, alors les sommes ne font pas toujours 1.
Hugo : Je ne peux qu’approuver. Chez DataCamp, j’ai parfois l’impression de fonctionner comme une somme infinie, en fait. Et comme votre formation est en physique, vous m’avez dit qu’il n’y a que trois nombres pour un physicien, n’est-ce pas ?
Ben : Exact. Il y a zéro, un et l’infini, et tout le reste n’est qu’une question d’échelle. C’est la vieille blague.
La carrière de Ben en data science
Hugo : Exactement. Alors, comment êtes-vous entré dans la data science ?
Ben : Très bonne question. Je crois que j’ai toujours travaillé avec des logiciels, des données, des maths, des stats et des modèles, et après que DJ Patil a popularisé le terme, quelqu’un au marketing m’a « rebrandé » en data scientist. Mais même à l’université, je codais déjà pour répondre à des questions scientifiques. Ma première « expérience » data, c’était un programme pour étudier la relaxation des cratères pour McKinnon, un planétologue remarquable à Washington University. Le groupe Frankie était très connu là-bas et, comme je traitais de relaxation de cratères, j’ai appelé mon programme Frankie. Plus récemment, après ma thèse, j’étais à l’Université de Chicago et on m’a recruté chez Amazon. C’était vers 2012. À ce moment-là, j’ai vraiment opéré la transition entre le monde académique et l’application en entreprise.
Hugo : Et aujourd’hui vous êtes data scientist chez Convoy ?
Ben : Oui.
Convoy
Hugo : Dites-nous ce que fait Convoy et quelle est sa mission.
Ben : C’est un bon exemple de la facilité avec laquelle un logiciel peut transformer un secteur établi, bien plus que l’inverse. Le fret existe depuis longtemps. Aux États‑Unis, c’est un marché énorme, environ 800 milliards de dollars. Le problème, c’est que la plupart des transporteurs sont très fragmentés. Pardon, je parle des carriers, c’est‑à‑dire les entreprises de transport routier, qui possèdent un ou plusieurs camions. Le secteur est ultra fragmenté : au 95e centile, un transporteur a deux ou trois camions. Les chargeurs, eux, se connectent à eux via des courtiers, qui opèrent encore avec une technologie des années 1980 : téléphone et fax. Chez Convoy, nous ouvrons la voie du « digital freight », en utilisant la technologie et, en particulier, la data science pour améliorer le processus pour tout le monde. Il est crucial d’associer le bon transporteur au bon chargement : quand c’est le cas, tout fonctionne mieux. Il faut donc tarifer, faire le matching et automatiser l’ensemble, ce qui change radicalement la structure de coûts du secteur. Et pour vous toutes et tous qui nous écoutez et êtes aussi consommateurs, la plupart des produits que vous achetez effectuent huit à dix trajets en camion avant d’arriver jusqu’à vous. Si nous réduisons le coût du fret, les prix des biens devraient devenir bien plus compétitifs.
Hugo : Concrètement, pour les… vous disiez que les carriers sont les conducteurs ?
Ben : Les carriers… La définition est un peu complexe, car beaucoup sont des owner-operators, une incarnation du rêve américain. Par exemple, ici dans le Nord‑Ouest Pacifique, cela peut être un immigrant russe arrivé sans rien, qui devient propriétaire‑exploitant d’un camion, puis, en réussissant, développe sa flotte. C’est précisément ce que Convoy veut aider ces propriétaires‑exploitants à faire. Cela peut aussi être une entreprise de transport de taille moyenne. Typiquement, ils ont un ou plusieurs camions. Il est difficile pour un individu de dépasser 20 camions, car la logistique se complique, avec des sujets RH, etc.
Hugo : Bien sûr. Et à quoi ressemble Convoy au quotidien pour ces transporteurs ? Utilisent‑ils des applications ou…
Ben : Oui, excellente question. Leur principal point de contact est l’application Convoy. Notre processus d’onboarding leur permet de nous transmettre très facilement leur dossier d’informations : assurance, licences, etc., afin d’activer leur compte. Ensuite, ils voient des offres adaptées aux types de trajets qu’ils nous indiquent préférer. Ils peuvent dire : « Je circule surtout sur le corridor I‑5 », et accepter ces chargements dans l’app, sans jamais avoir à parler à un humain. C’est ultra efficace.
Ils peuvent aussi enchérir sur des chargements. S’ils n’aiment pas notre prix, ou s’ils sont en concurrence avec d’autres pour un trajet, ils peuvent proposer une enchère, le prix montant ou baissant selon les conditions de marché. Autre point précieux : s’ils prennent une course de San Francisco à Los Angeles, et que nous le constatons, nous allons leur dire : « Nous avons un retour de Los Angeles vers votre point d’origine ou une autre destination ». L’idée est de les garder en mouvement et en revenus, pour réduire les trajets à vide. Car, en moyenne, les camions roulent à vide environ 40 % du temps, ce qui est mauvais pour l’environnement et pour les conducteurs.
Hugo : J’imagine que vous avez toute une série de problèmes du type « voyageur de commerce » à résoudre : on veut éviter qu’un chauffeur fasse Seattle–Bay Area à vide juste pour charger ailleurs. L’objectif est d’optimiser le trajet selon le taux de chargement, n’est‑ce pas ?
Ben : Absolument. Plus la plateforme gagne en liquidité, plus il devient facile de résoudre ce type de problèmes et de maintenir les transporteurs en quasi‑mouvement permanent.
Hugo : C’est très impressionnant. Une des raisons pour lesquelles je trouve cela si intéressant, c’est que, lorsqu’on pense au rôle de la data science dans l’industrie moderne, on pense souvent à la tech, un secteur né avec la montée des données. Vous, vous parlez de transformer un secteur bien antérieur à toute cette infrastructure technologique.
Ben : Tout à fait. Et si nous réussissons, nous allons changer la structure de coûts d’un grand secteur qui touche énormément d’Américains. Un fait marquant que j’ai appris chez Convoy : dans quelque chose comme 45 États, le métier le plus répandu, c’est conducteur routier. Cela concerne donc beaucoup de personnes en emploi, et touche aussi tous les consommateurs. L’impact peut être très positif, notamment pour les conducteurs : nous leur facilitons la gestion et la croissance de leur entreprise, avec beaucoup moins de frictions au quotidien.
La data science chez Convoy
Hugo : Très bien. Alors, comment la data science joue‑t‑elle un rôle clé dans la mission de Convoy ?
Ben : La data science est au cœur de tout ce que nous faisons. Depuis le premier jour, nous automatisons. Nous devons résoudre une foule de problèmes passionnants, avec beaucoup d’économie appliquée. Il est essentiel de prédire correctement les prix, car nous devons tarifer au juste coût pour les chargeurs, souvent via des contrats long terme, et aussi pour les transporteurs. Puis, nous devons résoudre le problème de l’appariement, pour associer le bon transporteur au bon chargement, ce qui maximise les résultats pour tous. Par exemple, « bon » peut vouloir dire moins de distance à vide (le trajet pour rejoindre le point de départ), ou de meilleures combinaisons d’origines et de destinations. Nous travaillons sur les enchères, les mécanismes d’acceptation de prix côté transporteurs, et sur de nombreux aspects de leur cycle de vie, jusqu’à s’assurer que tout se passe bien une fois le chargement pris. Il y a un vaste éventail de problèmes de ce type.
Hugo : On imagine un vrai problème « l’œuf et la poule » : pour convaincre les chargeurs, il faut des transporteurs, et pour convaincre les transporteurs, il faut des chargeurs.
Ben : Oui, c’est difficile pour toute plateforme. Il y a un excellent article de Simon Rothman, l’un de nos investisseurs depuis la série A, qui explique qu’il faut en quelque sorte lancer deux entreprises en même temps : amorcer l’offre et la demande simultanément, et garder l’équilibre.
Heureusement, nous avons une équipe commerciale remarquable, très forte pour générer une demande de qualité. Ensuite, nous développons vite l’offre afin de rester en équilibre, ce que nous suivons de près. Comme toute plateforme, nous pensons en termes de liquidité et d’équilibre. C’est comme un site de rencontre : si vous êtes hétérosexuel et qu’il n’y a pas de femmes, l’expérience sera mauvaise. Il faut des volumes comparables côté hommes et femmes.
Hugo : J’y pense car nous avons eu un défi comparable chez DataCamp au début : attirer des apprenants tout en recrutant des formateurs. Les formateurs veulent une audience, et les apprenants veulent les meilleurs formateurs, n’est‑ce pas ?
Ben : Exactement. Autre point : il y a des effets de réseau. Une fois lancées, ces activités ont tendance à croître exponentiellement. C’est grisant… et cela veut dire que si vous faites bien, vous ne dormez plus beaucoup.
Hugo : Tout à fait. Vous m’avez dit qu’un des leviers majeurs est une équipe commerciale solide. Comment l’équipe data science est‑elle intégrée à l’entreprise, notamment vis‑à‑vis des ventes ?
Ben : L’une de nos grandes contributions est d’aider à comprendre la tarification : comment enchérir sur des chargements, lesquels cibler, etc. La tarification est incroyablement complexe, avec toutes sortes d’incitations. On pourrait en parler des heures.
Hugo : Nous avons tourné autour du rôle de la data science. Quelles questions data précises devez‑vous traiter dans votre travail ?
Ben : Une des forces de Convoy, c’est notre culture très basée sur les données. Nous menons énormément d’expérimentations, comme tous les acteurs de pointe, je suppose. Bien souvent, la seule manière de répondre à une question, c’est l’expérimentation. Nous avons donc beaucoup investi dans un cadre robuste qui nous permet d’itérer rapidement. Il existe différentes approches pour l’A/B test, bayésienne ou fréquentiste ; l’approche bayésienne ou l’analyse séquentielle permettent d’arriver plus vite à une conclusion, et de discuter plus facilement des résultats avec les product managers.
A/B testing
Hugo : Revenons un instant en arrière. Pouvez‑vous donner un exemple d’A/B test que vous menez ?
Ben : Typiquement, on teste si un nouveau parcours UX fonctionne mieux. Par exemple, l’un de nos enjeux est que, lorsqu’un conducteur termine un trajet, il télécharge automatiquement ses documents, ce qu’on appelle le BOL, bill of lading. Si nous lançons un nouveau processus pour faciliter cela, nous pouvons mener une expérience en laissant la moitié des transporteurs sur l’ancien flux et l’autre moitié sur le nouveau. Après un certain temps, nous pouvons dire, avec une probabilité donnée, si le nouveau processus est meilleur.
Hugo : Très bon exemple et belle description de l’A/B test. Vous avez mentionné que les méthodes bayésiennes convergent plus vite ou donnent des résultats plus rapidement que les méthodes fréquentistes. Pourriez‑vous, pour le grand public, expliquer brièvement la différence entre les statistiques fréquentistes, plus connues, et l’approche bayésienne que vous évoquez ?
Ben : Bien sûr. Historiquement, la première approche, c’est la méthode bayésienne, développée par Thomas Bayes, qui était pasteur. Son idée correspond assez à notre intuition : on part d’un a priori sur quelque chose — par exemple : « mon nouveau processus est meilleur, il apporte 10 % de lift » — puis on met à jour cette croyance à mesure que l’on observe des données. Cette mise à jour bayésienne converge vers ce qu’on appelle la postérieure, qui est la distribution attendue du lift.
La vision fréquentiste… Avant cela, les méthodes bayésiennes étaient très dures à calculer jusqu’à il y a une vingtaine d’années, faute de puissance de calcul. Depuis, d’énormes progrès ont été réalisés, ce qui facilite grandement leur mise en œuvre. Avant, on ne pouvait résoudre que des cas particuliers. Des figures comme R.A. Fisher ont été très critiques du bayésianisme et ont développé l’approche fréquentiste au début du XXe siècle. L’idée y est qu’il existe une vraie valeur du paramètre, et qu’en échantillonnant suffisamment, on converge vers la vérité.
Les fréquentistes parlent de p‑values et d’intervalles de confiance : c’est le test d’hypothèse classique. Dans ce cadre, vous devez dire à un responsable marketing : « Sous l’hypothèse nulle, la probabilité d’observer un effet au moins aussi grand que celui mesuré est de 5,7 % ». Et là commence le débat, car on prend traditionnellement 5 % comme seuil de significativité. Dans ce cas, si vous êtes rigoureux, vous ne pouvez pas rejeter l’hypothèse nulle. Mais votre responsable dira peut‑être : « 5,7 %, c’est proche de 5 %, et si on prenait 10 % ? » Et vous voilà dans une impasse. Alors qu’en bayésien, vous pouvez dire au PM : « Il y a 94,3 % ou 98 % de chances que la variante A soit meilleure que B ». La discussion est plus simple.
Hugo : Dans votre exemple de variantes A et B, le paramètre regardé serait le pourcentage de personnes qui téléversent correctement toute leur paperasse ?
Ben : Exact.
Hugo : En fonction de l’UX proposée.
Ben : Oui. Quel que soit l’indicateur : taux de clics, finalisation d’achat, baisse du churn… L’approche bayésienne facilite vraiment les échanges avec les PM. Et, dans nos simulations, elle converge plus vite. Pour notre activité. Vos résultats peuvent varier, et en Europe vos kilomètres peuvent varier.
Hugo : Il me semble que Dave Robinson a écrit plusieurs billets pour Stack Overflow sur l’A/B testing bayésien, montrant que, pour leurs expériences, cela ne convergait pas forcément plus vite. À vérifier, nous mettrons cela dans les notes.
Ben : Oui. Evan Miller a aussi d’excellents billets sur le sujet.
Autres méthodes de data science : économétrie et machine learning
Hugo : Vous avez mentionné la conception expérimentale. C’est intéressant, car peu s’attendraient à ce que ces méthodes jouent un rôle clé pour réinventer le transport routier par la data. Quelles autres techniques utilisez‑vous ?
Ben : Avant de passer à la suite, un dernier mot sur l’A/B test : le secteur du transport routier recèle beaucoup de savoir empirique. Notre entreprise est à moitié une startup tech, à moitié une équipe de vétérans du secteur, avec une intuition précieuse — mais pas toujours exacte. L’expérimentation permet de trancher et d’objectiver.
Hugo : Il y a aussi un volet politique et social : des personnes en place de longue date, avec pouvoir et expertise, et la perception que des startups tech viennent « disrupter » tout cela. Faut‑il adapter les comportements ?
Ben : Je ne peux parler que de la culture Convoy : elle est très collective, comme dans une bonne équipe de hockey. Chacun reconnaît la valeur de l’autre. Deux vétérans du secteur peuvent d’ailleurs être en désaccord. Chez Convoy, si un débat ne peut être tranché par la théorie ou les faits, on lance une expérience, au lieu de tourner en rond.
Hugo : Quoi d’autre, côté méthodes ?
Ben : Nous faisons de la data science appliquée, très orientée business, avec des horizons courts. Nous utilisons la boîte à outils standard et restons agnostiques sur les technologies : R ou Python selon le besoin, chacun ayant ses atouts, mieux vaut connaître les deux. Côté approches, le machine learning est souvent adapté, notamment pour la prédiction : prédire si quelqu’un va téléverser un BOL, ou si un transporteur sera fiable. On peut construire une régression logistique ou un classifieur boosté. D’autres fois, il faut savoir si A a causé B, alors qu’on n’a pas pu expérimenter. On revient à la statistique appliquée : analyses de régression, etc. Mon premier « gros » succès chez Convoy : avant mon arrivée, une fonctionnalité avait été lancée sans A/B test. On voulait savoir si elle avait aidé. J’ai utilisé le package CausalImpact de Google, fondé sur des séries temporelles structurelles bayésiennes, et montré que la nouvelle fonctionnalité avait eu un impact positif.
Hugo : Super. Et cela sur des données déjà collectées ?
Ben : Oui. Nous avions des données existantes et il faut alors s’assurer que l’assignation est « aussi bonne que » aléatoire, autant que possible. Dans une expérience, il faut de l’assignation aléatoire au traitement, mais aussi des conditions comme l’individualisation, la probabilisation et l’absence de confusion. Si tout cela échoue, on est en observationnel et on utilise des méthodes statistiques appliquées ou économétriques pour se rapprocher d’une assignation aléatoire, afin de pouvoir faire des inférences causales.
Hugo : Rappelez‑nous ce qu’est l’économétrie.
Ben : C’est l’ensemble des outils statistiques développés par les économistes pour les problèmes économiques. En entreprise, ils sont très utiles, car nos problèmes sont souvent économiques. Un exemple classique : la sélection d’échantillon et d’autres formes d’endogénéité, quand les variables se déterminent mutuellement. Par exemple, pour savoir si augmenter la taille de la police réduit la criminalité : la criminalité dépend du nombre de policiers, mais l’effectif de police dépend aussi du niveau de criminalité. C’est la simultanéité. La sélection d’échantillon, une fois qu’on la voit, on la voit partout. Par exemple, tester l’effet de la petite taille des classes sur la lecture, mais si les parents les plus aisés imposent la petite classe à leurs enfants, ces derniers sont en moyenne plus favorisés, et vous avez un biais de sélection.
Hugo : Et l’économétrie a créé des outils pour gérer ces défis ?
Ben : Oui. En particulier, un ensemble d’outils bien connus des économistes mais moins des data scientists : les données de panel. Ces méthodes gèrent très bien ce que les économistes appellent l’hétérogénéité individuelle. Si j’observe des transporteurs ou des expéditions, chacun a des spécificités non observées. Si je peux observer un transporteur dans le temps, les modèles de panel me donnent d’excellentes méthodes pour purger ces effets individuels non observés qui pourraient biaiser mes estimations.
Hugo : Si je comprends bien, il existe tout un arsenal développé en économétrie, souvent ignoré en data science, alors qu’il pourrait être très utile ?
Ben : Exact. J’adore le machine learning, mais il y a des cas où il ne marche pas. On se focalise parfois trop dessus en négligeant des méthodes économétriques très utiles, capables de résoudre des problèmes que le ML ne sait pas adresser. Quelqu’un chez Uber me disait, avant que je rejoigne Convoy, qu’ils avaient rencontré des problèmes insolubles par ML, mais résolus via un modèle économétrique structurel. C’est complexe, cela prend souvent un an ou plus pour bâtir un tel modèle et le stabiliser. On modélise le processus de décision et la fonction d’utilité, et au final on peut faire de bonnes prédictions contrefactuelles.
Hugo : C’était chez Uber ?
Ben : Oui. C’est ressorti lors de mon entretien avec eux, avant que je parte chez Convoy.
Données géospatiales, qualité et camions autonomes
Hugo : Nous avons parlé de machine learning, d’économétrie, d’expérimentation et de bayésien. Vous semblez aussi avoir beaucoup de données géographiques, voire des séries temporelles géospatiales. Est‑ce important dans vos travaux ?
Ben : Oui. Ces données sont cruciales, et nous commençons à peine à en exploiter tout le potentiel. Nous les utilisons déjà dans l’app pour améliorer l’expérience des transporteurs. Par exemple, lorsqu’un transporteur arrive pour prendre un chargement, nous pouvons l’enregistrer automatiquement via la géolocalisation. Certains sites de chargement sont mal organisés et, s’ils font attendre le camion trop longtemps, ils doivent payer des frais de « detention ». Nous pouvons déclencher ces paiements automatiquement dès que le transporteur est éligible, sans paperasse fastidieuse — un peu comme un dossier d’assurance aux États‑Unis.
Hugo : Quand vous dites que vous avez encore beaucoup à explorer, on imagine un fort potentiel de recherche sociale autour de ces données, non ?
Ben : Oui. Il y a beaucoup de questions passionnantes sur le matching, les plateformes, les enchères. J’aimerais creuser. Je suis sûr qu’on pourrait écrire de nombreux articles académiques sur le sujet.
Hugo : Parmi vos projets data chez Convoy, lesquels vous semblent les plus impactants pour la société ou les plus révélateurs ?
Ben : Bonne question. Je suis chez Convoy depuis un peu plus d’un an et l’entreprise a un peu plus de deux ans. Je me suis surtout concentré sur la tarification et l’expérimentation. L’une des expériences les plus intéressantes, peu après mon arrivée : nous avons donné un accès prioritaire aux chargements aux transporteurs de plus haute qualité… et la qualité a baissé. Stupeur : « On favorise les meilleurs et la qualité diminue ? » Un mauvais manager dirait : « Le data scientist est nul ». Heureusement, notre head of data science, Ziad Ismail, a bâti une excellente culture data. Il nous a laissé investiguer. Je me suis tourné vers la littérature économique sur le matching. Mon hypothèse : en restreignant le vivier à un sous‑ensemble, même meilleur, la qualité d’appariement a baissé. Nous l’avons vérifié, puis montré par régression que la qualité du matching avait un impact causal sur la qualité. Découverte enthousiasmante qui souligne l’importance du matching sur notre plateforme.
Hugo : Pour clarifier : en donnant un accès anticipé aux meilleurs transporteurs, la qualité de l’appariement avec les chargeurs s’est dégradée, ce qui a entraîné une baisse de la qualité globale ?
Ben : Oui. La qualité d’exécution a chuté parce que le vivier éligible était plus restreint. Même meilleur, il offrait moins de combinaisons possibles, et cet effet a primé sur la qualité intrinsèque des transporteurs.
Hugo : Fascinant. Intuitivement, on s’attendrait à l’inverse.
Ben : Voilà pourquoi l’expérimentation est essentielle. Nous avons pris l’habitude, chez nous, de faire voter l’entreprise sur le résultat attendu d’une expérience. Cela implique tout le monde. Ensuite, l’équipe UX offre des donuts, des stickers, etc., aux gagnants. Nous avons souvent des résultats contre‑intuitifs. Il est facile de tomber amoureux d’une fonctionnalité que l’on croit géniale, alors qu’il devient de plus en plus difficile de trouver ce qui fera vraiment bouger la plateforme.
Hugo : En un sens, vous gérez un véritable laboratoire.
Ben : Oui, focalisé sur nos questions business.
Hugo : Sans entrer dans des éléments confidentiels, comment évaluez‑vous la qualité d’un transporteur ou d’une livraison ?
Ben : Il y a un problème sectoriel : environ 10 % du temps, un transporteur engagé pour un chargement se désiste sans prévenir ou à la dernière minute. L’excuse habituelle : « Mon camion est en panne ». Les camions ne tombent pas en panne 10 % du temps. En réalité, quelqu’un leur a proposé un chargement mieux payé. Certains le font souvent, d’autres, avec 100 ou 300 trajets, quasiment jamais. Le « fall‑off » est donc un indicateur clé de qualité, car cela nous coûte très cher : nous sommes engagés à offrir une expérience de transport de haute qualité aux chargeurs, et il nous faut alors trouver d’urgence un autre camion — coûteux.
Hugo : Je comprends. Prenez‑vous en compte l’arrivée des voitures ou camions autonomes ?
Ben : Il y a d’autres métriques de qualité auxquelles nous tenons…
Hugo : Allez‑y.
Ben : La ponctualité du conducteur, l’usage de l’app — crucial pour réduire nos coûts de conformité et de sécurité. Tout cela compte. Mais, dans l’expérience citée, le fall‑off était l’indicateur principal. Nous constatons que, si nous parvenons à faire utiliser l’app aux transporteurs, beaucoup de choses positives deviennent possibles. En tant que data scientists, nous réfléchissons aussi à la structure des incitations sur la plateforme pour encourager les bons comportements — c’est très « économie ». Par exemple, s’ils utilisent l’app, ils bénéficient du quick pay : paiement le jour même. La norme du secteur, c’est plutôt 30 jours après prestation, ce qui pousse souvent à céder la créance à une société d’affacturage, avec une perte de 2‑3 %. En somme, nous leur offrons l’équivalent d’une augmentation de 2‑3 % s’ils utilisent l’app.
Hugo : C’est une hausse de revenus et, en plus, cela améliore leur trésorerie.
Ben : Exact. Comme tout le monde, j’aime être payé quand je travaille : attendre 30 jours, ce n’est pas agréable. Il faut payer les courses, le loyer, des pièces de vélo…
Hugo : Et sur les véhicules autonomes ? Est‑ce un sujet actif chez Convoy ?
Ben : Oui, clairement. Les fondateurs sont très connectés et au fait de ces évolutions. Au final, quand les camions autonomes arriveront — probablement par étapes avec différents niveaux d’automatisation — ils auront toujours besoin de se connecter au fret. Notre plateforme sert à cela. Notre objectif est de les intégrer côté offre.
La nature plurielle de la data science
Hugo : Nous parlons de l’impact de la data science sur le transport routier et nous l’abordons sous de multiples angles. Vous êtes économiste computationnel, ex‑physicien, et ancien chercheur chez Amazon. Comment tout cela façonne‑t‑il votre rôle de data scientist ?
Ben : On n’a jamais trop d’outils. Jeune physicien, j’ai eu la chance de travailler avec John Wheeler. Il disait — en canalisant Niels Bohr — « Ne citez rien tant que vous ne connaissez pas la réponse ». C’est une Wheeler‑ism célèbre. Autrement dit, vous devez avoir une intuition de la bonne réponse à votre problème scientifique. Il y a une anecdote avec Feynman : il arrive persuadé d’avoir démontré quelque chose. Wheeler lui dit : « C’est faux ». Feynman est contrarié : « Comment pourrait‑il l’avoir fait ? ». En réalité, il y avait une erreur, et la connaissance de Wheeler était telle qu’il « savait » que cela ne pouvait pas être juste. Par analogie, si vous mesurez un lift de 10 % sur une campagne courrier, c’est probablement faux : peu crédible. La physique aide à être débrouillard et à muscler ses maths, surtout l’algèbre linéaire — essentielle en data science, sans doute plus que le calcul différentiel. L’économie m’a donné des outils théoriques pour les problèmes business, et l’économétrie pour confronter la théorie aux données. Mon passage en ingénierie logicielle m’a appris à transformer des stats en code. Partout où l’on travaille, on acquiert de nouvelles compétences. C’est crucial pour un data scientist. Amazon, culturellement, apprend aussi une approche très adulte : sens de l’urgence, focus impact — comme en thèse, à se demander sans cesse : « Ce que je fais fait‑il avancer ma thèse ? ». Si non, vous n’êtes pas sur la bonne chose.
Hugo : Vous avez donné un excellent talk à Data Science Pop‑Up Seattle, « Correctness in Data Science ». J’ai aimé la façon dont vous cadrez les erreurs fréquentes et ce que nous pouvons faire pour bâtir une discipline plus solide. Quelles sont, selon vous, les erreurs majeures commises aujourd’hui ?
Ben : Ravi que cela vous ait plu.
Hugo : J’ai adoré, et nous mettrons la vidéo dans les notes.
Ben : Super. La justesse des modèles scientifiques est essentielle. Beaucoup pensent : « Mon code tourne, il sort un nombre, donc c’est bon ». Non. Il faut s’assurer que c’est le bon nombre. Il existe un cadre épistémologique venu du nucléaire : la vérification, la validation et la quantification des incertitudes (VV&UQ). Je le dois à Robert Rosner, mon directeur de post‑doc et ancien directeur d’Argonne. Trois volets : la vérification, c’est s’assurer que votre code implémente correctement le modèle — indépendamment de la validité du modèle. Donc tests unitaires, données synthétiques via Monte Carlo avec paramètres connus, et vérifier que vous retrouvez les résultats attendus. La validation, c’est s’assurer que le modèle colle à la réalité : mener des expériences a posteriori pour vérifier la fidélité. La quantification des incertitudes, c’est penser aux limites du modèle : quelles hypothèses, tiennent‑elles, que se passe‑t‑il si un « cygne noir » survient ? J’aime demander aux ingénieurs BI en entretien : comment savez‑vous que votre SQL est correct ? Souvent, cela les surprend. Mais c’est crucial : si vous assemblez un jeu de données bancal, rien ne le rattrapera. Il faut donc être méthodique : plans de jointure, tests sur sous‑échantillons, vérifier agrégats et distributions, contrôler que vous n’obtenez pas un lift farfelu de 10 %. Et, autre point clé : les modèles vont en production. Il faut donc des tests d’intégration, etc., pour garantir la fidélité entre recherche et production.
La data science en production
Hugo : Dans vos expériences passées ou chez Convoy aujourd’hui, quelle est la place du data scientist dans la mise en production ?
Ben : Cela dépend des organisations. Parfois, le data scientist fait de la recherche « pure », puis passe le relais à l’ingénierie — et quelque chose de « magique » se produit. C’est risqué : on perd de l’information. Et beaucoup d’ingénieurs n’aiment pas recevoir du code R. Python, ça va mieux. Chez Convoy, nous visons un modèle où le data scientist possède son modèle de bout en bout, avec une plateforme ML pour le déployer. Nous n’y sommes pas encore totalement, mais c’est mieux pour tout le monde : les ingénieurs appellent un service de données et récupèrent le résultat. Notre organisation par groupes produit aide aussi : un PM, un ou plusieurs data scientists, plusieurs ingénieurs, qui collaborent étroitement. Et nos PM sont très techniques : la plupart ont un master en informatique ou équivalent, un bon MBA, et savent écrire du SQL. L’un d’eux a résolu en 60 secondes, en entretien, une question impliquant un left outer join. C’est le niveau. Ils sont data‑driven, comprennent les stats de niveau licence, et cela en fait des alliés pour « bien faire » la data. En transverse, nous entretenons le lien entre data scientists : brown bags, one‑to‑one techniques, etc., pour débloquer vite.
Hugo : Un PM technique peut aussi vraiment avoir la bonne conversation avec vous.
Ben : Oui. Ils sont investis dans l’usage de la donnée. Ils savent que, s’ils conçoivent une nouvelle fonctionnalité, ils doivent travailler avec un data scientist pour définir un plan de validation type Stack Overflow ou autre. Un exemple de cette culture : Ziad Ismail, notre chief product officer, écrit du SQL. Il reste tard le soir pour interroger l’entrepôt et comprend la donnée aussi bien que quiconque.
Hugo : Vous avez une boîte à outils statistique et économétrique très riche. Quelle est votre méthode préférée ?
Ben : Question difficile — comme « votre oiseau préféré ? ». En Angleterre, on dirait : « Quelle longueur a un bout de ficelle ? »
Hugo : Et personne ne peut répondre.
Ben : Voilà. J’aime…
Hugo : Qu’est‑ce qui vous plaît ?
Ben : … utiliser le meilleur outil pour le problème. Ma thèse, à UCL, était très forte en données de panel — avec des personnes comme Richard Blundell qui ont beaucoup poussé ces méthodes. C’est un de mes points forts. Mais j’aime aussi les outils cœur du ML. Cela dépend du problème. Ce qui me rend le plus heureux, ce n’est pas l’outil, c’est résoudre des problèmes intéressants. Je suis un scientifique appliqué. J’ai travaillé sur des sujets allant de la cosmologie quantique à la bioinformatique, jusqu’au transport routier. Avoir des problèmes stimulants et trouver l’outil adéquat, voilà l’essentiel — avec les données et le logiciel, bien sûr.
L’avenir de la data science
Hugo : Nous avons beaucoup parlé de la data science d’aujourd’hui. À quoi ressemble celle de demain ?
Ben : Nous vivons une période incroyable. Si vous avez des compétences en maths et en stats, les données explosent partout. Nous allons nous amuser… jusqu’à ce qu’Elon Musk trouve comment nous rendre tous obsolètes.
Hugo : Et d’ici là ?
Ben : À un moment, des outils automatiseront les modèles simples. On voit déjà des offres de modèles de churn « sur étagère ». C’est problématique, car chaque entreprise a des données uniques : autant construire votre modèle de churn. Mais vous verrez plus de modèles commoditisés et d’outils qui automatisent les « fruits à portée de main » de la data science. Pour une carrière réussie, il faut monter dans la chaîne de valeur, vers ce qui résiste à l’automatisation — y compris l’ingénierie de features automatique. Dans une entreprise précédente, Context Relevant, on a beaucoup avancé sur l’automatisation de la feature engineering pour un large éventail de problèmes.
Hugo : Quelles compétences les aspirants — et même les confirmés — devraient‑ils développer pour ne pas être automatisés ?
Ben : D’abord, on n’a jamais trop de maths. C’est un investissement de long terme qui commence tôt. Quand j’enseignais chez Galvanize (bootcamp data), je pouvais compenser un manque de programmation en huit semaines. Je ne peux pas rattraper un déficit en maths en huit ou douze semaines : c’est des années. Investissez donc en maths. Ensuite, maîtrisez les algorithmes cœur, et continuez à lire. Beaucoup arrêtent de lire en entreprise. Pour les plus avancés, choisissez une spécialisation en phase avec vos centres d’intérêt. L’expérimentation et les méthodes bayésiennes m’attirent, et j’ai beaucoup approfondi ces domaines récemment. Beaucoup se tournent vers le deep learning — c’est très concurrentiel. Il existe d’autres domaines intéressants et importants. Donc, oui, si vous voulez, allez‑y. Mais il y a un vrai bénéfice à être un peu contrariant.
Appel à l’action
Hugo : Avec tout cela en tête, avez‑vous un dernier conseil pour les data scientists, débutants comme confirmés ?
Ben : Comprenez que vous vous engagez dans une vie d’apprentissage. C’est un marathon, pas un sprint. Comme une thèse : il faut se ménager. Cela peut prendre des années. Continuez d’investir. Peut‑être regardez un peu moins Netflix le soir, et passez un peu plus de temps à lire les bons livres et articles, à coder, à tester des modèles. Si vous n’êtes pas excité par la donnée, il existe sans doute un domaine où vous serez plus heureux.
Hugo : Continuez d’apprendre, de lire, de faire.
Ben : Oui. Pour moi, et pour beaucoup d’entre nous, la donnée, c’est un Agatha Christie : il y a un mystère, et je veux le résoudre, découvrir si c’était le colonel Moutarde, dans le salon, avec le chandelier.
Hugo : Fantastique, Ben. Vous vivez votre vie de data scientist comme un roman policier.
Ben : Quelque chose comme ça.
Hugo : Je m’y reconnais : la donnée n’arrête jamais de parler. Un collègue nous répète qu’il faut « écouter » la donnée. Elle vous parlera tant que vous l’écoutez.
Ben : Exact. Et, à propos d’erreurs courantes, beaucoup se jettent trop vite dans le modeling sans faire d’EDA — l’exploratory data analysis de Tukey. Prenez le temps : vous découvrirez des choses surprenantes. À mon arrivée chez Convoy, en faisant de l’EDA, j’ai trouvé des problèmes de nettoyage et des outliers non traités. Nous les avons corrigés et obtenu environ 10 % d’amélioration sur le modèle de prix. De la performance « gratuite ».
Hugo : Très parlant. L’EDA — car il est tentant de foncer sur les modèles — doit précéder : visualiser sous 100 angles, regarder les statistiques descriptives, etc.
Ben : Oui. J’essaie d’enseigner une approche méthodique et standardisée. CRISP‑DM — le processus standard inter‑industries pour la data mining — est sans doute le meilleur workflow que j’ai vu pour un projet data. Parcourir toutes les étapes évite les oublis : comprendre le besoin business, comprendre les données, préparer, modéliser, évaluer, déployer. Et à tout moment, vous pouvez devoir revenir en arrière : en modélisant, vous réalisez que votre feature engineering n’était pas optimal, ou qu’il faut ajouter une variable. Être systématique évite les doublons et les oublis. Et, côté « correctness », j’aimerais marier CRISP‑DM et VV&UQ : on obtient alors un cadre puissant, professionnel et mûr.
Hugo : Excellent. Cela dessine une structure systématique pour la data science de demain.
Ben : Oui. Et n’oublions pas que le modeling est la partie fun, mais tout ce qui précède prend 80 % du temps : nettoyage, préparation. Le modeling arrive vite, donne un pic d’adrénaline… et c’est déjà fini. Nous verrons — espérons‑le — plus d’outils pour accélérer l’amont, car c’est là que se trouvent les gros gains de productivité. Investissez donc dans UNIX, la ligne de commande, et d’autres technologies et plateformes qui vous aideront à préparer vos données plus vite.
Hugo : Exactement. Ben, ce fut un vrai plaisir de vous avoir dans l’émission.
Ben : Merci, Hugo. C’était un plaisir, et je vous souhaite plein de succès avec l’émission.
Hugo : Merci.