Comment scaler des équipes en IA ?

19:24 C'est très chouette. Alors moi, je vous fais une rapide intro de Tech.Rocks qui nous sort. pour les gens qui ne le savent pas. Donc nous, on est une communauté, une communauté de tech leaders, donc de managers techniques. L'idée, c'est qu'on a ces trois grandes valeurs qui sont l'échange, le no bullshit et l'entraide. On veut grandir ensemble et notamment, on réunit les gens sur un Slack. Vous êtes peut-être venu de là et vous avez peut-être vu nos 12 annonces sur ce meet-up, sur ce Slack. On a donc 2250 personnes aujourd'hui. N'hésitez pas, si vous connaissez des tech leaders qui peuvent le rejoindre, il suffit de remplir un formulaire et après nous on vous fait un... un petit check à la main et on les fait rentrer dans la communauté. On est également présent évidemment sur meetup.com si vous voulez suivre nos événements et vous avez également bien sûr toutes les informations sur notre site internet. Tout simplement. Donc on organise des événements, des meetups hebdomadaires sur des thématiques aussi bien managériales que techniques. L'idée, c'est qu'on a aussi notre gros événement qui s'appelle le Tech.Rocks Summit, qui a lieu les 8 et 9 décembre cette année, et qui sera juste à côté, qui sera chez Comet Meetings,

20:28 Et nous sommes sur un format hybride. On a une partie présentielle avec 300 personnes sur place et une partie virtuelle avec des contenus exclusifs si vous êtes en virtuel. Voilà, donc on va vraiment prendre beaucoup de temps aussi pour la partie virtuelle. Donc n'hésitez pas, si vous voulez qu'on en parle aussi juste après, on pourra vous donner un petit peu plus d'informations sur cet événement. Et donc on dévoile au fur et à mesure le programme et les speakers. Donc là, on a les premiers speakers qui viennent de sortir sur le site. Vous pouvez aller voir, on a un site dédié au Summit. C'est pareil, on pourra en parler juste après si besoin. Voilà. Et si vous vous connectez régulièrement, vous verrez les prochains speakers. Dans l'année, on a également la partie événements, on a la partie contenu, du contenu fréquent, des articles, des replays, des meetups. On aura notamment ce meet-up en replay. Donc n'hésitez pas aussi à le partager si le sujet vous a intéressé et si ça peut intéresser d'autres gens. On a une newsletter bimensuelle qui est faite par la communauté pour la communauté. C'est une curation de contenu et qu'on diffuse justement tous les vendredis midi.

21:29 Les deux sont... Si vous voulez devenir contributeur ou contributrice, n'hésitez pas, ça se passe également sur le Slack. Et un podcast hebdomadaire, donc Renaud qui est avec nous a vécu l'expérience du podcast. Et donc c'est sous format d'interview. Et voilà, on a pas mal de personnes qui y sont passées. Pareil, si ça vous intéresse, on peut en discuter. On a un book club également via le Slack. C'est un club où on parle d'un livre par séance tous les vendredis midi en visio. Et enfin, on vient de lancer une activité de mentorat. C'est pareil, n'hésitez pas si ça vous intéresse d'être mentor ou mentoré. Vous pouvez venir me voir à la fin du meet-up, je pourrais vous en parler plus précisément. Et c'est vraiment là, on l'a lancé lundi. Donc c'est tout frais, tout récent et on a hâte. Et maintenant, je vais laisser la place à Maya, David et Renaud, justement pour nous parler de comment scaler des équipes en IA. N'hésitez pas. Et voilà, c'est très chouette en plus que vous soyez là. Donc, c'est aussi l'occasion de poser vos questions. Donc, il y aura un temps d'échange, il y a un temps de discussion entre nos trois intervenants.

22:32 Et à la fin, il y aura un temps d'échange. Vous pourrez poser toutes les questions que vous avez. Voilà, je vous souhaite un très bon meet-up et je laisse la place à nos intervenants et notre intervenant. Avec plaisir. Et David, je te laisse le micro. Vous nous entendez? Enfin, on vous entend déjà? Parfait. On va attendre que vous alliez nous joindre. Merci Naomi pour l'intro et surtout merci David et Renaud de nous partager aujourd'hui votre expérience sur comment scaler son équipe en IA. Donc en préparant le panel et puis moi en regardant un peu les chiffres, c'est vrai que chez France Digitale, chaque année on fait un mapping des startups en IA.

23:39 On en a l'année dernière qui s'habille un peu plus de 500, mais quand on fait le bien, il y a très peu de scale-up en IA et très peu d'entreprises qui ont vraiment scalé leurs équipes. Aujourd'hui, donc, Preligens, c'est déjà 60 data scientists. Shift Technology, c'est 200 data scientists. Pour en arriver là, il s'est passé plusieurs choses, plusieurs questionnements. Et le but, c'est de partager l'expérience. Donc l'idée, ce n'est pas non plus d'arriver avec une méthode toute faite de comment scaler son équipe, mais plutôt d'expliquer comment eux en sont à l'OELA. Et puis effectivement, l'idée à la fin, c'est de pouvoir poser un maximum de questions. Moi, j'adore quand il y a plein de questions, donc préparez-vous. Moi, très naïvement, c'est la première question que je vous ai posée. C'est quoi la spécificité d'une équipe en IA, par exemple, par suite d'une équipe de soft? Je vous laisse la parole. Comment est-ce qu'il veut? Vas-y, vas-y, comment? Ce n'est pas les mêmes compétences, ce n'est pas les mêmes objectifs. Ça se ressemble. Souvent, un CEO peut informer, peut confier une mission globale à son équipe technique de faire à la fois du soft et de la data.

24:50 En fait, c'est quand même des objectifs, des enjeux très différents. Les complexités ne sont pas au même endroit. Et donc, ça demande des compétences différentes, une organisation. différentes. Software, c'est quelque chose maintenant qui est aujourd'hui assez industrialisé à construire. Il y a des processus, il y a des critères clairs de succès, la qualité, le fait qu'on produise des features régulièrement, que ce soit prévisible, que ça réponde bien aux besoins de l'utilisateur. Et en ce qui concerne l'intelligence artificielle, c'est... D'une part, c'est beaucoup moins standardisé comme domaine, et d'autre part, c'est des problèmes qui sont un peu ouverts, souvent mal formulés. On sait qu'on voudrait faire mieux que ce que peut faire un humain sur une masse de données, ou au moins faire aussi bien, mais à part ça... Il n'y a pas une méthodologie, il n'y a pas des procédés.

25:52 Et donc il faut réfléchir, souvent se poser la question, quel est d'abord le problème qu'on veut résoudre, comment on va s'organiser en conséquence. Et je pense ne pas aborder... Le problème, comme si c'était un problème de soft simple, ça me semble être déjà la première étape. Oui, je pense que tu as dit pas mal de choses. Il y a une histoire de profil déjà, c'est souvent pas les mêmes profils. Il faut faire aussi un petit peu attention au profil, c'est-à-dire qu'il ne faut pas avoir ce biais de vouloir embaucher. Obligatoirement des chercheurs en intelligence artificielle quand on est une entreprise qui fait des produits. Donc ça c'est aussi un biais. Un truc qui change en tout cas pas mal aussi en computer vision, moi je trouve c'est les cycles. C'est-à-dire qu'il faut apprendre des algorithmes, le temps d'aller chercher les données, de les annoter, de lancer de notre reste que le training. Nous un training c'est pour prendre des fois plusieurs semaines, un entraînement d'algo.

26:55 En fait, on a des sites qui sont quand même assez différents, où en software, il y a des gens qui font des releases toutes les semaines, ou même qui mettent en croix de tous les jours, et qui font des sprints d'une semaine. Ça, en IA, en une semaine, en tout cas chez nous, souvent, c'est juste le temps d'annoter les données par la partie annotation. Ok, donc moi ce que je retiens, c'est qu'on n'aborde pas les problèmes de la même manière, ce n'est pas les mêmes cycles de développement. Et donc concrètement, comment ça marche dans vos entreprises? Alors à Shift, depuis le début, on a deux organisations séparées, l'organisation Product et Software Engineering, qui est d'ailleurs mon organisation, et l'organisation Data Science, qui s'occupe... L'organisation Product et Software Engineering, elle construit le produit. Et en général, c'est le cas chez nous, mais ça je pense que c'est courant dans la plupart des boîtes qui font de l'IA, l'IA n'est jamais le produit. L'IA est une composante du produit, et le produit c'est du soft.

27:58 En tout cas, pour... Quasiment toutes les boîtes que je connais. Et le soft, il faut le faire proprement et bien, et selon les bonnes méthodes. Donc il faut une organisation de développement logiciel qui fonctionne. Et il faut pluguer à ça des modèles, des algorithmes, qui eux vont avoir tendance à évoluer, vont avoir des spécificités selon les problèmes à résoudre. Vont avoir des besoins d'entraînement, de calibration, des besoins d'accès à des données qui sont massives, qui sont parfois pas très bien définies. Souvent, la plupart du temps, il y a une organisation data science qui est créée en parallèle, qui doit, à mon avis, ça c'est assez clé quand même, être très en relation avec l'équipe soft et les uns doivent être conscients des enjeux et des besoins des autres. C'est assez... Oui, si chacun travaille dans son coin, en général, c'est plutôt une mauvaise idée.

29:04 Et donc, les développeurs doivent considérer les besoins des data scientists quand ils construisent le produit. Et les data scientists doivent considérer le fait que leurs modèles vont aller en production, ce qui est... Pas le cas quand on fait des études, ce qui est souvent l'expérience du data scientist avant de rejoindre une boîte. Et donc, il doit m'apprendre qu'est-ce que ça veut dire quand on va en production, quels sont les besoins. Pourquoi est-ce que ça doit être robuste ? Pourquoi est-ce que ça doit être performant? Et comment on fait? C'est hyper intéressant et je propose qu'on y revienne d'ailleurs un peu plus tard sur comment est-ce que justement les équipes doivent collaborer parce que c'est un point qui est hyper important. Mais déjà, tu parles de data science. C'est quoi vos profils de data scientist? Parce que si je comprends bien, même dans vos équipes, ce n'est pas tout à fait les mêmes profils. Chacun de votre côté. Toi, c'est quoi un data scientist chez Preligens? Déjà, nous, je crois qu'on n'a pas de poste de data scientist, ou alors je ne sais plus comment on appelle ça. Mais on va avoir trois types de... Donc on a pareil, une organisation IA et une organisation software. Et c'est exactement ça, c'est le produit qui fait le lien entre les deux finalement.

30:08 Et comme tu le disais, en fait, nous, on vend des softwares, on est éditeur de logiciels. Donc dedans, il y a de l'IA, c'est un des composants. C'est un composant qui fait une bonne différenciation sur nos produits, qui apporte beaucoup de valeur, mais en fait, on ne vend pas de l'IA, on ne vend pas de l'information, on ne vend pas de données traitées, on vend un software. Et dans ces équipes IA, on a trois types de profils. Les premiers, c'est ce qu'on appelle les équipes production. C'est ceux qui font des algos. Ils ont un problème à gérer. Ils doivent avoir des données. Et puis, du coup, ils regardent comment ils améliorent les algos, comment ils créent les algos, comment, avec le produit, ils vont traiter les cas spécifiques. Donc, tu sais, nous, on fait pas mal d'images satellites. C'est comment je fais pour améliorer le détecteur d'avion quand il neige, comment je fais pour faire un détecteur qui permet de classifier les sous-marins, etc. Donc ça, c'est la partie production. On a la partie ce qu'on appelle engineering, qui sont des gens qui font des outils pour les autres.

31:14 Donc en gros, ils font ce qu'on appelle notre high factory. Donc c'est tout un cadre software. On les met dans l'IA, mais c'est des gens vraiment à la limite entre du software et de l'IA, ce qu'on appelle machine learning, engineering. C'est des gens qui connaissent à la fois le machine learning, parce qu'ils doivent... Triturer des modèles, faire des pipelines de données, mais qui savent bien coder aussi. Et donc c'est une équipe qui fait des outils, ce qu'on appelle notre usine algorithme, notre iFactory, qui font des outils à destination interne, à destination aussi de contribution interne, c'est-à-dire que le but c'est que les gens contribuent à ces outils, que ce ne soit pas juste une équipe, mais que ce soit un espèce de projet open source interne. Et ensuite, on a les équipes vraiment recherche. On a 12-13 personnes en recherche. Et pourquoi on a des gens en recherche? Parce que des fois, il y a des problèmes qui sont trop compliqués pour être craqués par la production. Donc tout le monde fait un peu de la R&D. En engineering, ils font de la R&D, ils font des cycles itératifs. En production, ils font des trucs itératifs. Mais dans des cycles de release et dans des cycles de développement de 8 semaines,

32:19 Et du coup, des fois, 8 semaines pour craquer un problème ou pour mettre un nouveau réseau en production, c'est un peu trop short. Donc à ce moment-là, ça va à l'équipe recherche. Donc très souvent, on ne commence pas par la recherche. On ne se dit pas, on prend un nouveau sujet et du coup, c'est la recherche qui va faire. Après, on transmet. C'est plutôt l'inverse. On a nos outils avec la engineering. On a des gens qui savent manipuler ces outils et les adapter avec la prod. Du coup, quand on a un nouveau problème, on essaye de traiter ça avec ce qu'on a. Et après, si vraiment on n'y arrive pas, là on va voir la recherche où ils peuvent passer un peu plus de temps, un peu réfléchir un petit peu différemment. Et donc à chaque fois, c'est des profils différents. Et à Engineering, c'est des gens qui sont plutôt quand même... C'est des gens souvent qui ont fait de l'ADA. Data Science et du Code, les deux. Et donc, on a souvent un peu d'expérience. Il y a assez peu de juniors dans ces équipes. La recherche, c'est des profils assez scientifiques, souvent des gens qui font des doctorats, que ce soit en maths ou en physique, qui ont de l'expérience en machine learning. Et à reproduction, c'est souvent un mix entre des gens qui peuvent des fois assez juniors et des gens qui ont de l'expérience pour encadrer et qui ont des profils assez business, c'est-à-dire qui aiment bien aller chez le client, comprendre leurs problèmes.

33:28 Et donc on a ces trois profils qui sont finalement les trois assez différents. Et tu les avais définis tout de suite dans ton organisation ou c'est venu sur le tas en disant tiens on va s'organiser de telle manière? C'est venu un peu sur le tas, naturellement on va dire. Au début on avait un peu de tout mais dans une équipe et puis après il y a des gens qui se sont un peu, on voit qu'ils sont orientés. Notre iFactory elle s'est auto-générée, c'est-à-dire qu'il y a un moment, c'est marrant, quand on était 3-4, et à un moment il y a un gars qui connait un peu mieux que les autres qui a dit mais il faut qu'on arrête là, on va se faire une base de code un peu propre et c'était parti. Maintenant il y a 15 personnes qui bossent dessus. C'est juste une personne qui s'est mis à dire on va normaliser la base de code parce que là à 3 c'est déjà un peu le bordel. Et donc du coup c'est un truc qui est presque auto-généré tout seul, c'est marrant. Quel est le bon sens? Et toi David? Ouais non, je voudrais rebondir là-dessus, c'est très intéressant parce que c'est un bon point de comparaison. Je peux donner notre expérience à Shift.

34:28 Effectivement, on a... On a les trois mêmes types de besoins, c'est-à-dire faire fonctionner les modèles en production, faire de l'ARD pour développer des nouveaux frameworks, des nouvelles classes de modèles sur le long terme et développer des outils en interne pour que les data scientists puissent faire de meilleures choses, faire des choses de manière plus efficace, mieux organiser leur travail. Donc ça, je retrouve complètement ça. Et comme Renaud, je dirais, on a commencé à Shift avec le modèle du data scientist très généraliste, très polyvalent. Je pense peut-être encore plus poussé à l'extrême, puisque... Pour nous, le data scientist va de la... Son rôle à Shift va de la relation client. Et vraiment, la relation client, nous, on est une entreprise qui a 100 clients.

35:29 Donc, c'est vraiment peu pour une entreprise de notre taille. Chaque client a vraiment une relation. On a moins de clients que de data scientists, pour vous dire. Donc, chaque client a une relation privilégiée avec les data scientists qui passent du temps. Au début pour comprendre avec eux leurs données, leurs besoins, leur proposer les meilleurs modèles et ensuite après aussi, une fois que la solution est implémentée, pour suivre les résultats, voir s'il y a besoin de nouvelles améliorations. On est dans un problème où les données peuvent évoluer avec le temps en plus, donc il faut suivre ça. Donc le data scientist a cette responsabilité-là qui n'est pas du tout ce qu'on placerait sous le titre de data scientist intuitivement. Et ça va jusqu'à faire de la recherche scientifique potentiellement complexe sur des temps de plusieurs mois, en passant par toutes les activités plus classiques du data scientist. Donc ça, c'est le choix qu'on a fait. On a recruté des profils.

36:30 assez généraliste. Et comme chez vous finalement, mais peut-être un peu plus tard, un peu plus lentement, on commence à avoir de la spécialisation et on commence à prendre des profils plus juniors pour faire surtout des problématiques de prod. On a, ça on l'a depuis un peu plus longtemps, on a quand même une équipe recherche qui sont vraiment des gens qui ont fait des thèses en intelligence artificielle et qui font que de la recherche, même si on essaye quand même, on fait en sorte que ce soit de la recherche qui finisse par aller en prod un jour, parce que ça c'est important. Donc il y a cette spécialisation, peut-être un peu moins, peut-être je l'expliquerai aussi par... Il y a une certaine friction à trop spécialiser les gens parce qu'on considère quand même que c'est important pour les data scientists, dans leur majorité, d'être exposés aux trois composantes du métier. Si, par rapport à ces trois composantes, quelle est la plus compliquée à recruter?

37:36 Il n'y a peut-être pas de réponse. Chez nous, je pense que c'est la partie machine learning engineering et la partie aussi manager data science parce que je pense qu'il y a, ça n'a pas 10 ans parce que ça avait 10 ans il y a 10 ans, mais ce n'est pas non plus une science très… Ce n'est pas quelque chose qui a 50 ans. Il y a donc des profils qui ont 5-10 ans d'expérience en IA. Soit ils ont créé leur boîte, soit il y en a assez peu mécaniquement par la jeunesse des applications. Les applications qu'on fait à Shift ou à Preligens, à 15 ans ça n'existait pas. Donc il n'y avait pas les formations, il n'y avait pas les... Les personnes. Donc en fait, ça c'est un... Voilà, aller recruter des gens qui ont 10-15 ans d'expérience en IA, c'est souvent un peu le challenge. Et puis sinon, avoir des gens qui ont à la fois des bonnes compétences en IA, mais des bonnes compétences en code, c'est pas le plus facile. Je suis complètement d'accord.

38:41 Machine Learning Engineering et globalement la compétence Engineering, c'est la plus spécifique, celle qui a besoin de la formation la plus longue, qui n'est pas la formation que reçoivent typiquement les gens qui font un master d'intelligence artificielle, de data. Qui n'est pas l'expérience qu'ils construisent non plus s'ils ont fait que des jobs de data scientist. Il y en a qui ont naturellement du talent, mais c'est quand même plus rare. Donc je pense que c'est ça le plus difficile à recruter. Je suis d'accord sur l'aspect management aussi. C'est une leçon qu'on a apprise finalement assez tard dans la vie de shift. Que manager, c'est un métier qui n'est pas forcément toujours lié au succès qu'on aurait pu avoir en tant que contributeur individuel. Et que des fois, il faut attendre que les gens se soient construits cette expérience ailleurs. Pour qu'ils viennent la porter dans une équipe existante.

39:44 Très clair. Tu en parlais tout à l'heure, David. Donc, on voit qu'il y a quand même un peu trois typologies de data scientists qui ne travaillent pas tout à fait sur la même temporalité. Et c'est encore différent quand on s'attaque aux équipes produits, aux équipes soft. Comment ça se passe les relations entre ces différentes équipes et comment tout... Faites en sorte que ça se passe bien. Nous, on a la chance, je trouve, dans nos produits, qu'on arrive à le séparer pas mal fonctionnellement. C'est-à-dire qu'en gros, il y a un software et puis il y a un endroit où on met un docker qui fait des algos. Donc en fait, on arrive un peu à découpler, c'est-à-dire qu'on peut faire des livraisons algo en parallèle de livraison software, des livraisons software en parallèle algo. On a des fois, bien entendu, comme tout le monde, des petits soucis d'interface parce qu'on n'a pas mieux relié la doc ou parce que les gens ne sont pas assez parlés ou parce que ça grossit très vite, etc. Mais paradoxalement, ce n'est pas là où on a le plus de soucis. Mais je pense qu'on a un peu de la chance parce que ça va un petit peu avec nos produits où il y a un flux de données, il y a un endroit où les algos vont détecter un truc, vont enrichir la donnée, puis après ça repart.

40:54 Donc ça peut être assez bien découplé au niveau du software. Je pense qu'il y a des endroits où c'est beaucoup plus compliqué que ça. Et où du coup, nous on fait par exemple ce qu'on appelle des cross-teams, c'est-à-dire des squads où on va prendre un ingénieur, un recherche, un production pour aussi éviter les frictions et les silos. Mais on a moins besoin de le faire entre le software et l'IA. On le fait un petit peu entre l'engineering et l'IA et le software, mais par exemple, les gens en prod, ils arrivent à être complètement autonomes. Mais sinon, en général, nous, on fonctionne comme ça. Quand on voit des sujets transverses, on crée un truc, on va prendre ce qu'on appelle... Les cross-teams, on va prendre des gens d'un peu partout et on va créer une squad, une future team en fait, comme ça s'appelle. C'est pareil chez Shift? C'est pas exactement, je pense, enfin je reconnais certaines choses, mais il y a quand même une différence, quelques-unes, si je peux expliquer un peu.

41:56 À Shift, on a commencé, comme Preligens, à considérer que les développeurs faisaient un framework, un produit sur lequel les data scientists allaient plugger leur modèle. Et donc les data scientists, de ce point de vue-là, étaient utilisateurs du produit que construisaient les développeurs. Et donc l'interface naturelle pour leurs besoins, c'était l'équipe produit. Et ça fonctionnait comme ça. Ce qui s'est passé, c'est que... peut-être qu'on n'a pas fait les bonnes interfaces, peut-être que notre équipe engineering n'a pas grossi assez vite par rapport aux besoins de notre équipe data scientist, on s'est rendu compte que c'était plus simple à un moment de donner la possibilité aux data scientists aussi de contribuer au framework lui-même pour le faire évoluer en fonction des besoins qu'ils découvraient eux, parce que eux finalement, comme je l'expliquais tout à l'heure,

43:00 C'est eux qui sont les plus proches de nos clients, c'est eux qui sont les plus proches de la donnée. Et c'est eux qui savent quelles sont les prochaines features qu'il faudrait au framework pour qu'on puisse encore améliorer les modèles. Et on a fait ça peut-être de manière un peu anarchique au début. Et on s'est retrouvé avec... Un problème qui était, en fait on avait un département qui était au niveau process vu comme des utilisateurs, mais au niveau de la réalité qui était des contributeurs, et qui n'étaient pas eux dans un process de roadmap, dans un process de release, process de priorisation, de définition du besoin. Et là, ça a commencé à partir un peu dans trop de directions à la fois, c'était difficile à contrôler. Donc ce qu'on fait depuis quelques années maintenant, c'est qu'on essaye de réintégrer au maximum les data scientists. Comme étant des parties prenantes de l'équipe produit et non pas seulement utilisateur du produit.

44:01 On n'a pas décidé de fermer l'interface et de dire, bon, on annule ce qu'on avait fait avant. On pense que les contributions des data scientists aux produits sont utiles, qu'ils ont les compétences pour le faire, mais qu'il faut le cadrer. Et donc, ça se fait ensuite de la même manière que vous, en faisant des squads cross-fonctionnels avec des développeurs, des data scientists, un product manager, une roadmap commune, un process commun de release, de QA. Pour avoir cette capacité-là d'avoir directement l'input de la data science, ce qui est précieux dans la construction du produit. Il va falloir. On a parlé du coup des profils et de l'organisation. Maintenant, c'est quoi les outils que vous mettez à disposition des data scientists pour leur travail? Ben non, là, ces fameux... Ce framework qu'on a développé, alors je le retrouve parce que c'est vrai que... Alors nous, ce n'est pas l'outil final, c'est l'outil final. Final, il est livré à plutôt des analystes et des gens de...

45:05 Plutôt vraiment des analystes de renseignement. Mais on a notre outil interne. Et c'est vrai que là où je le retrouve, c'est qu'en fait, on a dû l'ouvrir, c'est-à-dire que cet outil interne, C'est un espèce de framework open source interne où il y a des contributeurs. Il y a quand même une core team qui est la team engineering qui va regarder les PR, regarder certains composants pas ouverts parce qu'il y a des trucs qu'il ne faut pas casser, des choses comme ça, et qui ouvre certaines librairies en se disant que le framework est designé pour de la contribution externe. Et donc ce qu'on a mis à disposition, c'est justement des outils. Alors on essaye de faire toute la chaîne, bien entendu, il y a tout qui n'est pas encore, ça ne sera jamais parfait, mais avec à la fois une partie pour vraiment manipuler les données. Donc ça, c'est hyper important, l'annotation de données, le fait qu'une fois que ces données soient annotées, alors elles ne sont pas annotées par la data scientist, bien entendu, mais une fois qu'elles sont annotées par les équipes d'annotation, tu puisses les manipuler, les regarder, créer des jeux de tests, des jeux d'entraînement, les versionner, etc. Puis après, une partie pour designer des modèles.

46:10 Donc nous, c'est des interfaces très... C'est des YAML, donc c'est des fichiers de configuration, et qui permettent, comme on a standardisé un peu les interfaces, on peut être très très flexible dans ces fichiers de configuration, donc on peut vraiment tout modifier. On a différents réseaux de neurones. On a, comment dire... On a un groupe de 100 000 personnes. On peut changer les couches, le nombre de paramètres, est-ce que c'est du spatial pooling ou pas. Je ne dirais pas quasiment tout, mais vraiment très customisable, sans faire de ligne de code. Et après, on a une partie aussi qui permet de chaîner tout ça. C'est-à-dire que le modèle d'IA, c'est une des parties du process qui vont prendre à la fin. Donc tu peux mettre deux modèles, faire de l'ensemble, lier ensemble, après mettre un post-pro, un pré-processing, un truc comme ça. Puis une fois que tu es content, tu appuies sur un bouton et tu packages le truc dans un docker qui va en production. Donc on essaye de faire vraiment le plus possible toute la chaîne sans rupture de charge, de la du test à la mise en production. Alors aujourd'hui, en fonction des données que tu fais, comme on ne fait pas que de l'image, il y a des fois un peu de rupture de charge, mais on essaye de...

47:17 La vision, c'est ça. C'est vraiment de bout en bout. Tu as une librairie de process que tu peux designer, que tu peux tester, que tu peux modifier. Et puis une fois que tu es content, tu appuies sur un bouton, ça teste sur des données de test. Si tu es content de tes tests, tu en vends pas de quoi. Et chez Shift? Et chez Shift, on a deux types d'outils qu'on fournit à nos data scientists. Il y a les frameworks qu'on développe nous-mêmes et qui sont très métiers, qui sont plus spécifiquement ceux qu'on a identifiés comme étant nos côtés différenciants. Et donc c'est d'abord un framework de transformation de données, parce qu'à Shift on ne traite pas des données dans un format standard, on traite des données de nos clients sous quelque forme qu'elles soient. Donc déjà il faut les mapper. Ensuite on a des frameworks de reconstruction d'entités qu'on trouve à différents endroits, où il faut retrouver qui est la même personne à tel autre endroit.

48:21 Et un framework de détection de fraude sur lequel les data scientists peuvent construire des modèles, mais des modèles qui sont spécifiques, standardisés, par rapport à la façon dont on fait la détection. Tout ça, on l'a construit et ensuite, ils sont configurables par modèle, par géographie, etc. On a par-dessus ça rajouté d'autres outils qui ne sont pas des outils qu'on a développés nous-mêmes, soit parce que ce sont des choses vraiment commoditisées de nos jours et donc ce n'est pas stratégique de les développer. Un outil de data vise commercial. Qu'est-ce qu'on a d'autre? Un outil... Enfin, on a... On en a quelques-uns comme ça, un outil de labellisation de données à partir d'échantillons. Et aussi des plugins un peu dans nos frameworks originaux pour apporter la possibilité à nos data scientists de ne pas se baser uniquement sur la façon dont on a défini le framework à la base, mais d'intégrer, là un peu comme vous, des modèles, notamment

49:29 en Python, parce que notre technologie de base, ce n'est pas Python, c'est C Sharp, où là, ils peuvent importer un pickle, et ce pickle est encadré par toute une batterie de choses qui font que si ça casse ou si c'est en production, ça ne posera pas de problème. Par contre, à l'intérieur, ils peuvent avoir calibré le modèle qu'ils veulent, et donc ça leur donne cette liberté-là. Et comment vous faites le choix de ces outils justement? Il y a les personnes en interne qui sont chargées de les choisir? Est-ce que vous faites justement de la... Veille, comment ça se passe ? C'est assez naturellement, je dirais, parce que c'est vraiment les besoins, on les découvre finalement au fur et à mesure de notre progression dans la construction de nos produits, dans la compréhension de ce que veulent nos clients. Et à ce moment-là... La question remonte assez rapidement à tous les niveaux de l'organisation parce qu'on voit qu'il y a un manque ou on voit qu'il y a un besoin.

50:31 Donc la question après qui peut se poser à nous exec, c'est pas que moi, c'est aussi notre chief data scientist, notre chief product officer, c'est est-ce qu'on construit quelque chose pour ça? Est-ce qu'on prend quelque chose d'existant d'open source? Est-ce qu'on achète quelque chose? Bon, ça c'est des décisions que... On fait régulièrement, on commence à avoir l'expérience. Il y a plein de bouquins qui ont été écrits sur est-ce qu'il faut acheter ou construire. Ce n'est pas moi qui vais révéler la vérité là-dessus, mais c'est assez classique. Est-ce que tu as envie d'ajouter? Oui, on ne fait pas tout nous-mêmes, même si les ingénieurs adorent tout refaire. Je me bats pour que des fois ils achètent des trucs, donc on arrive à acheter ou à intégrer des boucles qui existent déjà. Mais nous, on a carrément mis un produit manager. On a un produit interne, on a un head of product, Terry Factory, avec deux produits managers. Et donc le rôle, c'est de gérer ça comme un produit. Alors avec des utilisateurs internes, mais c'est comme un produit, il y a des releases, on a clairement mis un produit dessus.

51:38 Je pense qu'on va bientôt passer aux questions. Moi, j'ai une dernière question un peu naïve, mais quand vous avez un outil soft en production, comment est-ce que vous embarquez l'IA? Puisque ce que je comprends, c'est quand même deux cycles hyper différents. Comment est-ce que vous arrivez à embarquer l'intelligence artificielle dans un produit qui est déjà en prod? Pour moi, et là je pense que ça dépend aussi de à quoi sert le soft, Nous, c'est vraiment une composante d'un outil software plus large. Et donc, l'IA donne, highlight des résultats, mais ces résultats peuvent être investigués, analysés dans une interface web qui est une web app SaaS. Et au fond, le plus important, c'est que cette web app, elle marche. Et même si l'IA, elle donne des résultats faux, personne ne va mourir. C'est mieux si les résultats sont justes, mais tout le monde sait que l'IA n'est pas parfaite. Donc, à partir de là, le plus important, c'est que les modèles qui sont embarqués en production, un, ils ne cassent pas, deux, ils ne soient pas trop lents. Et donc, pour moi, la chose la plus importante à faire, c'est d'encadrer ces modèles dans des frameworks, dans des containers, dans des technologies

52:52 qui permettent de dire, à un moment, j'ai... Presque une boîte noire, je lui pose une question, elle me répond, je lui fais confiance. Elle ne me répond pas, je ne sais quoi faire. Elle me répond trop lentement, je ne sais quoi faire. Et même d'ailleurs, cette boîte noire, si à un moment elle est complètement cassée et que ça nous embête, éventuellement, ça nous est arrivé, un data scientist va pouvoir faire tourner quelque chose à la main et sortir des données. Ce qui est, tant que le software derrière marche, le client est content. Ça, c'est notre position. Nous, c'est un peu différent parce que... Alors déjà, comme on fait de la défense, renseignement, quand tu dis si le modèle se plante, personne ne meurt, nous, on n'est pas à ce niveau-là. C'est vrai que quand même, on a des fois des sujets où il faut que ça marque. Donc, au niveau logiciel, pour que ça marche, c'est le boulot de la iFactory.

53:56 C'est-à-dire que ce n'est pas un data scientist qui met un modèle en prod, c'est qu'il paramètre son modèle et quand il est content, c'est la iFactory qui paquette le prod. Après, une fois que les interfaces sont bien définies et bien respectées, il y aura toujours un moment où l'ingénieur va changer l'interface sans prévenir les autres, que ça ira assez en test, ça arrive toujours. Mais en général, ça ne se passe pas. Donc on va dire au niveau logiciel, ce n'est pas hyper compliqué. Par exemple, ce qui se passe, c'est en effet être sûr que ça marche. Et surtout avec nos clients, pour être sûr que ça marche, pour ne pas les déplacer. Il faut prendre la voiture, passer les portes, les gardes, les machins, et se mettre devant le PC avec l'analyste. Et en plus, pour ressortir même l'info que ça marche ou pas, après, tu ne peux pas la ressortir comme tu veux. Donc c'est tout un process. Nous, c'est plutôt l'idée par... Alors, les data scientists participent à ça, mais en fait, c'est l'idée aussi par deux équipes. C'est bien entendu les équipes produits, puis aussi des équipes qu'on appelle sales support.

55:00 Qui sont des équipes aussi avec des anciens de la défense, des experts, des gens qui ont un mix entre une composante client et une composante technique. Et qui sont vraiment capables de passer beaucoup de temps avec les clients pour comprendre avec les product managers c'est quoi les spécificités, c'est quoi les problèmes. Donc un peu du customer success, on peut appeler ça. On a des noms à chaque fois, je ne sais pas pourquoi on a des noms différents pour des trucs que tout le monde appelle toujours pareil, c'est peut-être le côté défense. Mais du coup, ça c'est beaucoup de travail chez nous et c'est des équipes qu'on essaie de renforcer. Avoir des gens qui sont vraiment avec le mec en uniforme et qui regardent ça marche, ça marche pas et puis qui vont réfléchir à du coup aussi et la différence par exemple les product managers c'est qu'en fait le customer success ou le sales support il est derrière l'utilisateur et dit ça marche, ça marche pas et en fait nous le produit, c'est qu'on n'a pas un seul utilisateur, il va arriver à faire une vision avec ça parce que tu as

56:08 l'utilisateur en uniforme, mais tu as aussi le colonel, le général, puis le général de l'autre pays, puis la vision de la DGA, par exemple, ou la vision des... Donc c'est tout un système très compliqué, il y a les forces, les acheteurs, et donc en fait il faut consolider ces visions des différentes personnes pour qu'à la fin quand même la personne en uniforme derrière le PC soit aussi contente. Mais qu'eux, à la fin aussi, se soient achetés. C'est pas la personne en uniforme, d'ailleurs, le PC qui met sa carte bleue. C'est pas comme ça que ça... Le sous-officier, il n'a pas la carte bleue du ministère des armées pour acheter les logiciels. Certains diraient malheureusement, je ne sais pas comment ça se passerait. Mais du coup, il y a tout ce sujet qui est vraiment complexe. On a tout le sujet, le customer success produit qui permet de faire ça. Ce n'est pas que le data scientist parce que lui, il va se perdre un peu. Il est clair. Merci, moi je trouve ça passionnant. Est-ce qu'il y a des questions? Je ne sais pas s'il y a des questions aussi en ligne peut-être? Alors, là, il y a une question dans la salle. Alors, si tu ne peux pas, je pense que c'est une question, c'est un email, c'est bon, c'est pas de...

57:13 Et quel kit tu fais et à l'entraide que tu vas rencontrer en faisant une architecture de la salle sur le site? Alors oui, on est quasiment qu'en on-premise. Quand on a des clouds, c'est plutôt pour de la démo. Et du coup, c'est du cloud qu'on gère comme du on-premise. C'est-à-dire qu'on fait très peu de services hostés. Les avantages, il n'y en a aucun à part qu'on peut vendre. Mais sinon, honnêtement, si je fais une boîte sur un B2C ou du B2B qui n'est pas sensible, Moi, j'utiliserais des services hébergés, que ce soit de OVH, Amazon, n'importe qui. Je dirais que c'est presque... Quand on voit la puissance des services hébergés, c'est dommage de ne pas les utiliser. Donc nous, on en utilise des fois un petit peu pour du dev, mais même des fois, il y a plein de choses qu'on est obligé de développer sur des trucs français ou des trucs hébergés. Donc en fait, les avantages, il y en a qu'est-ce qu'il y en a très peu. Les inconvénients, c'est vrai que ça rallonge beaucoup les cycles de développement, ça complexifie sur beaucoup le test. Parce qu'en fait, on a des maquettes, mais c'est très dur de tester la prod pour nous.

58:23 Parce qu'en fait, rien que les données, on ne peut pas les avoir ici. Rien que la manière dont ils fonctionnent, des fois, on ne sait pas vraiment comment ils fonctionnent, ou ils ne nous disent pas, ou ils ne veulent pas nous... Et puis des fois, ils changent. C'est-à-dire que si vous suivez l'activité géopolitique, il y a un an ou un an et demi, pour les forces françaises en particulier, la grande problématique, c'était ce qu'ils appellent la BSS, donc tout ce qui est Mali, Burkina Faso, etc. Maintenant, je ne dis pas qu'ils ont oublié cette partie-là, mais maintenant, le focus, ça va être plutôt l'Ukraine, etc. Donc rien que le fait de changer de manière fonctionnelle, ça va changer. Ils ne vont pas mettre les données pareilles, ils vont en mettre plus, ils vont en mettre moins, ils vont mettre différents types de données. Donc les trucs qui marchaient avant vont se retrouver à péter maintenant ou des choses comme ça. Et ça, ce n'est pas un truc qu'on peut simuler. On peut le simuler plutôt à postériori, quand on va aller voir, on dit ça, on a essayé ça, ça ne marche pas. On ne savait pas que vous alliez faire ça, nous non plus, mais on ne savait pas que Vladimir Poutine allait se réveiller à un moment et dire je vais envahir l'Ukraine. Donc il y a tout ça qui change et je sais que c'est assez compliqué.

59:26 Mais du coup, il faut être très rigoureux dans les thèses, dans la manière dont on développe, dans les scénarios, etc. Pour que ce soit le plus fiable possible. Pour les gens qui sont en distance, on n'entend pas forcément les questions. Ah oui. Allez, répétez, bien sûr. Pardon. On va commencer par toi. Tu vas enchaîner. Merci Maya pour la qualité des questions et pour la qualité des réponses. Ça ne m'a pas fait peur, les questions, mais je choisis une. Comment vous gérez... tous les deux, la qualité sur le long terme, du point de vue des équipes d'Atatios. Alors, je vais répéter la question. Comment est-ce que vous gérez la qualité des équipes sur le long terme en data? Et moi, il y a deux choses. Et deux choses. La première chose, c'est comment ça flotte du client jusqu'à la clientèle. C'est vraiment du problème. C'est ça, on va parler un petit peu sur les questions de succès. Et justement, comment en fait l'équipe réagit?

1:00:27 Et deuxièmement, sur la performance, plus en rapidité ou vraiment en performance sur des algos, comment vous gérez ça? Tu veux dire, quel est le flot d'informations? Comment se passe l'information? Comment est-ce que l'équipe IA réagit? Du front client jusqu'à l'équipe IA. Oui. Et je n'ai pas fini de dire. Et la performance. Et la performance, d'accord. Je pense qu'on va avoir des réponses assez différentes. Parce que nous, justement, à l'inverse de Preligens, on n'est pas on-premise. On a accès aux données de nos clients, on a accès aux résultats aussi de leurs investigations, qui sont les feedbacks qui reviennent. Pour donner si le résultat de notre algorithme était bon. On a du monitoring en place sur la performance en temps, sur le nombre de temps d'indisponibilité, le nombre de bugs. On traque tout ça. Parce que finalement on peut le mesurer nous-mêmes.

1:01:30 On a seulement besoin de l'input du client sur les alertes qu'on leur donne, par exemple, en détection de fraude, où ils disent ça c'est suspect, ça c'est pas suspect. Ils le font naturellement parce que c'est dans leur process d'investigation, ils doivent le faire. Donc ensuite, on traque ça et on en discute de manière très transparente avec chaque client. Et on a une visibilité aussi agrégée au niveau géographique et au niveau mondial. Et c'est ça qui nous permet ensuite de piloter les investissements de l'équipe. Et Data Science et Engineering d'ailleurs, parce que des fois, les solutions ne sont pas toujours côté Data Science. Nous, c'est un sujet hyper stratégique, la performance, pour plusieurs raisons. Déjà, on ne peut pas la monitorer facilement. Il y a un sujet où il faut être sûr qu'on n'a pas l'impression que ça marche, puis quand on va chez le client, ça ne marche pas, parce qu'on n'a pas les mêmes données, etc. Et c'est un sujet aussi de perception, parce que... On va dire, on a toujours quelqu'un qui va nous dire, un client qui va arriver, qui va regarder des trucs, il rate une voiture sur un arbre, il se dit ça ne marche pas votre truc.

1:02:32 Je crois que c'est bon, on l'a tous vu ça. Et du coup, à la fois on teste beaucoup chez nous sur des données qui ressemblent, etc. À la fois on fait un gros travail avec les clients, que ce soit un travail d'éducation et d'apprentissage, pour dire bah oui c'est normal qu'on n'ait pas 100%, l'humain pas 100%. Et du coup, comment on qualifie la performance? Chez nous déjà, il y a beaucoup d'automatisation, on a des jeux de tests qui ressemblent le plus possible à ce qu'on imagine être ou à ce qu'on sait être des clients, mais ce n'est pas leurs données, ce ne sont pas des données classifiées, etc. Il y a tout un travail qu'on fait même avec eux, qui est de dire, on va définir un protocole de test sur vos données. On va aller voir, il y a toute une partie de la direction générale de l'armement qui est en charge de qualifier les matériels d'armement. Donc quand ils reçoivent un rafale, ils vont le qualifier, ils vont être sûrs qu'il marche bien. Quand ils reçoivent une frégate, ils font pareil. Maintenant, on est en train de construire avec eux, parce que c'est un truc un peu nouveau, comment on fait quand on reçoit de l'IA pour faire la même chose. Donc vraiment de la qualification technique, de la qualification client. Donc c'est vraiment, nous on a notre fameux sujet rapport de perfos, où à défaut on passe, il y a trois personnes sur trois mois qui vont travailler sur des rapports de perfos avec le client et qui vont faire que ça.

1:03:42 Pour diffuser ensuite ce rapport de performance interne dans le ministère des armées ou dans les ministères, parce qu'on a travaillé exactement la même chose à l'étranger, on a exactement les mêmes sujets. Donc c'est un sujet, on va dire, comment on le traite, on met beaucoup d'efforts dessus et on le co-construit avec le client. Et donc il y a vraiment aussi de la conduite du changement, parce que c'est normal que, moi je suis un opérationnel, je n'y connais rien à l'IA, ce n'est pas mon métier, Je mets des données, je vois qu'il y a un truc qui est raté, je dis c'est quoi ce truc? Moi j'ai besoin que ce truc-là soit détecté. Donc comment on adapte le fonctionnement des produits? Comment on fait de la condition de changement pour expliquer? C'est normal que des fois, même si c'est très rare le plus rare possible, des fois si tu mets une image qui est dépointée avec de la neige, du brouillard, du vent de sable, et que c'est un IA, un nouvel avion russe qui vient d'être créé, c'est normal que des fois il puisse être raté ou pas bien identifié. Pourquoi? Comment on le traite? Comment on fait le jour dans le produit pour que ça, ce n'est pas grave? Comment vous travaillez pour être sûr que quand vous travaillez, ça ne soit pas très grave et on puisse le corriger à la volée et puis le remonter?

1:04:48 C'est tout un process et nous, ça nous prend beaucoup d'énergie. Donc la recette, c'est vraiment la co-construction avec le client qui a impliqué les utilisateurs, le technique, la qualification. Tout le monde chez le client. C'est vraiment quelque chose d'assez compliqué et qui demande beaucoup de travail. Je voudrais juste peut-être rajouter un point pour quand même rapprocher nos points de vue là-dessus. Je suis complètement d'accord, y compris quand on a accès aux données, accès au monitoring, accès aux résultats, qu'il y a toujours quand même une partie du monitoring de la performance des algos en particulier, qui est de la négociation. Parce que c'est très rarement, ou peut-être jamais, objectif. Et nous aussi, on a des cas où nos clients vont nous dire, mais ça, parlons de détection de fraude, ce cas-là, vous ne l'avez pas trouvé, alors que c'est évident que c'est de la fraude. Donc, malgré tous les autres trucs que vous avez trouvés, c'est nul. Ça, c'est un exemple. Mais il peut y en avoir d'autres.

1:05:49 Il peut y avoir aussi, nous, on donne une alerte, c'est clairement suspect, mais le client qui est dans une... Par exemple dans une optique de négociation avec nous pour faire baisser les prix, va dire non ça c'était pas suspect, c'est pas une alerte pertinente. Et la fraude c'est pas, il n'y a pas de mesure objective de est-ce que c'était de la fraude ou pas, autre que si l'assureur va investiguer. Donc s'il décide de ne pas investiguer parce que c'est pas suspect, c'est lui qui a raison. Donc on a aussi une phase de discussion, négociation, éducation, accompagnement des utilisateurs pour s'assurer qu'ils utilisent et qu'ils comprennent correctement la valeur et la valeur. façon de travailler avec ces données et ces résultats. Pour revenir, l'intérêt, c'est que nous, quand même, on peut un peu factualiser. Donc, quand on nous dit que ça ne marche pas bien, on revient et on dit, attends, on a testé avec la qualification du ministère des Armées, ça marche à 95%. Donc, là, on a un cas qui est important qui est raté, mais on est quand même dans les 5%, ou 97%, en fonction des cas.

1:06:54 Et du coup, aussi, il y a le côté réactivité, c'est-à-dire que... Nous, ce qu'on fait, c'est que quand on voit des cas qui ne marchent pas, comme on essaye d'être assez réactif et de leur livrer les lierments, on leur dit, dans la prochaine release, on va essayer de le traiter. Et ça, c'est assez important dans nos domaines. C'est-à-dire que nous, on a un domaine où, je pense que le cycle en V, il a dû être inventé par les armées ou le DOD américain. C'est-à-dire que c'est les trucs qui sont spécifiés en 1990 et qui arrivent en production en 2030. C'est typiquement les armées. Ce n'est pas que les armées françaises, c'est toutes les armées. Et du coup, nous, on arrive à faire des livraisons régulières tous les trois mois. Alors, on va étendre un peu parce que trois mois, il disait que c'était trop fréquent. Donc, on va faire tous les six mois maintenant. Mais déjà, ça, ça permet de leur dire, OK, là, on a un problème. Du coup, on va le régler, en fait. On va aller chercher des données, on va aller chercher le truc, on revient vous voir, on vous fait une nouvelle liste note, on revient vous voir, on essaie de régler le problème. Et ça, déjà, ça détend vachement l'atmosphère. Parce que dans notre industrie, ils ont quand même l'habitude d'avoir...

1:08:00 des logiciels, des technologies qui sont... Où en fait pour régler un problème, il faut sortir un million. Et nous on arrive à fonctionner de manière agile, à fonctionner en construction, et ça c'est vachement apprécié. Il y a plein de fois, un de nos logiciels de cartographie, honnêtement la première fois qu'on l'a livré, ça ne marchait pas. La vérité, les gars, ils disaient, on avait des gens en face qui étaient vraiment hyper bienveillants, donc c'était hyper cool. On est arrivé, on a livré la première fois, ils nous ont dit, c'est très bien, c'est un bon début. Honnêtement, là, ça ne nous sert à rien. Tel quel, ça ne nous sert à rien, mais c'est un bon début. Du coup, trois mois après, on est revenu. Maintenant, ça leur fait gagner 90% de temps. Donc, c'est vraiment, on a réussi à apporter cette co-construction, ce côté agile, et ça, c'est aussi hyper important. Si on leur livrait des trucs, on leur disait, ça, c'est comme ça, puis si vous voulez, on revient dans 10 ans pour faire la version new generation, NG, ça, ça ne passera pas, quoi, pour lire. Est-ce qu'il y a des clients qui n'acceptent pas cette erreur qui est normale dans l'intelligence artificielle, ce taux d'erreur, et qui, du coup, vous font fermer la porte au nez en disant« En fait, trouvez quelque chose de parfait.

1:09:08 » Vous arrivez toujours à faire ce travail d'évangélisation. En ce qui nous concerne, globalement, oui, on y arrive toujours. On a développé aussi des méthodes pour faire ça. Ça passe par un business case. Si je prends la détection de fraude, qui est un de nos produits où c'est probablement le plus facile, il y en a d'autres où c'est un peu plus compliqué, ils nous payent un certain... un montant pour acheter une solution qui va leur détecter un certain autre montant de fraude. Et en quelques semaines, on peut voir combien ça va leur apporter par rapport à combien ça leur coûte. Et là, c'est assez convaincant en général. Donc ça, c'est facile. Il y a d'autres cas où le retour sur investissement n'est plus d'ici à mesurer. Il faut travailler un peu plus. Mais tant qu'on a un business case, même si ce n'est pas parfait, c'est là qu'on apporte, je pense, de la valeur. Il y avait d'autres? Question. Il y en a trois même. Je vais commencer par monsieur Alinette. Où est-ce que tu places la responsabilité de l'interprète?

1:10:36 Qui va avoir ça? Où est-ce que tu places la responsabilité de la performance dans les équipes, notamment en termes de performance de temps? Nous, c'est le produit. C'est-à-dire que le produit, il a des requirements clients qui sont la performance, le temps de calcul, des fois la déployabilité, parce qu'il y a des trucs qu'on va mettre plus ou moins proche du capteur, plus ou moins proche des op-eds en fait. Et du coup, il y a des spécifications. Les spécifications sont bien entendu, les techs doivent suivre ces spécifications, doivent essayer de trouver des solutions. Mais à la fin, c'est le produit qui est responsable de son produit. Donc c'est lui qui doit s'assurer, ou pas, parce que des fois, on nous demande de violer les lois de la physique, c'est rare, mais ça arrive toujours. Donc on essaie de trouver le bon compromis. Mais pour moi, c'est le produit. C'est le produit qui est responsable de son produit. Je suis d'accord avec ça. J'ajouterais que le produit est responsable et ensuite c'est très important que...

1:11:41 Engineering et Data Science co-construisent les solutions aux problématiques de performance compliquées. Parce que si on essaye de résoudre ça d'un côté ou de l'autre, en général, soit tu demandes aux ingénieurs, ils vont te construire un truc très rapide, mais qui ne peut pas exécuter des modèles très intéressants. Tu demandes aux data scientists, ils vont vouloir mettre les modèles les plus compliqués du monde. Ensuite, les ingénieurs vont te dire, OK, mais si on fait ça, ça va prendre 15 secondes d'exécution et il n'y a aucune autre solution. Et le seul moyen, c'est de se mettre ensemble et de co-construire une solution qui est... Qui rentre pile dans le créneau de temps alloué, mais qui permet quand même de faire des choses sympas. C'est de la négociation fine qui ne peut se faire qu'ensemble. Alors, peut-être que tu as essayé de poser ta question. Soit toi, avec le cube violet. Je suis désolée, je ne sais pas vos prénoms. Moi, j'avais une question plutôt sur l'évolution du voyer dans vos équipes et surtout, par exemple, sur le métier d'athléticiste.

1:12:46 Je pense qu'avec la robotisation des technologies d'IA, c'est un métier qui peut probablement être amené à évoluer. Donc, comment est-ce que vous l'avez en train de faire dans vos équipes? Comment est-ce que vous les accompagnez? Du coup, comment est-ce que vous voyez évoluer vos équipes? Métis, dataté, artiste. Je peux faire une petite réponse, mais déjà, moi je trouve que la commoditisation des technologies d'IA, je ne la vois pas beaucoup. Enfin, un peu, mais franchement, ça reste vraiment, vraiment compliqué. C'est-à-dire que pour faire aujourd'hui, pour faire sur un cas d'usage business, pour apporter vraiment de la valeur au client, il y a, en tout cas dans nos domaines, mais même dans les autres domaines, il n'y a pas beaucoup de domaines métiers où tu peux juste prendre un modèle sur SageMaker ou sur Gameface, le packager, le mettre en prod et ça marche.

1:13:48 Malheureusement, et je dirais malheureusement parce que si on avait ça, ça serait vachement plus simple de faire le business. Donc déjà, il nous reste beaucoup de boulot de R&D pour prendre, même le NLP qui est quand même vachement plus commoditisé que la computer vision. nous, quand on prend sur nos cas d'usage, il faut l'adapter. Donc il faut entraîner, il faut faire de la discrétion, il faut faire des choses comme ça, parce que tel quel, les modèles ne suffisent pas. Il faut le packager, il faut tout. Et sur le computer vision, je trouve ça encore plus grand. Donc déjà, il y a quand même du boulot encore. Et au niveau de l'évolution, je pense que de plus en plus, justement, il va y avoir de l'adhérence entre le métier de la data science et le software. On avait beaucoup, il y a 10 ans, un data scientist, c'était... quelqu'un qui était bon en maths, qui faisait un peu des notebooks, et qui était surtout un spécialiste de la donnée et de maths appliquées. De plus en plus, ça va être quelqu'un à la fois qui va utiliser des outils internes, mais qui va aussi les faire évoluer, les modifier. Donc, il va être un spécialiste de la donnée, quelqu'un qui est bon en maths, mais aussi quelqu'un qui sait coder correctement, qui sait utiliser des dockers, qui a des enjeux de l'ingénierie, qui est en fait un AI ingénieur plus qu'un data scientist.

1:15:00 Moi, c'est comme ça que je veux évoluer. Complètement d'accord. Pareil, je ne vois pas dans notre domaine, ni dans notre domaine, les data scientists être remplacés. À court, moyen ou même long terme par des solutions existantes. Je pense qu'il y a vraiment une finesse de la compréhension de la problématique, de la compréhension du domaine qui sera irremplaçable pendant longtemps. Donc, je n'ai pas l'inquiétude de me dire qu'est-ce que vont faire mes data scientists quand ils n'auront plus de travail. Par contre, et comme Renaud là encore, ce que j'aimerais par rapport à ce qu'on décrivait tout à l'heure où il y a trois composantes du métier, plus on peut les éloigner des problématiques de production, plus on peut les amener à faire de l'AI engineering ou de la recherche et développement de plus grande ampleur, plus ça aura de la valeur. Et pour ça, ce qu'il faut, c'est faire du meilleur engineering.

1:16:02 C'est un cercle vertueux, mais je pense que c'est ça la direction dans laquelle je vois l'évolution. Et je pense qu'aujourd'hui, au niveau des formations, il y a beaucoup de formations de data science qui sont en fait finalement des formations, je dirais, diathéoriques. Et je pense que je discutais de ça avec des profs de Supélec. Et je pense que ça serait intéressant qu'il y ait des formations d'IA appliquées. Comment je manipule un Docker? Comment je manipule Python? Comment je gère des librairies? Pour qu'un data scientist qui fasse de la data science, il soit aussi dans un contexte où il le fasse de manière directement productive. Aujourd'hui, il n'y a pas un développeur qui ne sait pas utiliser Git, qui ne sait pas utiliser... Normalement Docker, ce genre de choses, il n'y en a pas beaucoup. Pourtant, ce n'est pas des DevOps, c'est juste des développeurs front, mais je sais utiliser GitHub, je sais utiliser un petit peu AWS, je sais utiliser un peu Docker. Ce n'est pas encore rentré dans tous les mindsets pour les data scientists, mais je pense que ça va arriver très naturellement, où en fait, un data scientist qui ne sait pas manipuler un petit peu de Python ou un petit peu de Docker, je pense que dans 5 ans, ça n'arrivera plus.

1:17:14 Je crois que tu avais une question. Moi, j'avais toujours une question. Moi, j'avais une question sur la gestion de la connaissance. Comment gérer la connaissance de certains des gars? Je me disais que dans la factory, il y a des manières de loguer les scans, des choses comme ça, des paragraphe. Quels sont les spécificités qu'il y a dans le partage de la chaîne? Comment est-ce que vous gérez la connaissance de vos équipes? Et en même temps, en compétences. Oui, pour nous, en tout cas, je ne le vois pas de manière différente entre l'IA et les autres parties du métier, notamment le software engineering. Par contre, ce n'est pas un problème simple, quel que soit le secteur. Parce que nous, on a des solutions très classiques qui sont de faire de la documentation, faire du training. Le problème, c'est de trouver le temps et d'avoir les gens qui ont envie de le faire.

1:18:17 Donc, il faut donner cette dynamique, cette énergie, on le fait. Et ça marche, mais c'est quelque chose qui doit être poussé. Les gens ne le font pas spontanément. Mais on ne traite pas ce problème spécifiquement parce que c'est de l'IA, de notre tête. Il y a quand même des outils qui permettent, quand tu as une arrive factorielle, tu peux mettre la connaissance codée dedans et donc quand il y a un nouveau qui arrive, il a directement... Un petit peu de savoir-faire. Après, comme tu dis, ce n'est pas du tout un sujet simple. Nous, on bosse beaucoup sur les onboarding. Un des sujets qui n'est pas simple chez nous, c'est aussi la connaissance client, parce qu'il y a des fois des trucs, c'est dans un carnet chez le client, dans un coffre-fort, et tu ne peux pas le sortir. Et ça, ce n'est pas toujours très simple. Et donc ça passe par les onboarding, par des formations sur les produits, par le fait que quand tu arrives sur un nouveau produit, il y a quelqu'un qui te transmette le savoir, etc. Mais c'est de façon quelque chose d'assez...

1:19:17 C'est relativement complexe. Et les bases de connaissances et documentations, c'est vrai que... Moi, je n'ai pas encore craqué le côté comment tu forces un peu tout le monde à le faire naturellement, sans dire vous avez une base de connaissances, vous êtes obligé de rentrer des trucs dedans, ça t'oblige, les gens ne le font pas. Je n'ai pas encore trouvé la solution. J'essaye le plus possible que ce soit dans le code, comme ça quand c'est dans le code, c'est sûr que ce n'est pas perdu. Mais cet onboarding, chacun est un peu obligé d'onboarder ses collaborateurs ou est-ce que vous avez un peu des personnes clés dédiées qui vont justement veiller à ce que la formation se fasse en interne? On a des onboardings de boîte gérés par les HR assez complets et après chaque équipe a un onboarding. On peut spécialiser. Avec des documents mis à jour, ça, pour le coup, c'est pas un choix. Pareil chez nous et entre autres, dans l'équipe Data Science, on a un onboarding que je trouve très bien, puisque chaque data scientist va être amené à travailler sur

1:20:22 une problématique et un dataset de clients à un moment ou à un autre dans sa carrière à Shift, et souvent plusieurs, les premiers deux mois sont passés dans ce qu'on appelle un mini-build. En fait, ils ont une simulation d'un client, un dataset, un... Une problématique et ils résolvent le problème avec les outils de shift comme les 200 data scientists avec eux ça n'apporte aucune valeur à un client réel parce que c'est un faux client par contre ils apprennent en faisant et en demandant à leurs collègues comment est-ce que comment est-ce qu'on fait le data science à shift J'espère qu'il y a assez de questions. Comment est-ce que vous réfléchissez? Est-ce que dans la chaîne armée, on parle de la chaîne sous temps, c'est une autre chose? Et comment vous en partez de l'équipe? À la frontière, on n'est pas forcément à la frontière, mais est-ce que ça vient à l'explication de la chaîne sous temps?

1:21:28 Est-ce qu'il y a des temps, des temps de réfléchir à ce que l'on fait? Comment est-ce qu'on arrive à la chaîne sous temps? Tu veux répéter la question ? Elle est assez longue la question. Comment est-ce que vous avez fait que vous êtes dans un domaine qui évolue très très vite? Alors, évidemment, on fait de la veille à Shift. On a des chercheurs notamment qui lisent beaucoup d'articles scientifiques et puis des data scientists qui se tiennent intéressés. On reste connecté avec l'évolution du secteur. Maintenant, Ce n'est pas la course à la dernière innovation, en tout cas chez nous. Ce qui est important, c'est le résultat. Le résultat n'est pas forcément donné par le modèle le plus récent, même s'il a donné des super résultats sur une autre problématique. Il faut appliquer le bon modèle pour le bon problème. Des fois, le bon modèle, il est hyper simple.

1:22:31 Et donc nous, on n'est pas une boîte qui... On ne vend pas le fait que vous allez avoir la dernière innovation, on va dire, on vend le fait que vous allez avoir le meilleur résultat possible pour détecter de la fraude ou pour automatiser la gestion sinistre, ou pour d'autres problématiques dans l'assurance. Donc, ce n'est pas la course de ce point de vue-là. On surveille, on regarde s'il y a des choses intéressantes, on les teste et on prend le temps de le faire. Mais on n'a pas l'impression qu'on va se faire dépasser par quoi que ce soit, parce qu'on est aussi confiant dans les modèles qu'on a. Et on sait qu'on peut les mettre à jour si jamais il y a des choses pertinentes qui sortaient. C'est un peu pareil, le fait d'avoir une équipe recherche permet de faire ça. Comme tu disais très bien, les derniers modèles qui marchent pour les GAFA ne sont pas toujours les derniers modèles qui ont marqué nous pour nos calvages. On a juste commencé à trouver un modèle de transformer qui donne des résultats équivalents de modèles ou des resnets, une resnet assez classique.

1:23:36 Sur la computer vision alors que quand on regarde les articles, le transformer a tout cassé etc. Nous ça marchait moins bien. Jusqu'à très récemment on a trouvé des trucs assez intéressants. Et puis surtout ce qui est clé c'est qu'une fois que tu as trouvé un truc ça arrive vite en prod. Et ça on a bossé pas mal pour le research to prod pour que ça ne mette pas deux ans. Et donc nous on essaye d'avoir en 6-9 mois de passer du papier chez le client. Et des fois on y arrive. Et ça c'est justement en travaillant sur les interfaces entre les équipes, sur aussi les high factories pour que ce soit facile de rajouter des choses dedans. Pour qu'une fois qu'on a trouvé un truc intéressant, Et bien là, on n'attend pas deux ans pour que ça passe. C'est plutôt ça la course, moi je trouve. C'est-à-dire que la course, c'est de me dire des fois que les gens suivent la recherche, parce que la recherche, ils trouvent tout le temps des trucs intéressants, et des fois je suis là, mais ça fait six mois qu'on me dit que ça c'est bien, et on n'a toujours même pas commencé à le mettre en prod, c'est pas cool. Et c'est ça, je trouve, la plus grosse limitation. Et après, je pense qu'il y a un risque en IA, c'est que, comme en software, comme partout dans ces domaines-là, c'est que tu as toujours un livret, un truc qui sort, un machin, et tu peux te perdre dedans.

1:24:44 Tu peux te dire, tu vois, tu envoies, tu dis, est-ce que ce n'est pas mieux ce qu'on a, ce n'est pas mieux ce qu'on a, et là, il faut revenir au problème. Est-ce que notre solution, elle est bonne ou pas? Oui, sinon, on n'a pas besoin de changer. C'est comme les technologies de base de données ou les orchestrations, les choses comme ça. On n'a pas tous besoin de faire ça. du Kubernetes et du microservice, si tu n'en as pas besoin, tu le feras quand tu en auras besoin. Je pense qu'on a la fin pour le jour, sauf s'il y en a encore qui veulent se lancer. Il ne faut pas hésiter. Comment est-ce que vous faites pour sécuriser votre réseau et en général tout ce que vous avez fait en interne par rapport au fond de sécurité? Bonne question. Comment est-ce que vous faites pour sécuriser vos ailes gauches et pré-gènes? Alors sécuriser, c'est-à-dire? L'intérêt, c'est qu'il n'y a pas beaucoup à réfléchir.

1:25:45 C'est qu'ils nous disent« ça doit être comme ça», on dit« ok», et on fait quoi. Donc des fois, c'est un peu de travail, des fois, c'est un peu de négo aussi, parce que Docker, au début, à la dirisie, ils ne connaissaient pas, ils avaient un peu peur. Mais en fait, et je pense qu'en fait finalement on a moins de contraintes que les banques ou les assurances, parce qu'on n'a pas le sujet des données personnelles. Et en fait une grosse partie quand même de la sécurisation, et ça c'est un enjeu qui va être très très complexe à régler dans le futur, Aujourd'hui, là où se passe la sécurisation, dans 95% des ministères des armées, c'est en fait le cloisonnement. Ton logiciel sécurise un peu, mais c'est surtout le fait que tu es sur un réseau séparé. Là où ça va changer fortement, c'est quand il y a un moment où ils vont devoir faire de l'interconnexion, du cloud comme tout le monde. Et ça, alors là, ça va être un sacré, sacré... Je ne sais pas comment ils vont gérer ça. Les plateformes multiniveaux, comme ils appellent ça, etc. Ça va être très compliqué.

1:26:46 Les Américains commencent à le faire. C'est vraiment très, très complexe. Mais aujourd'hui, c'est assez simple. Il y a même des endroits où, en fait, pour notre logiciel, ils créent un réseau. Ils créent un réseau, ils mettent une diode. Quand on dit une diode, c'est une diode physique. C'est un truc en fibre optique qui permet... Ça passe dans un sens et pas dans l'autre, le signal littéralement. Et donc, ils peuvent aller consulter les résultats, mais il n'y a personne qui peut envoyer des données dessus. Donc c'est finalement assez simple. Ils me disent, oui, au Docker, il faut qu'il soit rootless, ils nous envoient quelques contraintes de sécurité. Mais en fait, je pense par rapport à ce que tu peux avoir dans l'assurance, dans la santé, dans des choses comme ça, en fait, c'est quasiment presque plus simple. Du coup, on va se poser la question. Oui, je suis d'accord. Je pense que la difficulté, c'est d'être connecté au réseau. Nous, on est connecté au réseau parce qu'on est du SaaS. On traite des données personnelles, on traite des données de santé. Et finalement, les solutions sont... Il y a une partie qui est similaire, le cloisonnement ça reste toujours quand même, alors on ne fait pas du cloisonnement avec des diodes, mais on isole les clients les uns des autres, en général on les rend invisibles de l'internet, ça, ça aide, et puis ensuite, ouais, on a toute une...

1:27:55 Tout un système de gestion de la sécurité avec des procédures de développement sécurisé, des procédures de gestion des vulnérabilités. C'est des investissements, le budget sécurité à Shift, c'est entre, je ne sais pas, vers 1,5 million par an. Il y a beaucoup de logiciels, des ressources humaines, des processus. Contrairement à l'IA, c'est probablement plus standardisé. Donc ce qui est bien, c'est qu'il suffit d'appliquer quand même des bonnes pratiques, il y a des standards. Mais c'est pénible. Ce n'est pas la partie la plus fun du job. Tu avais peut-être une question ? Non? Je ne sais pas, j'avais vu une main, ça avait... Ok. Je ne sais pas si il y en a d'autres encore. Je ne sais pas jusqu'à quelle heure on a d'ailleurs. Non? On va passer à la partie networking. Merci beaucoup, en tout cas, c'était hyper intéressant. Même pour moi, un peu plus novice que d'autres de l'Apsad.

1:28:57 Merci. Moi, ça va.