Comment mieux gérer et utiliser la Data ?

0:10 Bonne soirée à tous, enchanté. Donc, Laurent Bultveni de l'Amline Networks. Qui sommes-nous? On est un CDM, peut-être que l'image est un peu petite, ça fait un gros poste. Dont on fait de la diffusion de contenus d'Internet. C'est grâce qu'on est, on peut dire qu'on est une sorte d'autoroute où sur notre réseau va transiter des informations d'Internet, que ce soit de la distribution pour des sites Internet traditionnels, des sites e-commerce. Ce qui va permettre en même temps pour les marchands, pour tout le monde, supporter les pics de trafic, éviter des retours à l'origine. On va cacher tout le contenu au plus près des utilisateurs finaux. On va faire de la diffusion vidéo, que ce soit du live, de la VOD. On va s'occuper en même temps de tout ce qui va être transformation, transcoding, transmuxing. Peut-être que beaucoup d'entre vous utilisent la nouvelle plateforme, je n'ai pas le droit de citer son nom, qui a été sortie pendant le confinement de Mickey.

1:11 Eh bien, vous utilisez nos services. Quand vous appuyez sur Play, c'est nous qui vous livrons la petite vidéo, ce que vous allez voir, votre dessin animé ou peut-être le Mandalorian que vous avez vu sur votre TV connectée grâce à nous. À cela s'ajoute, nous faisons des services de sécurité, que ce soit de la pro... protection, voire pour protéger les données utilisateurs, les données des comptes clients, Donc, ce qui va vous permettre aussi d'être GDPR compliant. On va protéger le tout contre des grosses attaques d'IDOS. Là, récemment, il y en a eu une très grosse d'1,4 TBPS. On fait ce genre de choses. On utilise des partenaires qu'on a intégrés directement sur notre réseau. Contrairement à nos concurrents, nous avons un réseau totalement privé où ne circule que le contenu de nos clients. Et donc, on bypass l'Internet public et tous les nœuds, toutes les congestions, etc. À cela s'ajoute aussi, on a une offre où on fait du stockage, du stockage en cloud pour faire de la réplication automatique de tout ce qui est contenu, bibliothèque. Et on a une offre dédiée Edge Cloud, Edge Compute, où on va pouvoir mettre à disposition notre réseau pour vous, pour faire du calcul en temps réel, de l'AVM, du bar métal et pas mal d'autres choses.

2:25 Voilà un petit peu pour faire le tour très rapide de l'AMLight. Et je vais laisser la parole à Youen qui va monter lui aussi sur l'estrade. Et je vous souhaite un bon Bitsop à tous. Merci Laurent. Je me présente, je suis Youen Chéné, je suis le CTO de Saagie. Dans la vie de tous les jours, on fait un logiciel de ces technologies. Aujourd'hui, on va parler des personnes qui utilisent ces technologies, que ce soit, on parle de data science avec Marie Crappe, de la data dans tous ses états, dans toutes ses formes, avec Éric Pantera, CTO de Teads. Et enfin, on finira par Vincent pour faire un tour d'horizon vraiment beaucoup plus technologique pour ce cas-là. C'est le CEO de la société Affinitech, mais c'est aussi l'animateur du podcast Big Data Hebdo, un des plus anciens podcasts francophones sur la data. Ça doit avoir maintenant 7-8 ans de mémoire. Et donc pour commencer, j'invite Marie Crappe, la responsable data science de Veepee.

3:33 Bonjour à tous. Bonjour Marie. Est-ce que tu peux rapidement te présenter et ce que tu fais chez Veepee? Alors du coup, je m'appelle Marie Crappe, je suis en effet Head of Data Science chez Veepee. Veepee, pour ceux qui ne connaissent pas, c'est le nom depuis maintenant un an et demi du groupe Vente Privée. On fait des flash sales essentiellement. Et la data science, ça veut dire quoi? Ça veut dire que je gère tous les projets du groupe qui font intervenir du machine learning afin de pouvoir injecter de l'intelligence artificielle dans tous nos process métiers. Bien, ton équipe est constituée de quel type de profil? Alors, mon équipe, elle rassemble tous les profils nécessaires à pouvoir mener les projets de data science vraiment de A à Z, donc de l'exploration de la donnée jusqu'au monitoring, à la maintenance des modèles en production. Du coup, on a évidemment des data scientists, mais on a aussi d'autres profils, beaucoup plus cloud, architecte, software, développeur.

4:34 Alors, il se trouve que chez nous, on met tout un peu dans un même panier, on les appelle les data engineers, mais c'est vrai que ça peut porter à confusion parce qu'il y a beaucoup d'activités différentes derrière ça. D'accord. Et donc, c'est une équipe centrale qui fournit, vous fournissez quoi aux autres équipes? Des modèles de data science, des API? Des API, voilà. Exactement, c'est vraiment la façon dont on a décidé de fonctionner. C'est que plutôt que de fournir des modèles et après ne pas pouvoir garantir que c'est... modèle ne vont peut-être pas fonctionner dans le temps. Il peut y avoir des dérives, il peut y avoir des bugs qui interviennent. Donc vraiment, nous, on assure la maintenance dans le temps de tous les algos qu'on produit. Et donc, en fait, ce qu'on fournit, c'est des endpoints à tous les produits, à toutes les équipes métiers de Veepee. C'est combien d'équipes métiers? En gros, vous avez combien de clients en interne? Alors, on en a pas mal. Je ne les ai pas forcément comptés. Déjà, ce qu'il faut avoir en tête, c'est que Veepee, c'est quand même environ 1000 personnes à la tech. C'est souvent plus que ce que les gens pensent. On a plus de 80 équipes produits. Et côté data science, on va avoir trois grandes familles.

5:40 De produits, d'algorithmes. La première, c'est la personnalisation. Pour ça, on va avoir des clients qui sont le front de Veepee pour personnaliser l'ordre des ventes sur la homepage, mais aussi les équipes qui gèrent le CRM pour personnaliser les mails. Ensuite, la deuxième grande famille, ça va être le demand forecast. Donc ça, c'est du grand classique, c'est la prévision des ventes, mais c'est hyper important chez Veepee. Là aussi, les clients, ils vont être... Nombreux en fait, c'est pas juste un client, ça va intéresser le business pour aider les commerciaux, mais ça va aussi intéresser la supply chain pour améliorer la gestion des entrepôts. Et la troisième grande famille d'algo, en tout cas qu'on a aujourd'hui, puisque ce sera amené encore plus étoffé dans le futur, c'est tout ce qui est autour des images et du texte. Et là, nos clients, ça peut être à la fois les équipes qui gèrent le référentiel produit, mais aussi ce qu'on appelle les digital factories. puisque Veepee permet aux marques de produire tout le contenu numérique. On a des studios, on fait les shootings photos et on remplit les fiches techniques.

6:41 Il y en a des algos qui permettent d'accélérer ces process. Et vous vous reposez sur quel stack technique? Ce que tu peux partager, bien sûr. Alors sur la stack déjà d'un point de vue infra, l'équipe data de Veepee est entièrement sur GCP. Et du coup, la data science utilise essentiellement Google pour à la fois l'entraînement, mais aussi la mise en production de nos API. On a simplement quelques serveurs GPU pour des besoins spécifiques d'entraînement de modèles. Et après, sur les langages, on va être sur du grand classique. Donc, le Python, évidemment. On a également du Java, un petit peu de Scala, quelques autres langages, mais plutôt anecdotiques. Et sinon, sur les technos qu'on utilise, elles dépendent vraiment des projets. On s'adapte au niveau de complexité et au SLA de chacune de nos API. On va utiliser énormément de briques GCP, évidemment, de Cloud Storage et BigQuery jusqu'à Google Kubernetes Engine, Cloud Dataproc, Cloud PubSub, le load balancing, etc.

7:49 Et on utilise aussi beaucoup dans l'équipe TensorFlow avec TensorFlow Ranking, TFNX et des technos assez avancés. Il y a des gens qui commencent à se dire, C'était du PyTorch ou pas dans les équipes ? Je vois que ça pousse dans les communautés Python, c'est pour ça que... Alors, chez nous, on a des personnes qui l'ont déjà utilisé, mais en production, on n'a pas de PyTorch. Ok, pas encore. Et du coup, tu es arrivé il y a combien de temps à Veepee, du coup, il y a un an, un an et demi? Un petit peu moins d'un an. Un petit peu moins d'un an. Et du coup, c'était quoi ta mission initiale et à quoi tu t'es... Quelles ont été les difficultés et les trucs que tu as dû faire quand tu es arrivé? Alors, ma mission initiale, c'était manager de l'équipe Data Science. Lors de mes entretiens, il était un peu question que ce soit 50% management, 50% tech, rester les mains dans le cambouis, continuer à contribuer, ce qui était encore le cas de mon job précédent. Ça, pour le coup, ça a pas mal évolué parce qu'en fait, quand je suis arrivée,

8:50 J'ai découvert une équipe qui n'avait pas du tout besoin d'aide sur le plan technique, mais qui avait énormément de besoins sur le plan management. Management au sens très large, c'est-à-dire à la fois l'aspect un peu RH, administratif, one-on-one, etc., mais aussi gestion de projet, parce qu'il n'y avait pas de project manager, chef de projet ou product owner. Il n'y avait vraiment que des profils tech. Et très étonnant, j'ai du coup découvert notamment un produit qui fonctionnait extrêmement bien, avec une stack hyper avancée, passionnante, mais en face, un business qui était réfractaire, voire carrément convaincu que... ces algorithmes prenaient de la valeur à Veepee. Mais tout ça parce qu'en fait, il n'y avait pas eu forcément d'accompagnement, de gestion de projet, de communication proche du business. Donc voilà, mes missions, du coup, se sont pas mal réorganisées autour de ça. D'une part, la structuration de l'équipe. D'autre part, vraiment de la gestion de projet sur définir des roadmaps, clarifier les objectifs.

9:53 Et enfin, la partie plus communication avec le top management, lien avec le business et construction d'une stratégie plus long terme. Mais oui. Tu n'avais pas du coup le phénomène, on a vu l'IA, c'est super marketé, c'est magique, ça va tout résoudre. Tu avais l'effet inverse. Oui, c'est ça. C'est pour ça que j'ai été étonnée parce qu'en effet, dans beaucoup de boîtes, on a plutôt un département marketing ou certaines personnes côté métier qui pensent que ça va être une révolution, la magie. Et de l'autre côté, des modèles qui sont juste au stade de notebook, mais qui sont très loin d'être en production et encore énormément de travail d'ingénierie à faire. Et là, je suis arrivée sur l'inverse, des choses qui tournaient en prod avec d'excellents résultats, mais un business qui n'était pas du tout convaincu. J'en profite pour dire, si vous avez des questions, vous pouvez utiliser l'interface pour poser des questions et on les posera à la fin de l'interview et à la fin de l'ensemble des interviews. C'est quoi les difficultés, les gros chantiers que tu as eu à mettre en place pendant cette année, notamment dans les relations avec les autres équipes?

10:54 Alors, comme je le disais, il y avait déjà un enjeu de communication, tout simplement, se rapprocher du métier, leur montrer qu'on s'intéresse à leurs enjeux, qu'on ne prend pas, par exemple, la personnalisation, c'est un grand enjeu, parce qu'on choisit l'ordre des ventes sur la homepage et qu'on ne prend pas ces choses-là à la légère. Donner plus de transparence sur les modèles, autant que faire se peut, parce que ce n'est pas toujours très facile selon les modèles de machine learning qu'on décide d'utiliser. Du coup, il y a beaucoup de pédagogie sur leur expliquer, c'est quoi vraiment le machine learning, comment ça fonctionne, qu'est-ce qu'on est capable d'expliquer au sein des modèles. des données qu'on n'est pas capable d'expliquer, beaucoup travailler du coup sur les chiffres, c'est-à-dire mettre en place des... Qui suivent les AB tests, parce que tous nos algos, on les teste grâce à des AB tests, mais vraiment industrialiser le suivi de ces AB tests pour permettre une communication hyper proche et des analyses très granulaires pour les BU. Et après, évidemment, rentrer en contact avec un maximum de personnes dans des équipes variées pour identifier leurs besoins et voir quels nouveaux projets on peut lancer.

12:04 D'accord. Et je vais zoomer un petit peu techniquement sur les algos. C'est quand tu n'as pas d'explication des algorithmes. Vous avez quand même de l'algorithme, du deep learning, du GPU, c'est plus compliqué à expliquer, ou sinon c'est beaucoup d'arbres de décision et de choses comme ça, où c'est un peu plus facile à expliquer? Non, en effet, on a quand même ce challenge d'explicabilité des modèles, notamment parce que sur l'un de nos projets phares, on a fait des choses vraiment à la pointe, qui ont fait l'objet de beaucoup de R&D. Pour ceux qui s'y connaissent un petit peu parmi les participants, on travaille avec des réseaux de neurones 6 à 1 mois, utilisant une triplet loss. Donc, ce n'est pas des algos que vous trouvez comme ça, tout packagé, qu'il y a juste à déployer. C'est des choses qui demandent pas mal de travail. Et derrière, les résultats sont excellents. Par contre, on ne peut pas vraiment expliquer, en effet, au business sous forme d'arbre de décision. C'est souvent ce que veut le business. Ils veulent prendre un arbre de décision très clair.

13:05 Et c'est là que la pédagogie est importante. C'est qu'il faut toujours rappeler que ça ne fonctionne pas comme ça. Rappeler que ça part des données et ce n'est pas des règles de gestion avec des si et des alors. Mais avec le temps, ça finit par fonctionner. Et sur les données, vous n'avez pas de difficultés particulières sur la qualité des données, où il a fallu faire beaucoup de travail en amont, expliquer, où c'était facile, magique, tout de suite? Qui n'a pas de problème de qualité de la donnée? Je serais intéressée de savoir, peut-être les startups qui viennent de se lancer, qui ont fait un modèle parfait l'année dernière, mais ils auront des problèmes dans deux ans. Non, non, bien sûr, on a des problèmes, on en a plein. Alors, je préférais dire challenge que problème. Notamment, Veepee, en fait, c'est quand même un groupe qui existe depuis 2001, dont le modèle de données a beaucoup évolué. Et surtout, aujourd'hui, c'est un groupe. C'est un groupe qui a racheté Vente Exclusive dans le Nord, Privalia dans le Sud. Et donc, en fait, aujourd'hui, on a un gigantesque chantier de convergence qui a été lancé déjà il y a un bout de temps et qui demande notamment d'aligner les modèles de données de toutes les entreprises qui comptent quand même des dizaines de millions de membres.

14:15 Donc, on est sur des challenges énormes. Et évidemment que ça se reflète dans la donnée. Il faut s'y retrouver. On est sur un business qui change tout le temps. Et du coup, la donnée aujourd'hui n'est clairement pas celle de 2017 et ne sera pas celle de 2017. Du 21. Vous allez être à la place de ma atomique. Pardon. Non, continue, continue, excuse-moi. Pour répondre à cet enjeu, du coup, on a une stratégie relativement classique aujourd'hui, mais de mise en place d'un data lake, où on crée des data contracts avec chacun des produits de Veepee pour alimenter un data lake qui fait un mapping ensuite avec toutes les données des différents pays, permettant ensuite à la BI de construire des dashboards unifiés et à la data. Science de venir aussi chercher toutes les données à un même endroit. D'accord. Il y avait quelque chose qui rebondissait sur quand en face, les gens ne sont pas convaincus, l'équipe qui n'est pas convaincue, comment tu vas impulser quand même de pousser sur des sujets où les gens ne sont pas encore convaincus pour prouver la valeur?

15:19 En gros, est-ce que c'est toi qui impulses? Est-ce que c'est la direction qui va impulser ou il faut continuer à persuader l'équipe métier? Alors, il y a plusieurs choses. Je pense que dans ces sujets, c'est évident que gagner la conviction du top management, c'est essentiel. À partir du moment où notre fondateur, Jacques-Antoine, a été convaincu par la valeur ajoutée de la data science, ça a quand même vraiment changé le discours avec toutes les autres strates de l'entreprise. Ensuite, il ne faut pas baisser les bras sur la pédagogie et vraiment parler avec les gens, leur faire comprendre qu'on saisit leurs enjeux. Beaucoup les écouter aussi pour être sûr qu'on a bien pris en compte toutes les subtilités métiers. Et enfin, je dirais que notre atout à chaque fois, nous, c'est vraiment les AB tests. On rassure sur les AB tests parce qu'on dit de toute façon, on ne va pas vous prendre 100% du trafic et vous n'allez pas comprendre si les changements, c'est dû au Covid ou c'est dû à notre nouvelle variation. Non, on va se mettre d'accord sur un pourcentage du trafic global et vous allez avoir des analyses très détaillées qui sont hyper objectives pour voir si ça ne fonctionne pas et on décidera ensuite sur les roll-out avec ces résultats.

16:31 On va arriver doucement à la question sur est-ce que tu recrutes des data scientists et quel est ton vécu par rapport à ça ? Et ça va relier à une question, est-ce que c'est des gens qui sortent des connes d'ingénieurs, est-ce que c'est des doctorants, des gens qui sortent de thèse, des chercheurs qui ont 10-15 ans d'expérience? Comment ça se passe sur le commande data scientist dans ton équipe? Alors, aujourd'hui, je ne recrute pas de data scientists, tout simplement parce que quand je suis arrivée dans cette équipe, il y en avait beaucoup. Par contre, on recrutait énormément d'autres profils, ceux que j'ai pu mentionner au début, qui vont être sur les enjeux site reliability engineering, ops, mise en place de pipeline de données. Donc, on pourrait parler en fait de tout le panel des nouveaux noms qui sont sortis, ML Ops, ML Engineer, Data Engineer, etc. Et en fait, pourquoi on ne recrute pas de data scientists aujourd'hui? C'est tout simplement parce que, comme je dis, il y en a beaucoup dans l'équipe et en fait, un data scientist seul ne va pas apporter de la valeur au business, en tout cas très difficilement. Là, on parle de machine learning qui vraiment est en production avec des SLA qui sont parfois très solides.

17:35 Veepee, on parle de potentiellement plus de 2000 connexions à la seconde, des SLA qui sont ceux du e-commerce. Et donc, on a besoin de tous ces métiers-là. Et sur la séniorité des profils, bien sûr qu'on va recruter différents niveaux de séniorité. Les PhD, en général, les PhD data scientists, je vous le dis très honnêtement, ils ne vont pas trouver leur bonheur dans mon équipe. Parce qu'on ne fait pas de la recherche. On fait éventuellement de la recherche, mais appliquée pour justement mettre des modèles innovants en production. Mais on est là pour écouter le business, pour apporter de la valeur au business et pas pour plancher sur des sujets pendant trois ans sans avoir de conviction forte sur la valeur ajoutée. Et c'est vrai qu'aujourd'hui, on a énormément, énormément de candidatures en data science. Alors qu'en fait, tu as posé la question des sorties d'école, les sorties d'école data scientist, leurs compétences correspondent souvent aux fameux 5% de la data science, c'est-à-dire la modélisation, je suis sur mon notebook, mon dataset, il est parfait.

18:44 Et je vais fine-tuner mon modèle, je vais essayer plein d'architectures, Mais en fait, il y a un monde avant et il y a un monde après. Et nos besoins de recrutement, ils sont clairement sur ces deux pans-là. Et je pense que le marché, il est inondé aujourd'hui de profils qui sont concentrés sur le 5% du milieu. D'accord. Et toi, tu as besoin des gens sur tout le reste, si j'ai bien compris. Exactement, tout le reste. Donc, tu n'es pas confronté à une pénurie de data scientists de ton côté. C'est vraiment en plus les data engineers, les data ops, les mail ops et tout ça. En effet, je suis vraiment convaincue qu'il y a, et ça fait déjà deux ans que je suis convaincue de ça, qu'il n'y a pas de pénurie de data scientists aujourd'hui. Au contraire, la hype. Autour de ce métier a fait que les masters, les formations en ligne, les bootcamps se sont mis à produire. énormément de data scientists. Il y a eu aussi beaucoup de reconversions de gens assez seniors vers la data science, alors qu'en fait, derrière data science, on a oublié de dire qu'il y avait des besoins vraiment énormes en gérer le streaming de données, mettre en place des pipelines, des gens qui savent utiliser des technologies comme...

19:50 Airflow, Dataflow, Kubernetes, etc. Et je remonte les questions, il y a une question de David, mais ça rejoint là aussi la question de Didier sur... les retours. Si je reformule un peu les deux questions, est-ce que tu as des victoires ou des défaites à partager? Des victoires pour dire, sur les méthodes classiques d'analyse, BI, statistiques, on arrivait à un certain point et par une approche d'action learning, tu as créé un petit effet wow, tu as permis d'aller à une équipe métier, d'aller beaucoup plus loin de ce que eux pensaient, même de ce que toi tu pensais au début. Est-ce que tu as eu des cas comme ça que tu peux partager, bien sûr? Oui, j'en ai plusieurs en tête. Je l'ai déjà cité plusieurs fois, mais c'est vrai que la personnalisation sur un métier comme Veepee a beaucoup de sens. Comme je le disais, on a plusieurs dizaines de millions de membres. À côté de ça, on a une open page sur laquelle vous pouvez avoir jusqu'à 250 ventes différentes sur une même journée. Et donc, en fait, ranker ces ventes par personne a beaucoup de sens. Et là-dessus, j'avoue avoir été assez impressionnée par l'incrément que ça apporte sur tous les KPI.

20:58 Son pouvoir de donner de chiffres, ça justifie quand même d'avoir une équipe temps plein sur le sujet. L'autre sujet que j'aime beaucoup, c'est autour des images. Aujourd'hui, Veepee a la chance d'avoir plusieurs dizaines de millions d'images à sa disposition. Comme je l'ai précisé, on a nos propres studios de shooting. Et ces images, elles ont été labellisées pendant des années. Et donc aujourd'hui, ça nous permet d'entretenir des modèles assez puissants qui, à partir d'une photo, vous dit si c'est un t-shirt, mais peut aussi vous dire si c'est un... col en V, c'est des manches courtes, c'est du vert, etc. Et ça, même si j'avais été moi-même data scientist avant, en particulier dans le domaine de l'image, mais je reste assez impressionnée quand même par ce que peut apporter l'EML sur ce sujet et que clairement, la data analyse ne pouvait pas. Ok, merci. Et une autre question de Timothée, c'est comment tu vas de l'expérimentation jusqu'à l'industrialisation? C'est-à-dire, comment tu parles du notebook, qui est un outil classique, à une API avec un SLA qui sert, je ne sais pas de combien de requêtes par jour.

22:06 Alors, première chose qui, pour moi, est hyper importante, ce n'est pas forcément organisé comme ça dans toutes les boîtes, mais j'ai mis un point d'honneur à ce que ça se fasse comme ça chez Veepee, c'est que les data scientists ne travaillent pas seuls dans leur coin et ensuite fournissent un modèle à d'autres profils. C'est des équipes projet. Des équipes projet qui, du coup, peuvent évoluer dans le temps en fonction des besoins et qui ont des objectifs communs. Et ces objectifs, c'est forcément des KPIs sur ce qu'on va livrer. Et donc, ils travaillent main dans la main avec ces autres profils, data engineer, etc. Donc, de base, comme tout le monde a travaillé ensemble, il va y avoir une certaine attention portée à la capacité de mise en production des modèles. Et ensuite, on va suivre des cycles quand même assez naturels, je dirais. On va en effet utiliser des choses comme des notebooks pour itérer. Dès qu'on va être assez sûr de nous, on va... On va déployer des microservices, on va mettre nos premiers endpoints en production, on va les tester sur des A-B tests avec peu de trafic.

23:11 À la fois pour ne pas mettre notre infra trop en stress et pour d'abord regarder les résultats. C'est-à-dire que tu fais 0,1%, 1%, 10%? En fonction des sujets et de la vitesse à laquelle on souhaite avoir des résultats significatifs, on va adapter les pourcentages. On passe par en dessous du 1%, mais ça va aller de 3-4% à 33% quand on est déjà très sûr de nous. Sachant que justement, en dessous de cette chaîne, disons, de l'exploration jusqu'à la mise en production, on s'est aussi outillé de choses qui nous permettent d'entraîner des modèles de manière de plus en plus industrialisée, mais aussi d'outils comme des outils d'évaluation offline, parce qu'on a quand même beaucoup d'algos dont on ne peut pas vraiment évaluer les performances en offline, comme c'est le cas du machine learning classique pour la prévision d'admende, par exemple. Et sur la perso, on ne peut pas, il faut être en condition réelle. Mais du coup, on a quand même développé des outils d'évaluation offline, donc de simulation qui nous permettent d'anticiper déjà les performances et de réduire les risques une fois le test lancé en production.

24:21 Je vais grappiller une minute parce qu'il y a eu cinq votes d'un coup sur la question. Quand ça se passe, la gestion de projet dans les équipes d'attache et Veepee, est-ce que vous arrivez à appliquer des méthodes agiles? À votre métier. Tout à fait. Les méthodes agiles, c'est incontournable. Toute la data science chez nous travaille sur ça. Je vous disais, on est en équipe projet et on est sur le classico-classique de la méthode agile. On a des backlog grooming avec tous les profils qui sont présents. On a les sprint planning, on est sur un rythme de deux semaines. On a les délits tous les matins et les rétrospectives selon les équipes, toutes les deux ou quatre semaines. Et pour le coup, ça n'a jamais posé problème. Vu de challenge spécifique par rapport à ça, le seul challenge là-dessus, c'est l'exploration. Parce que souvent, en data science, on a aussi besoin des fois de faire des choses qui sont difficiles à chiffrer pour aller peut-être chercher de la valeur, mais ce sont des choses où on n'est pas sûr. Et pour ça, on utilise par exemple la notion de time boxing. Au lieu de faire un ticket où on sait clairement quelle est la difficulté et combien de temps ça va nous prendre, on dit, ça c'est un sujet exploratoire, j'aimerais le creuser, combien de jours on se donne?

25:27 Et donc, on chiffre de cette manière et ça rentre dans le flux classique des surmédiations. Je te remercie pour ces 20 minutes, Marie. Tu pourras revenir dans 40 minutes. Je vais faire entrer Éric sur scène. Merci à toi. Merci à toi pour tes questions. Et vous pouvez encore poser des questions et pour y répondre tout à l'heure. Éric, à toi. Bonjour Éric. Hello, Youen. Alors, tu te trouves à Montpellier actuellement, si j'ai tout suivi? Oui, exactement. Je suis à Montpellier. Il commence à faire chaud. Et voilà, on est bien. Et j'invite tous ceux qui veulent venir nous rendre visite à venir. On fera une belle visite. Et donc, qu'est-ce que tu fais chez Teads? C'est quoi ton rôle en tant que CTO? Alors moi, je suis CTO chez Teads. Je vais raconter peut-être un peu mon parcours.

26:29 Ça va me permettre de comprendre d'où je parle, de quel angle je parle. Moi, j'ai fait Epita fin des années 90, début des années 2000. Donc, cursus... Cursus computer science et j'ai découvert la data était on peut dire omniprésent à l'époque mais on ne savait pas et j'ai découvert le big data et le machine learning sur le tard que je que j'adresse aujourd'hui avec un oeil de manager en fait le CTO c'est un manager technologique en étant bien entouré et donc je vais parler avec ce prisme là en fait sur Peut-être un prisme pragmatique sur ce que ça veut dire tout ça. On va définir. Parce qu'avant, on a parlé de data science, d'intelligence artificielle. Là, on ne va pas… La data, qu'est-ce que ça veut dire pour toi et qu'est-ce que ça veut dire chez Teads? Alors Teads, rapidement, c'est une boîte où on fait de la publicité en ligne, dans les articles de presse, donc dans la presse la plus... En tout cas, on essaye. Donc la data, et je vais détailler un peu omniprésente, que ce soit dans du ciblage, du machine learning, de la connaissance utilisateur, de l'analytics, du data engineering, du CRM, etc.

27:38 Donc, j'ai une anecdote. Quand tu m'as demandé, est-ce que ça te dit de faire le talk sur la data? Si tu veux, dans ma tête, c'est un peu passé la même chose que quand on m'a dit les deux derniers CEOs. Bon, Éric, tu viens d'arriver. Écoute, la plateforme, ce n'est pas très stable. Il faut que ça marche. Et puis après, priorité, la data. Ok, donc priorité de la data. De quoi on parle? Quelle data? Est-ce qu'on parle... Parce que dans la même phrase, on peut entendre, on veut être data-driven, et on veut faire du big data et monétiser la data. Est-ce que c'est la même chose? Être data-driven et... Et monétiser de la data. Je ne sais pas. Est-ce que être data-driven, bien connaître l'usage de ces produits, avoir une BI puissante, faire de l'A-B testing, faire de l'analytics, est-ce que c'est ça la data? Est-ce que c'est ça dont on parle quand on parle de data? Est-ce que...

28:40 Est-ce qu'accumuler des logs de données, c'est ça faire de la data? En plus, vous avez un... Un métier dans la publicité ou la data, vous avez du stream de data en permanence. Oui, voilà, donc ça c'est le point de départ et du coup je vais essayer de te dire un peu nous ce qu'on met derrière le mot data. Pour faire le lien avec Marie, évidemment c'est la partie la plus évidente pour démarrer, c'est le machine learning, notamment dans la publicité. Le machine learning il est omniprésent chez nous. Il s'est développé, on a des gens très compétents là-dessus. Ça a été créé par Robert, Cyril, qui ont développé les premiers modèles il y a maintenant 4-5 ans. Et aujourd'hui, si le machine learning tombe en panne chez une boîte comme Teads, du jour au lendemain, la boîte ferme, elle s'écroule. On utilise du machine learning pour délivrer notre service, c'est-à-dire faire du ciblage publicitaire, prédire des clics, des qualités de trafic, des ventes, des prix, etc.

29:42 On utilise du machine learning pour faire de la fraud detection, on utilise du machine learning pour alléger l'opérationnel. Donc si le machine learning tombe en panne, on a l'infrastructure dont les prix explosent, on a plus suffisamment de personnes dans la boîte pour opérer le business, et d'ailleurs notre business D'ailleurs, si on parle base de données, l'acte de données, c'est combien de teras ou de pétas chez vous ? On a toujours les chiffres de Criteo qui sont énormes. Oui, c'est sûr que dans la pub, c'est impressionnant. Nous, on a à peu près entre 500 et 100 000 transactions en 30 par seconde, qu'ensuite on démultiplie parce que c'est notre métier d'aller appeler, de faire une compétition dans le domaine de la publicité. Donc, il se démultiplie jusqu'à 5 millions de requêtes par seconde. Ce qui fait que quand on applique nos modèles de machine learning là-dessus, on doit faire les 5 millions de prédictions par seconde. Et si on parle de volume de données, on en parlera j'imagine, si on parle de stocker l'usage,

30:48 l'usage de notre service, c'est-à-dire les publicités vues, le parcours des internautes, les articles lus, ça représente à peu près 20 milliards, je pense entre 20 et 50 milliards de lignes par jour. À peu près un péta de données sur trois mois. Vous avez réussi à garder un peu d'historique ou pas? Ou vous êtes tellement contraint par les coûts que c'est compliqué? Vous savez, les data scientists ont besoin d'avoir de la profondeur. Donc, Oui et non. Ça, c'est intéressant. Donc nos modèles de machine learning ne fonctionnent pas forcément de manière très profonde en termes de... d'historisation de données. Parfois, il est plus efficace de faire un learning sur les deux derniers jours, par exemple. Donc, c'est vraiment... Ça, c'est le métier de la data science. Il y a vraiment des cas, ou même dans les dernières 24 heures, parfois. Donc, on garde la donnée, pour répondre à ta question, la donnée granulaire, on la garde...

31:50 En plus, il y a la CNIL là-dedans, donc on la garde 3 à 4 mois. Après, la donnée la plus fine, qu'ensuite on agrège, qu'on anomise et qu'on anomise et qu'on garde beaucoup plus longtemps. Et moi, ce que je vois souvent, c'est que les gens commencent pour ne pas faire de machine learning, mais souvent, ils commencent par de la BI, voire de la BI++. On a toujours l'image de la tech où ils sont super forts en data. Comment ça se passe, la BI, toute la donnée data-driven, données de pilotage, et dans notre cas, il doit aussi y avoir de la donnée à partager aux clients et tout ça. Oui, c'est ça. Le machine learning, peut-être qu'on en reparlera, c'est assez structuré, je pense, dans l'esprit des gens aujourd'hui. Les algos, l'apprentissage, c'est assez structuré. Je rejoins totalement Marie sur ces 5%, ces 10%, peut-être ces 20% de notre boulot. Ça ne se fait pas sans une alimentation massive des pipelines et du data engineering massif. Donc nous, on a ce même choix.

32:52 Pour alimenter le machine learning, on a ce même choix que Veepee d'avoir des ingénieurs qui font un peu les deux, en tout cas de mixer ces deux compétences. Mais après, la data engineering, ça ne sert pas que au machine learning, ça sert à faire de l'analytics, bête et méchante, à facturer nos services et à faire de ce qu'on appelle la BI, donc on va essayer de décomposer. Pour ça, nous, on a une équipe dédiée, on a une équipe d'ingénieurs dédiés qui fait... Un peu tout le pipeline de collecte, de traitement et de mise à disposition de la donnée afin qu'ensuite elles soient interprétées et traitées par d'autres équipes. Donc c'est une équipe centrale qui va présenter la donnée à tout le monde et après chacun va faire ses cas d'usage autour en fonction de sa problématique. On travaille comme ça. On travaille comme ça parce qu'on a des problématiques de volume et de traitement de données, comme je te l'ai dit.

33:54 La data engineering en tant que telle est une vraie science, pour le coup, extrêmement noble, complexe et toujours vraiment pas résolue. Il n'y a que BigQuery, par exemple, qui a des miracles, mais toujours vraiment pas résolue et ça demande un travail très important. Et après, ce greffe là-dessus, sur notre data lake, que je pourrais décrire, ce greffe, les différentes features teams qui vont faire leur dashboard de connaissances produits, d'APT testing, de monitoring d'usage, ce greffe, la BI, ce greffe, la finance. Ce greffe, voilà. Le contrôle de gestion, tous ces secteurs d'utilité. Justement, avant de passer à l'organisation, la stack technique, ça doit être compliqué chez vous, parce qu'il y a un besoin de performance qui est assez énorme, un volume qui est assez énorme. Comment vous faites? Avec quelle technologie vous jouez? Est-ce que vous jouez avec des clouders? Est-ce que vous faites vous-même? Alors, on essaye de rester le plus simple possible. On essaie de rester pragmatique avant tout.

34:57 Encore une fois, effectivement, on essaie de ne pas se perdre dans... dans de la recherche, très concret, on essaie de délivrer un service de manière la plus pragmatique et agile possible. Sur la stack de machine learning, nos équipes ont développé en interne un framework. Pour une raison particulière, c'est les temps de réponse qu'on doit garantir en production. Donc on a développé une lib interne dans Spark, où on a implémenté quelques algos de machine learning assez simples, entre guillemets, de l'agrégation linéaire, de la classification, et de la classification par quantile, et on se contente de ça. On se contente de ça, et on essaie de l'outiller, de l'optimiser le mieux possible autour, avec de l'offline, de l'online, essayer de garder les mêmes libs pour faire de l'offline et de l'online, ce qui est important, outiller le feature engineering, Voilà, ça sera la partie très rapidement, sur la partie machine learning.

36:02 Sur la partie vraiment data engineering, au sens de notre pipeline de données, on a, je pense qu'on a une transformation intéressante. On est passé du state of the art de la land architecture, telle qu'on pouvait la connaître il y a quelques années, à un gros big query. D'accord. Un gros bico. Ce n'est pas du stream, vous interrogez la base directe. Oui, alors bien sûr, on a du streaming. Notre pipeline, c'est une collecte des événements avec un ET qui met ça dans du Kafka. On a des processings en temps réel, en flink, pour normaliser, nettoyer, filtrer, traiter la donnée. Mais ensuite, on stocke ça dans S3, sur Amazon, et aussi dans BigQuery, pour faciliter... La BI, mais pas que. On utilise aussi BigQuery comme moteur d'agrégation et de retravail de la donnée à ce qu'il y a.

37:04 Ok, donc tu as mentionné Flink, vous avez du Spark et du Flink, ils sont souvent mis en concurrence au sein de l'organisation. Oui, c'est une bonne question. Effectivement, c'est étonnant. On a Spark et Omni présents chez nous, évidemment, comme chez beaucoup, j'imagine. Et pour un use case très précis, streaming, on a pensé un temps que Flink était intéressant, notamment pour la gestion du backfreshure. Effectivement, ça pose question d'avoir les deux, mais ça marche bien aujourd'hui. Et du coup, ça relie à la question qui a été posée par Thibault Loiselier, c'est qu'est-ce qui vous a conduit à construire votre propre bibliothèque dans ce parc? En existant, ce n'était pas assez suffisant? Oui. Alors, ça, il faudra en parler en profondeur avec Robert et Cyril chez nous, si vous les connaissez, qui ont fait ce choix-là. Ce qui nous a conduit à ça, c'est à l'époque la gestion des sparse vectors, qui n'était pas bien faite dans les lignes existantes, qui était un besoin pour nous, et cette volonté, donc la rapidité d'exécution.

38:15 On fait 5 millions de... 5 millions d'évaluations de modèles par seconde. Il faut que ça aille vite pour un affichage publicitaire. Ça aussi, quand on a démarré, c'était... On pensait qu'on pouvait mieux le faire en interne, en se focalisant sur vraiment notre besoin. Et cette volonté d'avoir la même technologie pour l'offline et l'online. On pourrait réévaluer ce choix aujourd'hui. Et côté BI et tout ça, tu as mis les trucs cool, Flink, Spark et tout ça. Côté BI, c'est quoi? C'est du ClickView? Est-ce que c'est un truc hyper classique ou vous avez fait des dashboards sur mesure web et tout ça? Alors, c'est encore plus classique que classique, j'ai envie de dire. Tu sais, la BI, elle est double, elle est affichée à nos clients, à nos utilisateurs des dashboards d'Analytics. Donc, si je resitue le métier, c'est je suis client, j'ai payé de la pub, je regardais la performance publicitaire, c'est ça? Par exemple, où je suis un éditeur de presse et j'ai besoin de savoir comment mon site web me rapporte de la recherche avec la publicité.

39:22 D'accord. Donc cette partie-là, la partie cliente, la partie utilisateur externe, on l'a fait sur du développement custom. C'est un produit web, donc ça c'est du développement custom. Sur cette partie-là, nous, on a fait le choix de projeter la donnée dans des data marts qui correspondent aux grands use cases des clients. Et on fait du dev web par-dessus, du React et de la data vise classique. En interne, comme on a la chance d'avoir une grosse équipe data engineering qui est capable de travailler des data marts, de les projeter et de faciliter ça, On a un outil de BI très simple qui s'appelle Chart.io, qui est vraiment... Qui est assez simple, qui est très facile d'utilisation et très user-friendly, et Chart.io qui nous permet de manipuler les data marts qu'on a créés. Et Chart.io est au centre de la vie de tout le monde dans la boîte. D'accord. Depuis 6h du matin pour ceux qui lèvent tôt jusqu'à... Très bien. Souvent, le plus dur, ce n'est pas forcément de faire le chart, mais c'est de faire qu'il soit utilisé tout le temps.

40:24 Donc, on va revenir à l'organisation de tes équipes. C'est que, justement, avec Marie, chez Veepee, on a vu une équipe centralisée qui fournissait des modèles. Comment ça se passe chez toi, que ce soit pour le machine learning ou pour tous les autres métiers de la data? Oui, alors le machine learning, on a fait un choix qui est de décentraliser le machine learning et donc de mettre des data scientists, puisqu'on les appelle comme ça chez nous, dans toutes les équipes qui ont besoin de machine learning. Donc on n'a pas une équipe centralisée de machine learning qui fournit des modèles et des API pour différentes équipes. On va au bout de l'approche feature team et on a dans trois équipes aujourd'hui, trois ou quatre équipes, des data scientists qui font pour les besoins de l'équipe et les besoins use case précis des modèles. Du machine learning et on apporte de la transversalité avec une communauté de pratiques et des échanges et de la réflexion conjointe entre équipes et de l'outillage. Ça, c'est pas naturel.

41:26 Je ne crois pas que ce soit naturel quand on a pris cette décision de le faire. Parce que quand on a un tel besoin d'expertise sur un domaine, on pense qu'il vaut mieux le centraliser, mais nous, ça a porté ses fruits de le décentraliser. Par contre, tu as expliqué que tu avais quand même des équipes centralisées, notamment pour la gestion de données tout à l'heure. Est-ce que tu as d'autres équipes centralisées ou est-ce que tout est décentralisé, quel que soit le métier derrière? Donc le machine learning est décentralisé. On a une grosse équipe qu'on appelle Analytics chez nous, qui fait la collecte, le traitement et qui fournit les outils pour manipuler la donnée. On a une équipe data engineering centralisée, bien qu'on ait des data engineers dans beaucoup d'autres équipes pour ensuite avoir une autonomie plus forte. On a une décentralisation aussi de l'équipe de business analysis, ce qui est, je crois, ce qui n'est pas banal, ce qu'on considère être comme une faiblesse, mais qui peut-être est une force, je ne sais pas. En tout cas, on n'est pas clair là-dessus. En tout cas, on n'a pas d'équipe centrale de BI.

42:28 On a une communauté de business analysis éclatée un petit peu dans la tech, dans le produit, dans des business sponsors qui sont référents de différents produits. On a cette décentralisation. De manière générale, on est très décentralisé. Ok, très bien. Ce soit la bière, c'est vraiment un peu classique. Tu arrives à avoir une cohérence de rapport ou ce n'est pas grave? Entre les deux. Entre les deux. Donc la force de la décentralisation, c'est que chaque équipe, donc là je parle des équipes tech et produits, chaque équipe est très autonome sur la mise en place de ses dashboards, que ce soit des dashboards techniques ou des dashboards produits, et très impliquée dans le... Très impliqué dans la connaissance du business et de l'utilisateur, parce qu'en faisant les dashboards, ils sont obligés de se poser les bonnes questions.

43:29 Donc ça, ça marche très bien. Notre outil d'analytics, donc Chart.io, qui reste très simple, joue comme un terrain de rencontre, en fait. C'est là-dedans que finalement chacun vient composer son tableau ou son chart ou vient créer un nouveau dashboard. Et effectivement, évidemment, souvent on a des conflits de définition. Qu'est-ce qu'un client? Quel est tel produit? Quel est tel produit? Mais globalement, ça s'aligne. Globalement, on s'aligne. On est en train de me rappeler à l'ordre, au niveau de l'horaire, comme j'avais pris un avec toi, vu que c'est tellement large à donner, on n'aura qu'un aperçu, malheureusement. J'ai posé une question pour faire la transition, qui est celle qui a le plus de votes, qui a été posée par Vincent Heuschling, qui est le prochain orateur. Vous avez des grosses volumétries sur BitQuery. Est-ce que vous avez testé BitQuery et Mail? Non. Non? Non, on ne l'a pas testé parce que... Pourquoi on le testerait?

44:34 Vincent, pourquoi on le testerait? Pour la publicité, puisque vous faites beaucoup de choses dans BigQuery, vous avez simplifié beaucoup de choses en mettant des choses dans BigQuery, et nous on se rend compte qu'il y a des clients aujourd'hui où la performance qu'ils arrivent à obtenir pour leurs analystes, pour les faire monter vers du prédictif, Et finalement, il y a une voie de simplification de dire, finalement, tout analyste qui est capable de manipuler les données en BigQuery va commencer à pouvoir faire des modèles. Assez simple, là on est d'accord aussi, c'est des modèles qui vont être, je ne vais pas dire d'entrée de gamme, qui ne vont pas être des modèles très évolués, mais ça peut permettre d'enclencher des aspects prédictifs plus facilement. Bon, écoute, on va regarder, mais on est très driveé par la production, par l'usage de nos services en prod. Donc en prod, nous, on est en ce cas-là, nos modèles sont en ce cas-là. C'est ça qui nous drive, en fait. On essaye d'éviter ces deux temps et ces deux technologies que sont, je caricature, des chercheurs dans un coin vont étudier des modèles et un jour, des ingénieurs vont les implémenter.

45:39 On ne travaille pas comme ça. Donc c'est pour ça qu'on utilise d'ailleurs assez peu de Python, bien qu'on en utilise, aussi pour ces raisons-là, pour être drivé par la production. D'accord. Très bien. Merci, Éric. Il y a assez de questions, on va les garder pour tout à l'heure, pendant 20 minutes. Un point, parce qu'un point qui est essentiel, je te donne la parole, qui était en fait le cœur de mon message. Là, on a parlé de choses qui sont volumineuses, peut-être impressionnantes, mais la data, c'est aussi Salesforce, c'est aussi installer un intercom. C'est aussi, finalement, regarder... La base de données des utilisateurs. Et j'aimerais plutôt faire passer ce message-là, en fait. Commencer dans la data et s'intéresser à la data, c'est sûrement d'abord regarder le CRM de l'entreprise, regarder le Salesforce,

46:46 Peut-être qu'on aura l'occasion d'en rediscuter, mais nous, les techs, on aime bien ce qui brille, on aime bien la grosse donnée, on aime bien la hype. Mais aller voir Salesforce, c'est sûrement plus intéressant que couvrir un site. Mais là, on ne va pas vous parler de qualité de données en sortant de Salesforce. Petite note pour ceux qui utilisent Intercom, regardez les options, il y a des trucs pas très GDPR-ready dedans, qui viennent prendre toutes les données des réseaux sociaux de ceux qui se connectent sur votre site. Donc, il y a un petit truc à décocher pour votre DPO et tout ça. On l'a appris par hasard. Merci Éric, à tout à l'heure. Et donc, bienvenue Vincent. Donc Vincent, en plus d'être aussi au Daffinitech, tu es l'animateur de Big Data Type 2. Ça fait combien de temps que ça existe, Big Data Type 2? Écoutez, on a démarré à Daffinitech en 2012 et c'est à peu près deux ans après qu'on a démarré avec, on va lui rendre l'honneur de ça, malgré le fait qu'il ait quitté l'aventure depuis, avec Benjamin Guimbertier. On a démarré le Big Data Hebdo en se disant, si on arrive à temps en temps à faire un épisode, ça sera pas mal.

47:49 Et puis, on a diffusé ce matin le 102e épisode du podcast. Donc, c'est une belle aventure. Et avant la data, tu faisais quoi? Alors, moi, j'ai eu la chance d'avoir... avoir un parcours très en zigzag, mais très enrichissant, puisque j'ai été CTO, c'était mon premier métier, j'ai été CTO, ensuite j'ai été consultant pour vendre de l'infrastructure, je résume un petit peu les choses, et puis je suis arrivé autour des années 2011, où un de mes clients m'a demandé de faire une conférence sur le Big Data, McKinsey avait sorti son papier assez fondateur sur l'épopée du Big Data en 2011. Et quand j'ai lu ce papier, je me suis allé voir le lendemain mon patron, je lui ai dit écoute, on va se séparer, je vais démarrer une aventure entrepreneuriale dans le monde de la data. Et donc j'ai démarré à Finitech en 2012, ce qui était un petit peu early sur le sujet. Et on a commencé à accompagner, comme je dis, le métier, c'est d'aider des clients dans leur démarche autour de la data pour construire des produits et services data.

48:53 Et je dis souvent qu'auprès de mes clients je joue un rôle de CTO data aujourd'hui tu m'as présenté comme CEO d'Affinitech mais je dis toujours aussi que je suis un peu le CEO par défaut parce qu'il n'y a personne d'autre qui veut faire ce job dans la boutique et donc on a accompagné des clients dans des projets ça peut être des choses extrêmement simples mais des choses très compliquées comme ce dont on vient de parler lors des deux présentations d'interview et puis depuis peu j'ai démarré une nouvelle aventure qui est le fait de construire un produit qui s'appelle Datatas, qui a comme vertu de répondre justement à un des challenges. qui ont été soulignées par Marie tout à l'heure, qui est comment est-ce qu'on passe le plus facilement d'un notebook à un service. On s'est rendu compte qu'on avait de manière récurrente justement ce problème chez de nombreux clients, du merveilleux travail fait par un data scientist qui ne passait pas le cut pour passer en production et que c'était un vrai problème. Donc c'est une nouvelle aventure que j'ai démarrée il y a peu. Qui me permet aussi de revenir sur, comme c'est un produit, de revenir sur des challenges un peu plus techniques de CTO, un peu plus dans la longueur.

49:58 Donc, ça me fait très plaisir. Et du coup, on va venir au cœur du sujet. Parce que moi, étant dans la data, je suis souvent, on discute beaucoup avec d'autres CTO et j'ai des questions de type qui vont te sembler un peu... Un peu simpliste pour toi, mais c'est quoi la différence entre Data IQ et Snowflake? Des choses qui n'ont plus ou moins rien à voir. Oui, tout à fait, mais dans les deux cas, ce sont peut-être les produits dans la data qui ont eu le plus de hype ces dernières années. Sur la dizaine d'années qui vient de s'écouler, Dataiku, c'est une superbe aventure très réussie. Ils ont comme point commun d'être tous les deux créés par des Français. On peut être fier de ça. On nous parle de la French Tech, mais pour le coup, ça, c'est deux super grosses réussites. Vous allez bientôt en être une troisième au train où vous allez chez Seiji. Bravo pour cette récente levée de fonds. Et puis, fondamentalement, Data IQ, c'est un atelier qui va permettre de démocratiser les travaux de data science. Alors que sur Snowflake, on est plutôt dans un produit qui, lui, est un simplificateur du layer de stockage et d'exploitation de données.

51:02 Marie et Éric nous ont parlé de Google BigQuery. Snowflake est plus à comparer avec Google BigQuery, alors que Dataiku, lui, ne va pas du tout aider la partie infra, mais va plutôt aider la partie exploitation de la donnée à très haut niveau. Et ce que je voulais dire, c'est qu'en fait, ça donne un peu l'éligibilité du marché de la data actuellement. Et donc, je t'invitais aussi pour qu'on s'y retrouve un peu. Effectivement, il faut... Après, il y a un nouveau bullshit, on pourra sans doute... Commencer par la partie stockage notamment. Oui, tout à fait. Mais ce qu'il y a de très certain, c'est qu'effectivement, il n'y a pas de produit magique non plus. Et souvent, ces produits ont aussi comme point commun d'être présentés comme étant des produits magiques. Qui vont solutionner tous les problèmes des entreprises et qui vont faire que les entreprises vont être data-driven du jour au lendemain. Mais ça, c'est totalement illusoire. Ils ont l'impression que j'ai plus entendu parler de culture avec Éric et Marie que technique. Oui, c'est ce que nous, on constate au quotidien avec nos clients, c'est qu'actuellement, on a plus un sujet d'acculturation et de développement d'une mentalité de

52:09 développement de produits et de services qui peuvent changer le business à l'intérieur des entreprises que de problèmes technologiques actuellement. Donc si je repars un peu pour donner la visibilité, si je parle stockage, on a parlé de BitQuery, on a parlé de Snowflake, on pourrait parler d'Adoub, si j'en vais directement en débat. En 2020, toi, Vincent Eschling, si tu dois construire une architecture de data, comment tu fais? Eh bien, écoute, en 2020, on va dire jusqu'en avril, mai 2020, j'aurais dit que ça pouvait encore être un bon pari. Et puis, depuis précisément le 2 juillet 2020, je dis que c'est surtout un très mauvais pari, puisque Cloudera, qui après avoir tué la diversité du marché en rachetant Hortonworks, a déclaré ce matin qu'ils y recherchaient un repreneur. Donc, on se dit qu'Adoub va finir par mourir chez IBM ou chez Oracle ou dans un fonds d'investissement. Et donc avec une grande difficulté. On sait que ce genre de marché n'existe que par la diversité des acteurs et la concurrence qui peut exister entre eux.

53:10 Et depuis maintenant, les clients qui ont fait le choix d'Adoub il y a quelques années, ils ont quand même de grosses difficultés à opérer tout ça. Et c'est quelque chose de... Et c'est quelque chose... Je crois que tu ne vas pas le reprendre pour le cas, celle-là. Et c'est quelque chose qui... Qui s'unira mal alors qu'on aurait pu avoir, ça aurait pu être, Adou pourrait rester un acteur majeur aujourd'hui. Il ne faut pas oublier qu'aujourd'hui, face aux offres cloud, c'est le deuxième facteur, on ne peut pas dire qu'il n'y a que Cloudera qui faut tif là-dedans. Les offres cloud ont aussi beaucoup fait de mal à Adou puisque la complexité à gérer d'un Adou est quand même infiniment plus élevée que celle que l'on peut avoir si on s'appuie sur les services managés d'un code provider. Et du coup, là, tu as répondu de manière un peu généraliste. Si tu n'as pas une équipe qui a des gens comme Netflix, qui ont des gens comme Uber, qui ont des gens comme LinkedIn ou autres pour administrer des grands clusters à double et pour pouvoir gérer,

54:14 les montées de versions sans dépendre d'un fournisseur qui est quand même devenu un point de fragilité, il ne faut surtout pas le faire. D'accord. Du coup, tu fais quoi? Tu prends du S3? Tu prends effectivement du service manager et tu commences à te dire que, tu vas pouvoir découpler surtout avec le service manager ta capacité de stockage de données d'un côté et de processing de ces données de l'autre côté, puisque c'est là aussi où un ADOOP, il a un couplage très fort entre le nombre de nœuds que tu vas déployer pour ton stockage de données et le nombre de nœuds que tu vas avoir en termes de ressources de processing. Alors, quand tu vas chez un cloud provider, le stockage ne coûte quasiment rien. Alors, on pourra venir sur les coûts de réseau, tout ce qui s'ensuit. On peut en parler pendant très longtemps. Les comparatifs sont très difficiles à faire et tout le monde a... un avis tranché là-dessus. Nous, ce que l'on sait, c'est qu'aujourd'hui, on a vu une délivrabilité de projets beaucoup plus importante depuis que l'on a fait le switch de passer depuis le déploiement de distribution à double vers des offres de cloud provider. C'est le taux de réussite des projets et le time to market de ces projets, il est bien plus intéressant.

55:19 Pourquoi? Parce qu'on abstrait une énorme quantité de travail liée à l'administration. Parce que les offres sont sur étagère et que manager un cluster à double, même à quelques nœuds, même à quelques dizaines, quelques pétas de données, c'est déjà un truc très difficile. Il faut du monde. Il faut du monde. Il faut une équipe d'Obs. C'était lors d'un Adoub Summit qui devait se tenir en 2014. Je crois qu'il y avait le responsable des opérations de LinkedIn qui avait fait un talk. Il avait dit Adoub n'est pas un problème technologique, c'est un problème d'Obs. Oui, oui. Je sais, on l'a fait pour notre première offre, c'était ça. C'était le manager pour les autres. Bien sûr. Il faut des 3-4 offres pour le faire. Bien sûr. Ok, tu as ton stockage. Donc là, tu prends un des stockages sur étagère d'un des clouders. Et pour info, même maintenant, les OVH et les scaleways sont des offres équivalentes. Pour être un peu plus national.

56:20 Non, je vais faire du traitement de données. Alors, le choix par défaut, et on l'a vu précédemment, ça reste quand même Spark qui est un format qui est... qui est un outil de traitement de données qui, pour le coup, est une... Je ne vais pas dire qu'il est hégémonique, ça serait excessif, mais qui a une grande flexibilité et qui est capable de s'adapter à des cas de figure du très très batch à du... De la donnée en mémoire, du full memory pour la mémoire, et qui a une richesse fonctionnelle quand même très importante. D'ailleurs, Spark 3 qui est sorti récemment, et on a enregistré la semaine dernière un épisode du Big Data Hebdo là-dessus, donc vous pourrez, si ça vous intéresse, en savoir plus avec des gens de Databricks. Arrive avec plein de nouveautés, qui vont finir par faire la jonction entre je fais du traitement local de données, c'est-à-dire sur un worker qui est un mono-neu, à du traitement distribué. Donc Spark a quand même permis de résoudre des gros problèmes de calcul distribué et de scalabilité de manière assez intéressante. Et ça reste quand même une offre assez précise.

57:22 Tout à l'heure, on parlait de stockage dans BigQuery. Aujourd'hui, si vous êtes sur GCP, vous pouvez faire du Spark sur les données qui sont à l'intérieur de BigQuery en bypassant la couche SQL, par exemple. Donc, vous avez des capacités comme ça. Et tous les providers aujourd'hui, de toute façon, ont une offre de stockage de type objet. Tu citais OVH, effectivement, tout à l'heure. Et ont une capacité à avoir de la ressource Spark, c'est-à-dire qu'on ne provisionne plus des nœuds de traitement, mais on va provisionner à la volée un cluster sur lequel on va exécuter un ou plusieurs jobs. Mais on provisionne et on déprovisionne, c'est-à-dire qu'on ne se... ne commite pas sur la quantité de ressources de traitement. Et ça, c'est un point très important. Pour faire votre critique, tu ne penses pas que ce n'est pas un peu trop overkill pour la plupart des cas, ou un bon script Python R, Scala, ça suffira? Effectivement, c'est le choix par défaut, et c'est le choix qui permet d'avoir quelque chose qui soit pérenne dans le temps, quelle que soit la scalabilité que l'on va avoir.

58:23 Néanmoins, il y a une immense majorité de datasets qui doivent être traités, qui sont des datasets qui vont très bien tenir dans la mémoire d'une VM, même de taille raisonnable. Sachant qu'aujourd'hui, la VM d'une taille raisonnable chez la plupart des cloud providers, c'est quand même déjà quelque chose d'assez conséquent en mémoire. Et effectivement, nous, on a vu beaucoup de clients qui étaient partis au départ sur des scripts Spark pour faire du distribué. qui, pour enlever un niveau de complexité, ont rebasculé sur des workers qui sont des VM, qui là aussi spawnent ces VM dès lors qu'ils en ont besoin. Ils exécutent leur traitement en mémoire. Dans la mémoire de la VM, et puis ils descendent de la VM après. Et du coup, je vais reprendre deux petites questions qui sont liées au sujet. Je reprendrai celles sur les métiers après. Dataflow qui est de mémoire Apache Beam en version open source par rapport à Spark. Alors, Dataflow n'existe que...

59:28 n'existe que chez Google quasiment. Et donc, il y a un gros problème par rapport à Spark, qui est la portabilité de travaux qui ont été faits dans Dataflow. C'est pour ça que nous, on préconise assez rarement à nos clients de se mettre dans ce modèle-là de Dataflow. Même si c'est vrai que c'est un modèle super intéressant, puisque le modèle d'Apache Beam, c'est de dire on fait la jonction entre du batch et du streaming, et donc on va utiliser le même modèle de compute pour traiter des données, qu'elles soient avec un stream de taille finie, c'est-à-dire un batch, ou qu'elles soient avec un stream de taille finie. Stream infini. Après, les features que va apporter un Dataflow sont, si on n'a pas de streaming, faire du Dataflow, c'est quand même un peu overkill. C'est beaucoup plus complexe que Valette du traitement avec Spark. Spark a quand même aussi une portabilité, c'est-à-dire que vous prenez stricto sensi un job qui tourne sur GCP avec de la data qui est dans Cloud Storage sur GCP, vous allez chez Amazon et vous faites tourner ce job sur du S3 et ça tournera vraisemblablement sans trop de difficultés. Et donc là, tu as cité des technologies qui sont des technologies très orientées code.

1:00:31 Si je viens du monde de la BI et que je faisais de l'informatique ou du data stage, je veux faire de la data en 2020, qu'est-ce que je vais utiliser? Alors, il y a toujours la ressource d'utiliser un outil comme les outils de BI, les data stage, les talent, tout ça, se sont adaptés à ce genre de solution. Après, nous, ce que l'on dit, et c'est tout à l'heure, on parlait de Snowflake, c'est aussi un problème. Snowflake est une merveilleuse solution qui permet aux gens de rester un pied dans le SQL et d'avoir un pied qu'ils croient être dans le futur, sauf qu'il n'y a pas de rupture importante. Si tu connais les cubolas pour ne pas être... Voilà. ... Et t'es pas perdu. Tu n'es pas perdu. Il y a toujours un risque de faire juste une amélioration incrémentale comme ça et de ne pas avoir une amélioration de rupture à un moment donné. Donc, effectivement, le fait d'avoir des gens qui veulent rester dans leurs vieux outils traditionnels en ayant un passage à l'échelle de la data, à l'échelle du cloud, ça va vraisemblablement à un moment donné être un frein et quelque chose qui va leur coûter sur le fait qu'à vouloir rester un peu dans l'ancien monde, ils n'auront pas accès à tout ce qui est possible de faire dans le nouveau monde.

1:01:38 Même avec du DataQ, du Google Fusion, je crois que même Amazon est en train de sortir de nouvelles offres, ou de l'Azure ML par exemple. Oui, bien sûr. Pour revenir sur DataQ, le constat que nous, on a vu chez quand même beaucoup de clients, c'est que malgré la promesse, ceux qui ne savent faire que de l'analyse de données dans des outils de BI, DataQ, c'est trop haut pour eux. Donc, la marche, elle est trop haute à monter. Et ceux qui savent déjà faire du IPython Notebook pour faire des traitements de données, qui savent déjà coder du Spark, c'est un peu une régression. Donc, à un moment donné, c'est ces outils qui sont censés apporter une réponse très générale que tout le monde va pouvoir utiliser. L'histoire montre que c'est des outils qui vont freiner le développement. Un exemple simple, on a actuellement des gens avec qui on travaille, ils sont hyper branchés sur Talend. Ils ont des artilleries de jobs qui tournent sur un cluster à double, qui sont opérés par du Talen.

1:02:43 Donc, c'est du Talen Big Data, qui génère du Spark. Et ce qu'on sait, c'est que pour moderniser ça, ça va être très difficile parce qu'ils sont dans un confort absolu autour de leur talent qui ne les a pas obligés à adopter et à appréhender la technologie sous-jacente. Oui, tu dois apprendre tous les mécanismes sous-jacents pour optimiser. Voilà, à un moment donné, il va y avoir des plafonds de verre à traverser, et si tu restes dans une technologie qui te maintient confortablement sans te faire prendre de risques et sans devoir te mouvementer, tu vas avoir un moment donné ce plafond de verre sur lequel tu vas te heurter. Et donc avant de faire venir tout le monde sur scène, une petite dernière question, c'est je veux visualiser la donnée ou je veux exposer la donnée en API ou des modèles en API, les nouveaux de partie, c'est qu'est-ce que tu vois sur le marché? Est-ce que je mets la carte bleue et j'achète le bon gros tableau? Qu'est-ce que tu as vu comme approche qui marche? Nous, on voit de plus en plus quand même dans la lignée, nous, dans la lignée... De ce que des gens comme Netflix ont fait, on voit quand même la valorisation et la capacité à recycler ce qui a pu être fait en expérimentation à l'intérieur d'un notebook pour commencer à construire des dashboards à partir de ça.

1:03:55 Il y a des offres au-delà de Chartaio dont Éric nous a parlé juste avant. Il y a des offres comme Voilà qui permet de commencer à sortir des visualisations à partir d'un notebook. Il y a des offres comme Dash de Plotly. Qui permettent de construire des visualisations qui sont d'un très très bon niveau et qui sont donc déployables sous forme d'applis web très simples et donc partageables au sein d'une organisation. Et par exemple, pour prendre l'exemple de Netflix, qui pour moi est souvent assez... Montre la direction dans laquelle il faut regarder. Et le... Et ce qui remonte à nous, eux, ils ont généralisé le fait d'utiliser le notebook comme étant le document quasi bureautique de partage de données à l'intérieur de l'organisation. Et ils ont automatisé la génération du notebook, c'est-à-dire pour les faire tourner, pour générer des graphes, pour générer toutes formes de choses. Et c'est une solution qui est extrêmement viable. Ce que l'on pense, c'est qu'aujourd'hui, Tableau est comme pouvait l'être Excel à un moment donné, un outil qui apporte un set de fonctionnalités tellement vaste.

1:05:00 qui apporte des moyens tellement structurants par rapport à tout ce qu'il peut apporter, qu'il est utilisé à globalement 5% de ses fonctionnalités par beaucoup de ses utilisateurs, ce qui en fait quand même une solution très très chère. Si on regarde ça. Et justement, j'ai vu une question sur MLflow, mais du coup, tout ce qui est MLflow, Kubeflow, modèle management, gestion des métadonnées, des modèles hyperparamètres, est-ce que tu vois des choses qui... C'est émergent, donc est-ce que tu vois des choses qui commencent à être adoptées sur le marché? Nous, on voit des choses qui sont de plus en plus... Oui, effectivement, une émergence assez forte là-dessus. Avec notamment la logique qui va être de commencer à dire je suis capable d'avoir de l'automation autour de toutes ces tâches de gestion de la mise en production du modèle et de la capacité à faire que le d'automatiser le fait la maintenance du modèle tout à l'heure marie parlait de problématique d'exposer qu'une api pour pouvoir garder en dans le sein de son équipe, la maintenance des modèles, c'est un vrai challenge. Et ces outils vont pouvoir apporter un côté ML Ops assez intéressant de ce point de vue-là.

1:06:06 Et on les voit de plus en plus. Et d'ailleurs, si on regarde les offres de Databricks, elles sont quand même hyper focus de ce point de vue-là. Très bien, merci. Du coup, je demandais à Éric et Marie de venir sur scène. J'ai sélectionné deux questions par rapport à ce qui a été posé avant. C'est très timé par rapport à un podcast du coup. Ah ouais, disons. Merci à tous d'être revenus. La question c'est, on n'a pas hyper nué Data Science, c'était light. C'est quoi le nouveau métier qui monte dans la data? Honneur aux femmes. Je pense que c'est un peu déjà ce que j'ai dit tout à l'heure. C'est comme on parle toujours dans les médias de data scientists, on oublie les autres métiers. Il y a les métiers ML Ops et ML Engineer qui sont un peu sortis dernièrement et dont on entend de plus en plus parler.

1:07:11 Je pense que pour moi, c'est ça. Parce qu'on fait de plus en plus de data science et on a besoin aussi de plus en plus de la mettre en production. Donc, c'est ces métiers-là qui vont monter et qui doivent monter. Pour compléter, j'ai deux réponses. Une provocatrice, donc software engineer, et une un peu plus réelle. Je crois que le machine learning, ça prend bien. Le machine learning, ça s'apprend bien. On sait l'apprendre aujourd'hui. Il y a Coursera, il y a des cursus, il y a des algos, etc. En tout cas, en apparence, on croit que c'est facile. Mais ce côté universitaire un petit peu du machine learning et son côté cadré peut faire oublier ce qui pour moi est un point essentiel de la data science qui est le... La curiosité, la créativité et un peu le côté pirate.

1:08:14 C'est-à-dire trouver la bonne feature. Pour trouver la bonne feature, il faut aller s'intéresser au business. Il faut le comprendre. Il faut le comprendre de manière créative, c'est-à-dire en se disant, est-ce qu'on ne pourrait pas récupérer tel type de données? Il faut être à l'affût des innovations technologiques. Je vous donne un exemple concret. Nous, en fouillant, on s'est rendu compte que Chrome, un jour, dans une version, a relisé la capacité de récupérer en temps réel le network bandwidth des dernières secondes. Ça, c'est une feature géniale pour faire du machine learning pour de la pub. La rapidité de la connexion à un instant T, c'est-à-dire entre la salle de réunion et l'open space. Un data scientist, habituellement, il ne va pas le trouver. Donc, un data scientist très créatif, c'est ça le métier. J'ai vu, moi, dans les questions dans le public, des gens qui mélangeaient des PFD avec des étudiants qui sortaient de 42. En haut, le méga hacker avec le méga diplôme. Donc ça, c'est génial. Il en manque un.

1:09:15 Le super businessman. Oui. Il y a une dimension business qui est souvent très oubliée et qui fait que l'expérience sectorielle est super importante finalement quand on commence à parler de data science. Et moi, je rejoins quand même Marie sur le fait de dire qu'on a moins besoin de data scientists. Mais plus de gens qui sont capables d'utiliser ce qui a pu être créé par un data scientist, de le mettre en musique pour le mettre au service du business. C'est clairement ce type de métier un peu moins... Qui se retrouve sous le terme ML Engineer. Et tu as dit, sauf toi, ingénieur, tout à l'heure, Éric. C'est super, oui. Tu veux dire quoi? Que les data scientists ne savent pas coder, etc. Parce qu'ils commencent à avoir un peu de data scientist bashing, On s'en est aussi en avoir marre de ça. Non, loin de moi l'idée de bâcher qui que ce soit dans cette industrie. Mais je répète ce que dit Marie et ce qu'on a tous dit. Prenons Kaggle. Prenons Kaggle. Être data scientist, ce n'est pas que faire du Kaggle.

1:10:20 Explique ce que c'est Kaggle pour tout le monde. Moi, je ne connais pas très bien Kaggle, mais Kaggle, c'est une plateforme qui permet de faire des concours de machine learning sur des échantillons de données déjà existants. Donc, en fait, c'est trouver la meilleure solution possible à un problème qui est bien posé. Ce n'est pas ça qu'on fait en entreprise. On ne cherche pas la meilleure solution possible à un problème qui est bien posé. On cherche déjà à comprendre la question. Généralement, elle est posée à côté de la plaque. Et ensuite, on cherche à collecter de la donnée, mettre des pipelines pour enfin essayer de la résoudre. Donc, quand je dis... Quand je parle de software engineer, je veux dire par là qu'il faut plus développer le pont entre le code et la data science. C'est indispensable. Et comme Éric, loin de moi, l'idée de bâcher qui que ce soit, j'ai commencé en tant que data scientist. Je vois le commentaire notamment de Thibault Loiseleur, qui est data scientist parmi nous.

1:11:23 Mais encore une fois, je pense que c'est juste comme souvent une question d'alignement des formations avec les besoins du terrain. Et en effet, Il y a beaucoup de data scientists qui ont des profils très stats, très maths, et donc pas forcément programmation, ça dépend. Et ne serait-ce qu'une bonne culture générale tech et une bonne sensibilisation aux enjeux, à des bonnes pratiques de développement, c'est déjà un bon début. Je pense, pour pouvoir aller plus loin que les notebooks, en effet. Je vais enchaîner par une autre question. C'est la data, que ce soit Veepee ou chez Tite, c'est un énorme impact sur le business. Quand les gens font appel à Vincent, c'est aussi pour un impact sur le business. Est-ce que vous pouvez nous partager un gros fail? ou une belle plantade que vous avez réalisée. Oui, c'est faire du tri d'ailleurs le plus difficile là-dedans. Et surtout, comment vous l'avez résolu?

1:12:25 Tu as un moment donné, tu parlais de la data visualisation. Le plus gros fail qu'on ait eu, c'était un jour de faire un splendide modèle de segmentation et de recommandation pour un client. Et on sortait un truc assez brut. Et on n'avait pas du tout mis l'accent sur le fait de travailler sur la... Sur la data visualisation et le client n'a rien compris à ce qu'on lui proposait. Donc, il a fallu qu'on revienne derrière en ayant fait cet effort de pédagogie. Et ça, ça a peut-être été la plus belle leçon qu'on ait eue, c'était de se dire que finalement, il n'y a aucun effort d'enrobage d'un savoir-faire très brut, qui est sûrement très performant, mais totalement incompréhensible pour la personne qui était en face de nous. Et ça, c'était l'absence de marketing autour du produit créé. Était sûrement un fail monumental. Marie, Éric ? Alors, je n'ai pas réussi à trouver un exemple Veepee. En tout cas, pas de grande ampleur. Mais par contre, j'en ai un d'une expérience précédente.

1:13:27 J'ai travaillé un moment donné pour la SNCF sur des projets de deep learning pour la reconnaissance de défauts dans les rails et les pantographes. Et quand je suis arrivée, le projet était un peu dans un état catastrophique. Pourquoi? Pour quelque chose de très bête, mais très difficile. En fait, c'était juste la compréhension du besoin. Et tout le problème s'était cristallisé autour d'un mot. Ce mot, c'était« accuracy». Enfin, en français... Merci. Oui, non, il ne le disait pas comme ça. Mais en gros, la SNCF avait un besoin, c'est mon système, je veux qu'il soit apprécié à 99,9%. Et en face, ils avaient des gens hyper, justement, stats. Et le système qui tournait, la SNCF était là, mais regardez, je vois tout sauf des images de pantographes. Donc votre système, il ne marche pas, c'est sûr. Et de l'autre côté, les data scientists, c'était des chercheurs, etc. C'était en mode, si, si, on a fait des modèles et la précision des modèles, c'est 80.

1:14:30 Enfin, justement, ce n'est pas précision, c'est accuracy. L'accuracy des modèles, c'est 99%. Et du coup, on arrive et on se dit, c'est fou, les gens n'arrivent vraiment pas à se comprendre. Et en fait, c'était vraiment une question de vocabulaire et d'alignement sur le besoin métier. Le métier de la SNCF, c'était d'avoir une interface sur laquelle, depuis les caméras, on voyait juste des photos de pantographes. Les pantographes, c'est ces bras mécaniques au-dessus des trains qui relient à la caténaire. Et ils voyaient plein de photos de plein de parties du train, mais ils envoyaient très peu de pantographes. Et de l'autre côté, les statisticiens, c'était la définition de« accuracy», c'est-à-dire combien d'images ont été bien labellisées par nos modèles. Et en fait, quand vous regardiez, les deux avaient raison. C'est-à-dire que la SNCF, ils étaient frustrés. En effet, sur leur système, ce n'était pas vraiment utilisable en condition de production. Et les statisticiens, leur modèle, une fois qu'on l'a audité, avait en effet une accuratie de 99%. Mais la précision et le recall sur les différentes catégories d'images que vous pouvez avoir, donc différentes parties de la toiture, les pantographes, la face du train, les rails,

1:15:35 faisait que vous aviez 200 images de toiture qui venaient polluer l'interface des utilisateurs parce qu'un train, c'est tout de suite 4000 images. Donc, même en ayant une bonne accuratie, vous avez quand même beaucoup de bruit, vous avez quand même 1% d'erreur. Donc, en fait, le système final, il ne convient pas. Et là, je parle d'un projet, il y avait quand même plusieurs millions en jeu, ça durait depuis plusieurs années. Et en fait, il y avait besoin de quelqu'un comme ça de l'extérieur qui se rende compte que c'était essentiellement un problème de communication et de compréhension du besoin de métier. Donc en fait, je dis la même chose que Vincent. Éric? On faille tellement souvent que je ne sais pas quoi choisir. Je ne sais pas si c'est le plus gros, mais je vais prendre le plus récent. Je vais prendre le fail de ce matin. On s'est rendu compte, c'est très classique, très basique, mais c'est ça qui est intéressant. On a... Un service a commencé à déconner, on a cherché pourquoi, on s'est rendu compte qu'on avait des données qui n'étaient plus dans les slaves de nos bases de données primaires, parce qu'en analysant, on avait un réplica lag qui était monté à 20 minutes.

1:16:47 Pourquoi? Parce qu'un de nos jobs de machine learning s'est mis à alimenter une base de cache, une base de cache, pourquoi elle est en maïsquel, on pourra en discuter, mais une base de cache toutes les trois minutes avec 20 millions d'entrées. Voilà, donc réplication master-slave, réplication à l'acte augmente. Et alors qu'on fait des trucs très sophistiqués, ça s'est passé entre les mailles du filet et personne ne s'en est occupé. Un peu de pragmatisme et de terre à terre, c'est ce qui nous manque tout le temps, je pense, dans l'ingénierie. Voilà le dernier fail en tout cas. Donc du coup, on va sortir l'alimentation du cache par les modèles de machine learning de set by the SQL. On va la mettre dans un modèle plus adapté, probablement S3, pour le DSA toutes les heures. Voilà, enfin un truc commun, mais de ce matin. Et il y avait une autre question pendant ton intervention, Éric, et c'est aussi valable pour les autres.

1:17:48 Est-ce que vous avez des cas d'usage, notamment sur l'archéologie, qui ont permis... d'alléger l'opérationnel, d'automatiser des choses qui étaient faites manuellement, en gros d'optimiser la performance humaine, c'est-à-dire pas aller chercher du profit, mais aller baisser les profits. des coûts ou d'optimiser la qualité ? Est-ce que vous évitez ce type de cas d'usage-là dans vos trois expériences? Oui, je peux commencer rapidement. Évidemment. Est-ce que vous avez des exemples à citer, du coup, pour que les gens puissent... Que tu peux. Je prends un exemple de base primaire. Un annonceur, je ne sais pas si c'est quelqu'un d'une marque en particulier dans l'assistance, mais je ne sais pas, Ford qui a envie de vendre des voitures, qui a envie de dépenser un certain budget pour faire des pubs, jusqu'à il y a quelques années, c'était des opérateurs qui manuellement essayaient de délivrer la pub et optimiser. Bon, ça n'existe plus ça. Ça ne m'existe plus. Ah, il y a des gens qui disent ça. Ok. Marie ou Vincent?

1:18:53 Chez nous, j'ai envie de dire que c'est la moitié de nos cas d'usage. On en a beaucoup. Par exemple, chez Jusy, historiquement, quand vous arrivez sur une vente, vous allez avoir le catalogue. Et ce catalogue, en fait, il a été fait à la main. Les produits ont été rankés un par un avec toute une réflexion derrière de la personne en charge de cette catégorie. Pour la lingerie, vous pouvez imaginer que les hauts vont avec les bas. Pour la cosmétique, il y a peut-être des palettes de couleurs. En fait, il y a plein de choses qui peuvent être imaginées. Bon, en fait, nous, maintenant, on propose des algos. qui font ce ranking automatiquement et en plus qui le mettent à jour au fur et à mesure de la vente, en fonction de l'évolution de ce catalogue. J'ai cité aussi tout à l'heure le travail qu'on faisait sur les images. Historiquement, et encore maintenant sur certains process, quand une marque n'a pas la donnée, parce que des fois les marques perdent leurs photos, elles perdent leurs fiches techniques, ça peut peut-être paraître étonnant, mais en fait ça arrive énormément. Et donc en fait, elle nous envoie les échantillons, on fait tous les shootings, on fait les fiches techniques.

1:19:56 Donc là, il y a des personnes qui vont prendre les objets un par un et dire... dire voilà ça c'est une cafetière, elle est noire, c'est peut-être pas l'item le plus populaire sur notre plateforme, les cafetières c'est un bon exemple, donc plutôt les robes. Et du coup, grâce à nos algos, on peut dire à partir de la photo directement qu'en effet c'est une robe, qu'elle est longue, qu'elle est courte, qu'elle est à motif fleuri, qu'elle a des longues manches. Après, on peut même prédire des choses comme la matière, les méthodes de lavage et tout, mais ça, c'est encore à fine-tuner, on va dire. Vincent, chez tes clients? Oui, alors moi, j'ai deux choses. On a vu beaucoup, beaucoup de progrès chez les clients et beaucoup de choses héroïsables, si je puis utiliser ce terme qui n'est pas super beau, autour de la connaissance client. Notamment, on a vu des sujets de segmentation où on a dépassé ce que la segmentation traditionnelle pouvait faire pour pouvoir commencer à avoir du micro-segment, ce qui permet derrière d'avoir de la personnalisation. Et puis, le deuxième sujet sur lequel les clients ont eu des gains énormes, c'est sur le forecasting.

1:20:58 On voit effectivement qu'aujourd'hui, on a des technologies de forecasting qui peuvent arriver à des résultats bien meilleurs que ce qu'un chef de rayon était capable de faire jusqu'alors. Alors, ce n'est pas facile culturellement à faire passer ce genre de sujet, mais on voit qu'on a une capacité de... De faire bouger les lignes en termes de business et d'amener une profitabilité importante. Et d'ailleurs, ça devient quand même essentiel, mais on essaie toujours de travailler en début de projet sur le fait de trouver le bon KPI qui fait consensus pour qu'il n'y ait pas de débat à la sortie sur le niveau d'amélioration que ça a pu apporter au business. Et ce n'est pas toujours simple de trouver ce bon KPI à mettre en exergue pour pouvoir garantir que l'exercice a été probant. Prochaine question, une question de Pierre Rossines. Il y a beaucoup de notions à comprendre pour un nouveau entre l'infra. On a parlé de machine learning, mais en fait, vous avez beaucoup parlé d'infra, vous avez beaucoup parlé de data engineering, de restitution. Comment débuter sans se perdre? Je vais rajouter une question complémentaire à ça. C'est si votre CEO, comme il a demandé à Éric, tu stabilises la plateforme et ensuite tu t'occupes de la data, par où on commence?

1:22:07 Comment on commence pour appréhender le sujet? Comment on commence pour traiter le sujet? Je vais peut-être te faire une réponse simple pour démarrer. Déjà, on commence par stabiliser la plateforme. Oui. Voilà, la base. Et puis ensuite, on essaie de comprendre la question. Je pense qu'il faut passer du temps à la question et prendre une question à laquelle on peut essayer de répondre. Il faut passer du temps là-dessus, c'est-à-dire avec le CEO ou avec des business ou avec des opérationnels. Quelle est la première question ou le premier sujet qu'on aimerait traiter? Je pense qu'il ne faut surtout pas se dire on va créer une équipe d'atteint dans un coin et puis on verra ce qui tombe. J'insiste très souvent auprès des clients sur l'ambition raisonnable. Il faut de l'ambition, parce qu'il faut faire un truc justement qui permettra de montrer qu'il y a eu quand même une amélioration sensible de ce qui se passait dans l'entreprise avant. Mais il faut surtout qu'elle soit raisonnable, c'est-à-dire qu'une ambition totalement démesurée qui va faire qu'on a une chance de se casser la gueule qui est totalement démesurée, qui est tout aussi démesurée, ça ne sert à rien.

1:23:13 C'est qu'à un moment donné, il faut commencer par trouver un sujet raisonnablement atteignable et avoir un succès dessus. Et puis, c'est comme ça qu'on va faire les choses. Et là, tout à l'heure, la question, c'était aussi qu'est-ce qu'il faut commencer par apprendre, par quel bout on prend le problème. Là aussi, il faut se trouver un sujet qu'on est capable de cerner en termes de périmètre. Parce que c'est vrai que si vous vous attaquez au sujet d'infra, au sujet de business et au sujet de data science en même temps, ça risque de faire beaucoup de front à aller chercher en même temps. Donc, il faut, à mon avis, pouvoir serrer les choses et trouver quelque chose de... De raisonnable de ce point de vue là. Écoutez, je vais s'en tourner, Marie. Pour la première partie de la question sur par où commencer, comment se former, bien sûr, ça dépend d'où on part. Et je suis entièrement d'accord avec ce que vient de dire Vincent, tout simplement. Il faut... Je pense que ça ne sert à rien de trop papillonner, de vouloir faire 15 technos d'un coup, mais plutôt chercher sur quoi on a envie de se développer.

1:24:22 Typiquement, il y a des personnes qui choisissent de se spécialiser par cloud. Alors oui, vous pouvez faire ça. Vous avez après des très, très belles formations qui sont construites sur tous les clouds, que ce soit sur mise en production, machine learning, sur AWS, Kubernetes, Infrastructure for ML sur GCP, etc. Ça me semble être des bons points de départ. Et puis après, bien sûr, il faut trouver des boîtes où il y a des bocas d'applications et où on peut grandir grâce à des personnes plus ou moins. Très bien, et je vais essayer de gratter deux minutes par rapport au point de Noémie avec une dernière question. Est-ce que vous avez vécu le phénomène des POC à répétition, sans mise en production ? Et si c'est le cas, comment vous avez pu changer ça? Bon, Vincent fait la grimace déjà, c'est-à-dire qu'il en a vécu. Vas-y Vincent, écoute. Non, nous, on va être très clair. Maintenant, on refuse même, quand un client nous sollicite pour faire un POC, on discute avec lui de quelle manière on peut concevoir les choses comme allant jusqu'à un pilote, au minimum.

1:25:27 C'est-à-dire que la vision de comment on va aller au pilote se fasse dès le départ, parce que très souvent, il y a des POC qui étaient des choses tout à fait louables en termes d'intention, mais la partie... La suite du POC n'était absolument pas prévue au départ et donc ça amenait les gens dans une impasse et ça ne passait pas le cut. C'est souvent une raison comme ça. Et puis deuxième chose, on retombe sur ce qu'on a dit avant, c'est trouver un sponsor business qui va bien vouloir emmener les choses un peu plus loin que le POC qui fera plaisir sûrement à celui qui l'a fait mais qui n'ira pas bien loin dans l'adoption de l'entreprise. Marie? Alors moi, j'ai vécu un POC sans suite. C'était pour un acteur de la grande distrib, pour de la prévision de vente. Et j'ai cru comprendre que Vincent connaissait aussi la difficulté de se lancer dans ce domaine avec la résistance du métier, réticence. Et ça me suffit. Un, c'est déjà assez. Et du coup, j'ai pu le vivre après, mais aussi parce que c'est sûrement peut-être le sujet.

1:26:30 Le numéro 1 sur lequel je suis vigilante et auquel j'ai fait attention jour 1 chez Veepee. Merci. Et Éric, pour terminer, du coup? Donc, excuse-moi, la question, comment faire pour qu'un POC ne reste pas un POC? Sortir de l'usine à POC et sortir des vraies choses en production. Est-ce que tu l'as vécu et comment tu as fait la transition? Ce que je peux dire, est-ce que je l'ai vécu? Je pense qu'on l'a tous vécu à différentes échelles. Pas très souvent parce que c'est mon obsession première, le pragmatisme. Et on a créé une culture du pragmatisme. On essaye de, comme je vous disais tout à l'heure, d'essayer d'identifier la question à laquelle on veut répondre et on cherche les moyens d'y répondre. S'il faut faire du machine learning, on en fait. Et s'il faut faire un requête SQL, on fait un requête SQL. Donc, je... Je ne me ferai copain avec un sponsor, pas un sponsor, mais avec une personne du business ou un opérationnel et j'essaierai de lui rendre service le plus vite possible.

1:27:35 Vraiment essayant d'éviter de créer des grands projets, les grands projets Data Lake ou les grands projets... Moi, je n'ai pas eu de succès grâce à ça. D'accord. Merci à tous. On va conclure là-dessus. Je vous remercie tous les trois d'être venus. On a pu aborder les sujets. On aurait pu aller beaucoup plus loin. On aurait pu faire ça. Ça, trois heures quasiment. Mais toutes les questions n'ont pas été répondues, mais après, vous pouvez tous rester, se répartir par table, mais Noémie va expliquer ça beaucoup mieux que moi.