IA en production : ni trivial ni sublime

0:14 Bonjour à tous. Merci Noémie pour cette intro. Merci beaucoup. Bonjour à tous, bienvenue sur ce meet-up, bienvenue à Alexis et Mehdi. Merci beaucoup à vous deux de vous prêter à l'exercice. Je crois que pour vous deux, c'est la première fois que vous êtes speaker dans un Meetup Tech.Rocks, n'est-ce pas? Oui, c'est bon. Alors, évidemment, on va commencer par les présentations. Donc, à la fois, Mehdi, Alexis, je vous invite à nous dire en quelques mots qu'est-ce que fait votre entreprise, qui n'est peut-être pas connue de tous ici, et ensuite nous expliquer un petit peu quel est votre rôle au sein de cette entreprise. Alexis, je te laisse ouvrir la danse. Ok, merci Marie. Du coup, moi, Alexis Jacob, je travaille à Deepomatic. C'est une startup qui existe depuis 8 ans. On a fait une série A il y a quelques mois. Du coup, nous, ce qu'on essaie de faire, c'est qu'on s'est rendu compte que les entreprises qui ont des opérations de terrain, à savoir...

1:16 Installer et maintenir des équipements font face à une pénurie de main d'oeuvre qualifiée et du coup tous les équipements etc fonctionnent moins bien et du coup ça pose des problèmes. pour les clients, etc. Et du coup, nous, on a une solution à base d'intelligence artificielle qui permet de valider et de s'assurer que toutes les opérations sont bien faites du premier coup. Et moi, mon rôle spécifiquement à Deepomatic, c'est de gérer les équipes techniques, puisqu'on a un produit assez complexe, de la partie entraînement des réseaux de neurones jusqu'à l'exploitation et la partie BI. Donc, je vais gérer toutes ces équipes techniques. Travailler avec le produit pour faire une roadmap qui peut fonctionner en matière de débroussaillant rapidement en amont et après des sujets plus haut niveau avec le CTO, que ce soit sécurité, process et puis R&D. Ok, donc tu es VP Engineering et tu reportes au CTO, c'est ça? Tout à fait. Le tout dans une boîte dont le cœur du métier est l'intelligence artificielle. Exactement.

2:17 Super, merci Alexis pour cette intro. Mehdi? Oui, merci Marie, merci Alexis pour la présentation. Moi c'est Mehdi, je suis chez DoiT International. Alors, qu'est-ce que DoiT International? C'est une société qui propose une gamme de services et de produits dédiés à la bonne gouvernance du cloud. Depuis la migration vers l'optimisation des coûts. Pour ce faire, nous proposons une plateforme de gouvernance du cloud qui permet de centraliser et de s'assurer de la bonne marche de son infrastructure. Mais nous proposons également une gamme de services dans plusieurs domaines. data, IA, network, containerisation, des services d'advisory qui nous permettent de proposer des solutions à nos clients à travers le monde. Et moi spécifiquement, qu'est-ce que je fais chez DoiT?

3:18 Je suis staff cloud architect, donc j'accompagne une équipe d'ingénieurs et d'experts cloud pour la région Saône-et-Mier. France, Iberia et Italie. Et je suis également spécialiste IAM, c'est-à-dire que j'accompagne des clients depuis les prémices en R&D vers les aspects de production et de mail-outs, le tout dans un cadre cloud. Super, merci beaucoup Mehdi. Et donc, si j'ai bien compris, DoiT, vous travaillez avec Deepomatic. Absolument. Vous vous connaissez déjà. Super. Alors, pour rappel, aujourd'hui, notre thématique, c'est l'IA, et plus précisément, l'IA en production. Pour ceux qui ne le savent pas, Tech.Rocks a maintenant des mois thématiques, et en ce moment, on est dans le mois de la data. Donc, comment parler de data sans parler d'intelligence artificielle, surtout par les temps qui courent. Mais même si ça s'améliore un petit peu d'année en année dans l'intelligence artificielle il y a beaucoup de fumée et on a du mal à trouver les feux parfois

4:24 donc aujourd'hui le but c'est vraiment de parler de l'IA dans la vie réelle l'IA qui passe en production et ça tombe bien Parce qu'Alexis, c'est ce que vous faites. Mais alors, avant de nous parler un petit peu des réussites et potentielles difficultés pour justement passer en prod avec l'intelligence artificielle, Est-ce que tu peux nous décrire rapidement ta stack sans aller dans le détail, mais pour que les personnes qui ont le plus la fibre tech parmi nous puissent s'y retrouver un petit peu? Oui, carrément. Alors, nous, principalement pour le backend, on a utilisé du Python avec Django pour la partie web. Pour tout ce qui va être à l'aise. inférence réseau de neurones, on a notre propre moteur qu'on a écrit en C++, basé principalement sur ton source flow. Alors je me permets de te couper Alexis, est-ce que tu peux préciser ce que ça veut dire inférence pour les personnes qui ne sont pas spécialistes du MA? Exactement, c'est quand on va envoyer une donnée à un réseau de neurones et qu'il va nous faire une prédiction, on appelle ça une inférence. Et du coup, pour aller le plus vite possible, on le fait en C++.

5:28 Pour la partie front, on est principalement sur du Angular. Et le tout est déployé sur Google Cloud, containerisé, donc avec Kubernetes. Et Terraform. Génial, et j'en profite pour rappeler ce qui a déjà été dit, vous pouvez utiliser l'onglet Q&A pour poser vos questions tout au fil de l'eau. Je prendrai les questions qui s'intègrent bien dans notre discussion, et sinon on en prendra aussi évidemment à la fin. Donc vraiment n'hésitez pas. Du coup, je propose d'attaquer direct dans le vif du sujet. Alexis, ça fait pas mal d'années maintenant que tu bosses chez Deepomatic. Donc, tu fais partie de ces quelques personnes qui peuvent dire sans mentir, oui, moi, j'ai X années d'expérience dans l'intelligence artificielle. Alors, fort de cette expérience, quels sont pour toi vraiment les points clés? Pour s'assurer de passer en prod et ne pas s'arrêter au proof of concept? Alors, je pense que déjà, il faut que le proof of concept fonctionne. Et donc, pour ça, il faut arriver à bien le cadrer.

6:30 se concentrer sur certaines tâches à forte valeur ajoutée, très peu, mais qu'on va vraiment bien réussir. Ensuite, le cadrer dans le temps pour ne pas faire durer le proof of concept éternellement. Et la dernière étape qui, à mes yeux, est la plus importante, c'est d'aller le plus rapidement possible en production parce que ce qu'on a pu voir, donc moi ça fait 8 ans que je travaille dans cette entreprise, avant je travaillais dans d'autres boîtes en IA, c'est qu'entre les données qui servent pour l'entraînement et les données du terrain, il y a souvent des différences qu'on ne peut pas anticiper et donc même si on a quelque chose qui est parfait, En théorie, on va dire dans la phase d'entraînement, quand on voit dans la pratique comment ça se passe, c'est souvent différent. Donc nous, ce qu'on fait, c'est d'essayer de pousser le plus rapidement possible un POC, valider que ça fonctionne sur certains éléments qu'on a envie de valider, et ensuite passer à l'étape suivante, à complexifier la solution. Dire ce qu'on va attendre comme résultat et comme ça on s'assure que tout fonctionne bien et soit conforme à ce qu'on attend.

7:35 Quand tu dis le plus rapidement possible, est-ce que tu as des points de repère là-dessus? Est-ce que ça va dépendre beaucoup des projets ou est-ce que chez les diplomatiques vous avez une sorte de time frame que vous essayez de respecter pour la partie POC? Aujourd'hui, à Deepomatic, on a des avant-ventes techniques qui vont cadrer le projet, dans le meilleur des cas. On est arrivé à avoir des POC après trois semaines, un mois. sur certains projets avec des clients, des entreprises plus grandes avec plus de process. Ce qu'on a envie d'éviter, mais c'est déjà arrivé, c'est les premières données qui revenaient du terrain, c'était après plus d'un an. Donc voilà, après il y a des périodes creuses pendant deux mois, on se voit des petits mails et après finalement on avance. En tout cas, on est capable sur l'époque de prouver qu'en deux, trois semaines, on peut avoir quelque chose de viable. Et si on arrive à atteindre cette end frame, c'est vraiment l'idéal. Top, super. Ça donne quelques points de repère. Et Mehdi, vous, avec votre expérience, tous les clients que vous voyez passer, est-ce que vous avez un petit peu des astuces, des bonnes pratiques plutôt, pour permettre justement l'accélération d'époque?

8:47 Alors oui, je souscris d'abord à tout ce que vient de dire Alexis, un cadrage, un cadrage temporel effectivement avec deux, trois semaines me paraît suffisant et la nécessité de faire une démo, que ça ne reste pas, que les aspects théoriques qui peuvent être écrits dans un notebook ou dans une présentation soient disponibles sous forme de démo très rapidement. Effectivement, je suis d'accord avec le concept de différence entre la donnée que l'on exploite en production et la donnée qui est théorique. C'est ce qu'on appelle le concept drift qui peut... effectivement, qui doit nous faire accélérer le temps de développement, la nécessité du MVP, donc Minimum Viable Product, très rapide. J'ai deux aspects complémentaires que je souhaiterais évoquer. Le premier, c'est dès lors que l'on cadre, on doit s'appuyer sur...

9:51 Pas plus de deux métriques de succès et des métriques qui puissent être corrélées avec Ce qu'on appelle la fonction de coût, la fonction d'optimisation qui va être utilisée par un algorithme d'IA. Il faut qu'il y ait une corrélation entre ces deux métriques pour ne pas avoir un modèle dit hors sol qui ne soit pas utilisé. Et le deuxième point, parce que c'est vrai que nous avons aussi changé de paradigme en moins d'une dizaine d'années, nous avons à disposition énormément de modèles pré-entraînés sur étagère, open source, qui nous permettent immédiatement d'activer des cas d'usage génériques. Et à la faveur de ce qu'on appelle l'apprentissage par transfert, transfert learning, on peut adapter ces cas d'usage génériques plus tard, lors d'une deuxième phase, à la spécificité.

10:53 Donc globalement, oui, ces deux astuces permettent d'accélérer le cadrage et le fait de dépasser le top. Génial, merci beaucoup à tous les deux. Je pense que ce qui ressort beaucoup de cette première partie de discussion, c'est que finalement, désolé si je cache le mythe, mais un projet d'IA, c'est un projet comme les autres, et l'une des grandes clés de succès, ça va être de faire un cadrage de qualité, d'avoir une gestion de projet tout simplement de qualité, et en effet, des projets qui se sont plantés parfois magistralement pour... de cadrage, absence de définition d'une métrique unique ou définition mais hyper floue sans avoir été jusqu'au calcul, jusqu'à la définition d'une fonction de coût, etc. Voilà, j'en ai vu et ça a été parfois des catastrophes. Donc les leçons clés un petit peu de succès qui en ressortent, elles sont... Pas hyper original, mais des fois, il faut savoir enfoncer les portes ouvertes.

11:54 Bon, mais justement, quitte à parler de situations un peu épineuses, Alexis, j'imagine que vous, vous en avez pas mal chez Deepomatic. Ce serait quoi un peu les plus gros fails que vous avez vécu au moment de passage en prod de Projet DIA? Alors, je pense que je vais d'abord parler du concept Drift dont parlait Mehdi. Et en plus, c'est un de nos premiers gros projets qui allait en production. Donc, c'est pour le groupe Compass, qui est le leader de la restauration collective. Et le but du projet, c'était de, sur des bornes style bornes McDo, apporter son plateau repas, prendre une photo du plateau et puis l'analyser, sortir les items et ensuite les facturer aux convives. Et donc, sur ce projet-là, nous, déjà, la première phase, c'était l'acquisition de données. Comment on pouvait l'avoir? À quel moment? Qu'est-ce qu'on devait mettre en place? Et donc, ce qu'on a fait, c'était de mettre des petites webcams sur les mâts des caisses standards que vous pouvez voir dans vos restos d'entreprise. Donc déjà, les images n'étaient pas parfaites par rapport aux caisses finales qu'on allait avoir.

13:00 Et surtout, cette phase d'acquisition de données a pris énormément de temps. Je pense que ça a dû commencer en septembre jusqu'à février pour avoir des données représentatives. De ce que les convives mangeaient, puisqu'il y a beaucoup d'items aussi qui étaient à la carte, mais qui n'étaient pas forcément achetés par les convives. Et donc après, on a eu la phase de recadrage, développement de la caisse, etc. Entraînement des réseaux de neurones. Et le premier restaurant qu'on a mis en production, c'était fin mai. Et donc, j'étais sur place pendant le premier repas. Et ce qui s'est passé, c'est quand on est arrivé au moment de l'analyse des fruits, ça ne marchait plus du tout. Et assez vite, on allait voir ce qui se passait. Et en fait, c'est qu'on entraînait sur les fruits qu'on avait vus en hiver, notamment des poires et des pommes. Et en fait, quand on est arrivé en été, il y avait des cerises, il y avait des melons, il y avait des pêches. Et le réseau de neurones ne connaissait pas du tout ça. Et donc, les gens ne comprenaient pas.

14:00 Il y avait ce tour de magie qui ne fonctionnait pas de reconnaître un melon ou une cerise. C'est facile. Pourquoi est-ce que le réseau n'y arrive pas? À l'inverse, reconnaître, je ne sais pas, un sauté de veau ou une salade César. On était excédents là-dessus parce qu'il y avait eu ça tout le reste de l'année. Je pense que ça, c'est... Un premier fail qu'on a eu. Et on pensait être assez bon sur ce sujet-là. Et ensuite, il y a le Covid qui est arrivé. Donc, pareil, sur le même projet. J'en parle beaucoup parce que j'ai vraiment bossé dessus sur la partie dev aussi. Donc, il y a le Covid, le confinement, les restos ferment, ensuite les restos réouvrent à la fin du confinement. Et là, quand on voit un peu nos métriques qui montent du terrain, on ne comprend pas. Encore une fois, les fruits ne fonctionnent pas. Là, on a normalement toute la gamme de fruits de toutes les saisons. Qu'est-ce qui se passe? Alors, on va visualiser. En fait, ce qui se passait, c'est que post-Covid, tous les fruits étaient recouverts de plastique. Et en fait, les réseaux de neurones n'avaient pas appris à reconnaître des fruits avec des plastiques. Et du coup, tous les items... était toujours reconnu de la même manière.

15:01 Et donc, pareil, on n'avait pas anticipé ça. Et ce qu'on a appris, du coup, là, ce qu'on pousse, c'est si vous faites des changements de l'environnement, idéalement, dites-le nous à l'avance pour qu'on puisse anticiper ça. Donc, voilà, ça, c'est un premier fail qu'on a eu vraiment lié à l'intelligence artificielle et au réseau de neurones qu'on avait entraîné. Pardon Alexis, je me permets de te poser deux petites questions avant que tu nous donnes d'autres exemples. Premièrement, comment est-ce que tu fais pour détecter des problèmes comme ça? Parce que le monde change, donc on a beau tout anticiper, il y aura toujours des cas comme ça où on ne plastifiait pas les légumes, maintenant on les plastifie. Un, comment vous faites pour détecter ça le plus vite possible, si possible avant même que les clients vous aient appelé en râlant? Et deuxièmement, comment vous résolvez le problème? Dans le cas des plates au repas, là c'était vraiment sur place, les gérants de restaurants qui nous appellent en panique, etc. Mais ce qu'on avait mis en place en amont, c'est qu'on ne renvoyait pas de manière brute les résultats de l'intelligence artificielle.

16:09 En fait, sur ce projet-là, s'il y a à se tromper, puisque c'est des choses qui peuvent arriver, le convive ou les gens dans le restaurant pouvaient corriger le résultat. Et en fait, même si ce n'était pas parfait, à la volée, on pouvait remapper la sortie d'un réseau de neurones avec la réalité. Et donc, par exemple, dans le cas des fruits d'hiver et d'été, on a mappé assez rapidement et automatiquement. que ce qui était reconnu comme des litchis, c'était des cerises. Parce que le réseau de neurones avait appris à reconnaître la forme ronde et la couleur rougeâtre. Donc ça, c'est la première solution qu'on a en place. Et l'autre chose, c'est que ce qu'on essaie de faire, et idéalement, c'est ce qu'on pousse chez les clients, c'est de faire de l'AB testing, mais pas... Tout remplacer d'un coup. Et du coup, si on a assez de métriques qui remontent et qui sont intéressantes, il y a un travail de transformation, donc plus qu'il y ait ETL, etc. En ce moment, mais justement de pouvoir faire surfacer les clusters qui sont différents de la norme et d'avoir des alertes en amont pour qu'on puisse regarder ce qui se passe et dire, OK, là, sur...

17:10 Ce type d'analyse, il va falloir qu'on réduise les seuils ou qu'on les ignore dans le résultat final, ce qui permet de mitiger le problème avant de pouvoir le régler efficacement. Ok, donc en fait, à la fois, ce qui vous permettait de détecter était aussi un petit peu ce qui vous permettait de résoudre le problème, à savoir la correction par les utilisateurs et vous derrière qui arrangez votre algo en fonction. Mais si on généralise à d'autres projets, Les mêmes deux questions, en général, quelles sont les bonnes pratiques pour détecter des changements de l'univers, de l'environnement dans lequel on évolue? Et comment est-ce qu'à chaque fois, ça veut dire réentraîner un modèle? Chaque fois, ça veut dire recollecter de la donnée, la réannoté ou est-ce que ça dépend ? Je pense qu'il n'y a pas de réponse universelle.

18:11 Néanmoins, c'est déjà de notre côté d'être au courant de ce qui se passe, de quel est l'environnement qu'on connaît, qu'on maîtrise. Et de pouvoir détecter, il y a des choses qui sont suspectes, ça ne touche pas l'ensemble des interventions, mais il y a des erreurs là où on ne devait pas en avoir, et de pouvoir faire remonter ce genre de métriques. Nous, un autre avantage qu'on a, c'est que toutes les données sont en général remontées en temps réel, Du coup, on peut assez vite, et donc on fait de la computer vision, c'est visuel, on peut très vite aller voir nous-mêmes qu'est-ce qui se passe. Et donc, par exemple, dans les raccordements fibres, quelque chose qui arrive avec les réseaux de neurones, c'est qu'aujourd'hui, même s'il y a des efforts qui sont faits sur ce sujet-là, l'explicabilité de ce que comprend le réseau de neurones, ce n'est pas extrêmement clair. Et donc, ce qui nous semble bon de notre côté, ne l'est pas pour le réseau de neurones. Par exemple, une nouvelle étiquette ou un changement de couleur de câble peut complètement perdre le réseau de neurones, même si nous, en tant qu'humains, on va regarder la finalité du câble.

19:13 Un exemple pour illustrer ça, c'est au tout début de Deepomatic, on voulait faire un chasam de la mode, donc typiquement prendre en photo les gens et trouver leurs vêtements. Et il y avait des premiers papiers de recherche pour expliquer ce que le réseau de neurones comprenait. Le réseau neurone était excellent pour reconnaître des baskets ou des sandales. des sandales d'été. Et donc, on s'est dit, si on arrive à comprendre ce que voit le réseau de neurones, on va pouvoir être meilleur sur des vêtements un peu plus complexes. Et en fait, on a réussi à voir que le réseau de neurones sur les baskets, ce qu'il avait appris à reconnaître, c'était le logo. Donc, n'importe quelle chaussure avec un gros logo était reconnue comme une basket. Pour les sandales, c'était encore pire. Il apprenait à reconnaître de la chair, donc de la peau. Et du coup, un pied nu était reconnu comme une sandale. Et donc, ça, c'est les problèmes qu'on ne peut pas vraiment comprendre, sauf si on sent. On va regarder dedans. Et donc, quand on prend maintenant les sujets fibres, etc., c'est vraiment nous, en fait, on est beaucoup plus rapide à dire, tiens, il y a un changement de couleur, il y a un changement de prise de vue, de luminosité, etc. Et donc, on va détecter ça.

20:15 Et ensuite, ce qu'on essaye de faire dans la plupart des cas, c'est... De pouvoir entraîner assez rapidement un nouveau réseau de neurones. Et donc, la durée d'entraînement peut varier. Quand on est sur la production et qu'on a besoin de réentraîner, ça peut prendre quelques heures et au maximum quelques jours. Et du coup, avec toutes les images qui étaient fautives, mais faut-il pour une bonne raison, parce que c'est une image floue, etc., on va les réannotés, les réentraîner, et ensuite déployer ce nouveau réseau de neurones assez facilement, donc c'est invisible pour les utilisateurs, et corriger ça en production. Top, merci Alex pour ces illustrations hyper complètes. Je crois que tu as d'autres exemples à partager avec nous sur vos failles, vos difficultés en prod. Je te laisse reprendre à cet endroit-là. Un autre de nos problèmes, c'est que Même si, comme tu disais tout à l'heure, Marie, on parle de plus en plus de l'IA, etc. C'est que l'IA, ce n'est pas magique.

21:18 En fait, se dire on met le lien en production et ça va marcher dans 100% des cas, c'est une grave erreur. Et là où on a eu des fails, même si ce n'est pas directement à dire imputé à nous, c'est que l'intégration que certains de nos clients ont faite, basée sur le fait que l'IA avait toujours raison, sans possibilité de la corriger. Et donc, un exemple, c'est que quand il y a les raccordements fibres particuliers, donc on peut voir dans la rue, il y a ce qu'on appelle les PM, le technicien, la dernière étape, c'est de photographier l'état du PM complet pour valider que tout a été bien fait, qu'il n'y a pas de nœud, qu'il n'y a pas de gaine qui tombe. Que les cassettes ne s'affaissent pas, etc. Et une fois que nous, on dit ça, c'est bon, sachant que quand on dit ça, c'est bon, ça prend moins d'une seconde. Le technicien peut clôturer l'intervention et retourner chez lui. Et ce qui s'est passé, c'est qu'on n'avait que des images qui étaient avec une bonne luminosité, puisque les opérations avaient lieu normalement. Pendant les heures de jour en France.

22:21 Là, sur ce cas particulier, c'est qu'il y a eu des problèmes pendant le raccordement, il manquait des outils, des allers-retours, etc. Et donc, le technicien, il a pris la photo en fin de journée où il n'y avait plus beaucoup de lumière. Et puis, même le flash, une photo avec flash, ce n'était pas des photos que nous, on avait appris à reconnaître. Et en fait, ce qui s'est passé, c'est que notre IA faisait que répondre photo non valide, photo non valide, photo non valide, parce qu'elle ne correspondait pas aux données d'entraînement. Et donc là, le technicien n'a pas pu clôturer son intervention, il a dû appeler le support. En plus, il y a des chaînes de sous-traitance, etc. Pour pouvoir rentrer chez lui et travailler. Et ça, c'est un énorme fail parce que ça a mis de la frustration. Chez la personne qui est sur le terrain, alors qu'en fait, On voulait juste l'aider, s'assurer qu'elle fasse correctement son travail, qu'elle puisse être payée efficacement. Ça, c'est un premier exemple de mauvaise intégration. Et un autre truc pareil, je pense que c'est avec ces sujets d'IA qui sont sur le terrain, c'est qu'il y a une chaîne de commandement qui est gigantesque, des gens qui sont les décideurs, aux chefs de projet, aux chefs d'équipe, jusqu'aux techniciens qui sont sur le terrain, et parfois la communication n'est pas optimale.

23:28 Et pour un grand opérateur téléphonique français, ils ont poussé une nouvelle version de l'application à tous leurs techniciens, donc ça faisait peut-être 8000 personnes. Et en fait, ce qui se passait, c'était la même chose, c'est que le technicien devait compléter son intervention pour pouvoir aller chez un autre client et faire ce qu'il devait faire dans la journée. Sauf que dans certains cas, les clients ne sont pas chez eux, ils ont oublié ou ce genre de choses. Et comme les techniciens ne pouvaient pas clôturer l'intervention en montrant que la fibre était branchée, que la longueur d'onde était correcte, les techniciens ont patienté toute la journée devant le portail parce qu'ils ne pouvaient pas savoir où était leur prochaine intervention. Et le temps, et là c'était compliqué, c'était une application que nous on ne maîtrisait pas, le temps qu'en urgence, notre client réimplémente dans l'application la possibilité de faire un script de l'intervention, il y a eu une journée de travail qui a été perdue pour peut-être 5000 personnes. Et donc il y a eu environ... 10 000, non peut-être pas.

24:31 5000 personnes qui n'ont pas pu être accordées en fibre et qui ont dû attendre. Et du coup, ça crée de la frustration, etc. Donc, je pense que l'autre chose qu'on pousse vraiment chez tous nos clients, c'est de voir l'IA comme un outil supplémentaire. Mais il ne faut pas hésiter à pouvoir la couper avec un circuit breaker ou de la corriger si elle a tort, sachant que s'il y a une correction, nous, c'est une donnée aussi super intéressante puisqu'on va pouvoir regarder est-ce que c'est l'IA qui est trompée sur tel type d'image. Donc, on va rajouter ça au dataset, entraîner. et que dans le futur, ça se produise. En effet, pour un projet qui visait à optimiser les interventions fibres, avoir bloqué 5000 raccordements, ça fait un petit peu mal. Finalement, j'ai l'impression qu'il y a deux sources de gros problèmes quand il s'agit de passer de l'IA en prod. Un, cette fameuse histoire de concept drift, et merci de Mehdi pour les réponses sur le chat. Donc toujours cette lutte des data engineers, des data scientists pour obtenir des datasets les plus représentatifs possibles de la vraie vie

25:39 et deuxièmement la question de l'intégration de l'algorithme dans un process métier tout simplement je répète souvent à mes équipes qu'on ne construit pas des algos on construit des systèmes, des systèmes de bout en bout il y a le cadrage dont on a parlé mais il y a en effet l'intégration dans un process, l'intégration avec d'autres outils, il y a le monitoring, il y a la maintenance, il y a énormément de choses à penser autour d'un algo et pas juste la modélisation, l'entraînement, l'évaluation de la performance pure de cet algorithme. Est-ce que tu as éventuellement une librairie ou un outil à conseiller que vous utiliseriez pour détecter le concept drift, même si vous avez manifestement beaucoup de cas où vous pouvez avoir des... des retours terrain très directs. Il existe des outils, par exemple, qui analysent la distribution des données, voir si elle évolue dans le temps.

26:40 Est-ce que vous, c'est quelque chose qui vous est utile parfois ou pas? Un petit peu, Marie-Lie, on le fait plutôt de manière maison, puisqu'on a développé un certain nombre d'outils en interne qui nous permettent justement de voir ça, la représentativité des données, l'équilibrage des classes, ce genre de choses. Mais c'est un vrai sujet. J'ai vu qu'il y a des startups qui sont en train de créer sur le testing des réseaux de neurones. Nous, on a nos benchmarkings en interne. Mais voilà, ça, c'est un vrai sujet. Et tout ce qui est expliquabilité, qui permet aussi d'aller regarder en détail les concepts, comment ça se passe. Il y a des choses comme ça. Je pense que Mehdi doit avoir des infos là-dessus. Oui, alors justement, effectivement, en ce qui concerne la détection du drift, nous avions un cas, en fait, un client chez DoiT qui a voulu implémenter un modèle de catégorisation de texte.

27:41 Donc typiquement, c'est un texte, c'est de savoir si le texte appartenait à une catégorie sportive, news ou autre. Il s'avère que le premier modèle utilisé est un modèle pré-entraidé et marchait relativement bien. Arrive le moment du fine-tuning. Le fine-tuning, c'est un entraînement du modèle pré-entraîné un peu plus spécifique pour le rendre plus adapté au cas d'usage du client. Le modèle est fine-tuned, toutes les métriques sont ouvertes et il s'avère que le modèle fine-tuned a commencé à catégoriser. Toutes les données comme étant des news sportives. Pourquoi? Parce qu'il y avait un événement sportif dans la région du client qui détruisait complètement l'équilibrage des classes.

28:44 Donc, qu'est-ce qu'on a fait? On a essayé de mettre en place du monitoring sur le cloud provider du client. Tout simplement avec des comparaisons de distribution plutôt simples, d'abord visuelles pour donner un peu de matière aux décideurs, mais aussi un peu plus techniques, comme les liens que je les avais envoyés, la divergence de feedback leader notamment. Il faut savoir aussi qu'après, nous avons travaillé pour pouvoir activer, en l'occurrence, un outil de monitoring du data drift que je vous ai envoyé dans le chat. C'est ce qu'on appelle... Ce qui est marrant, c'est ce qu'on appelle aussi la catastrophe classe. L'entraînement devient tellement spécifique à la donnée, ce n'est même plus de l'overfit, ça va au-delà, c'est qu'on perd toute notion de ce qui s'est passé avant et on devient extrêmement obtus.

29:45 Un autre exemple qui est devenu assez proverbial et qui est assez ancien, c'est celui de Tay. Le chatbot, rapidement mis en prod et avorté par Microsoft, qui est devenu un petit peu vigoureux. Voilà, c'est un bel exemple de fail en prod, parce qu'il a lu Twitter pendant à peu près une heure. Oui, vigoureux, gentil mot pour dire notamment nazi. C'est ça, exactement, c'est un euphémisme. Oui, et d'ailleurs, alors moi je ne suis pas du tout une spécialiste des LLM en ce moment, etc. Mais ChatGPT, évidemment, par exemple, ce n'est pas une solution qui vous fournit la sortie de l'algo brut de décoffrage. Il y a des couches supplémentaires par-dessus GPT, notamment une couche de sécurité pour éviter déjà la promulgation d'informations qu'on n'a pas envie de... De diffuser typiquement comment je peux fabriquer une bombe.

30:47 Et aussi, il y a des mécanismes qui évitent comme ça d'absorber les mauvaises caractéristiques, disons, de ce qu'on peut trouver sur Internet, sur les forums, etc. Alors, on a parlé plusieurs fois de l'entraînement. Alexis, tu nous as dit que vous en avez pour seulement quelques heures, parfois maximum quelques jours, pour réentraîner un modèle, pouvoir itérer. Et c'est vraiment parce que je trouve qu'on... Quand on parle d'intelligence artificielle, on parle beaucoup des performances, de comment ça va changer la vie de tout le monde, etc. Mais on parle moins de ce que ça coûte exactement. Tout ça, c'est assez flou. Même là, sur la vague médiatique GPT, on a finalement assez peu de repères sur combien ça coûtait en argent, en impact environnemental, etc., de créer ce type de technologie. Vous, c'est quoi un petit peu vos retours terrain sur les coûts et les contraintes de créer ces algos que vous proposez à vos clients?

31:55 Alors, la première chose à savoir sur les réseaux de neurones, comme parlait Mehdi, c'est que nous, on ne fait quasiment que du réentraînement et du transfert learning. Parce qu'en fait, sans rentrer dans les méga détails techniques que je ne maîtrise pas à 100% non plus, le réseau de neurones, au début, va surtout apprendre à reconnaître des formes, des textures, etc. Et en fait, pour ça, il faut beaucoup de données. Ça prend énormément de temps à entraîner. Ensuite, l'autre sujet qui est assez intéressant, c'est qu'il y a une sorte de, je ne sais pas si guerre, c'est le bon mot, mais Facebook, Google, Microsoft, Alibaba. Ils poussent, en fait, ils ont une armée de scientists pour avoir les meilleurs réseaux de neurones, les meilleures architectures, etc. Et donc, eux, ils ont, on ne sait pas combien de temps ça leur a coûté, mais ils ont cette ferme de serveurs, ils ont toutes les cartes graphiques quand ils veulent, ils peuvent faire autant d'expériences pour finalement battre ou dire avec les premiers sur des concours de reconnaissance.

33:00 d'images et principalement ce temps d'entraînement va être pour apprendre à connaître les formes etc. Nous le choix qu'on a fait parce qu'on a essayé de faire aussi nos propres réseaux de neurones c'était vraiment de regarder est-ce que si on entraîne quelque chose de A à Z ou est-ce qu'on va juste entraîner la fin donc là quand on va spécialiser le réseau de neurones sur nos cas à nous est-ce qu'il y a des différences notables en termes de performance en fait les réseaux pré-entraînés ou on va entraîner la fin était largement meilleur que ceux qu'on avait entraînés de A à Z. On n'avait pas les ressources en interne pour tester différentes techniques d'entraînement. Donc même maintenant, aujourd'hui, ce qu'on a, c'est des techniques de recherche automatique d'hyperparamètres. Il y a énormément de paramètres qu'on peut mettre lors d'un entraînement, mais ce n'est pas très clair quels sont les meilleurs, etc. Donc nous, on va se concentrer sur... Partir d'un réseau entraîné et chercher les meilleures combinaisons de paramètres pour l'affiner sur nos besoins à nous. Mais en soi, ces réseaux par rapport au nombre d'images, on va dire, les plus longs réentraînements qu'on a, c'est ce projet de plateau repas, parce qu'on a à peu près, je pense, 800 000 ou 1 million d'images de bonne qualité pour de la détection.

34:13 Donc, trouver les zones, ça va nous prendre une petite semaine. Mais dans la plupart des cas, quand c'est de la classification, donc juste dire est-ce que sur mon image, il y a telle ou telle chose, ça va prendre 2-3 heures. Et c'est moins cher parce qu'un autre truc aussi à garder en tête, donc nous, on a fait le choix. de faire l'entraînement in-house plutôt qu'utiliser les services un peu SaaS, Blackbox, qui seront mis à disposition par Amazon, par Google, etc. Et en fait, aujourd'hui, contrairement au partage de ressources CPU sur des VM, La partie GPU n'est pas encore au point et on ne peut pas partager un GPU. Les dernières générations de cartes graphiques, Nvidia a fait beaucoup de travail dans ce sens-là. Mais aujourd'hui, ce qui est disponible facilement, notamment côté Google, c'est une carte graphique ou une machine avec une carte graphique qu'on va apprendre à plein temps. Et ça, ça coûte assez cher. Donc, on essaie quand même de réfléchir et de réduire les coûts à ce niveau-là parce que j'ai regardé, nous, aujourd'hui, 60% de nos coûts cloud, c'est uniquement les cartes graphiques.

35:20 C'est assez énorme. Et l'autre partie aussi qui est intéressante, c'est qu'il y a beaucoup d'architectures de réseaux de neurones qui sont disponibles. Et qui ne sont pas toutes adaptées à l'utilisation. Aujourd'hui, nous, on a des clients qui veulent vraiment la précision la plus haute possible. Et donc, pour ça, c'est des réseaux qui sont assez gourmands en termes de RAM, etc., qui peuvent tourner sur ces grosses cartes graphiques. Mais dans ce cas de figure, il y a des réseaux de neurones qui sont moins performants, mais qui sont extrêmement rapides à entraîner, qui peuvent tourner sur CPU. Et là, ça fait des grosses réductions de coûts. Il y a aussi des axes de recherche pour optimiser les réseaux entraînés par rapport au hardware, notamment Intel qui essaie de se positionner aussi dans cette course au hardware de deep learning. Et donc Intel va fournir des outils qui vont optimiser les réseaux de neurones pour qu'ils puissent tourner sur CPU et pour que ça soit, de notre point de vue, moins cher. Donc, globalement, on va dire que le deep learning, c'est une petite révolution depuis une dizaine d'années, mais c'est gourmand en termes de ressources, en termes d'entraînement.

36:30 Et on va dire, l'état de l'écosystème aujourd'hui est bien moins avancé côté GPU, enfin carte graphique, que côté CPU et virtualisation. Et alors, je suis très curieuse, je ne sais pas si c'est toi qui gère ça en interne, comment vous faites pour justement rationaliser un petit peu vos coûts cloud? Alors ici, je parle essentiellement sur l'entraînement des algos, parce que c'est vrai qu'il y a le côté open bar qui est très sympa pour itérer rapidement quand on est data scientist, etc. Mais certaines boîtes ont eu des factures un petit peu surprenantes à cause de ça. Évidemment qu'il ne faut pas complètement brider ses équipes, mais il faut maîtriser son budget. Donc, est-ce que vous êtes proactif là-dessus? Comment vous surveillez ce spending cloud? Et comment est-ce que justement vous surveillez les innovations telles que tu viens d'en citer, qui peuvent vous aider à rationaliser tout ça?

37:33 Je pense que la première règle de sécurité par rapport aux dépenses, c'est de mettre une limite à l'autoscaling. Parce que sinon, ça peut exploser. En fait, on va avoir deux axes. Le premier, c'est de ne pas entraîner pour le plaisir et de pouvoir arrêter une expérience. Le plus rapidement possible à partir du moment où ça diverge. On a un certain nombre de métriques d'entraînement qui nous montrent que ça ne va pas dans la... Ça ne va pas dans la bonne direction. Ensuite, une autre chose très terre-à-terre, très concrète, c'est en fonction du client qu'on a et du budget sur le projet, on va passer plus ou moins de temps à l'entraînement et on va définir nos seuils aussi par rapport au temps qu'on a passé dessus et au coût que ça nous a coûté. Mais après, étonnamment, côté diplomatique, aujourd'hui, nos plus gros coûts, ce n'est pas spécialement côté entraînement, mais c'est côté inférence en production. Donc, analyse en production, puisque de base, on doit avoir de la haute disponibilité, donc le minimum.

38:37 Deux cartes graphiques, enfin deux serveurs séparés au cas où l'un tombe. Bien sûr, on a certains clients qui ont besoin de 4, 5, 6 serveurs tout du long. Donc ça, ça va être nos grosses dépenses. Et là-dessus, on va regarder comment on peut s'en sortir. Parfois, il y a... Il y a des possibilités de réutiliser le même réseau de neurones et jouer sur les dernières couches pour répondre à plusieurs tâches. Donc, il y a du travail qu'on va faire de ce côté-là. Et on va dire, à diplomatique, en tant que startup, c'est qu'est-ce qu'on peut faire d'un point de vue développeur opérationnel pour réduire les coûts. Et après, on passe un peu de temps pour lire des papiers de recherche et voir qu'est-ce qui se passe au niveau de l'état de l'art pour réduire aussi les coûts de ce côté. Ok, merci beaucoup. Je reviens sur une autre chose que tu as. Mentionné tout à l'heure, c'est quand tu as expliqué que vous faisiez vos propres modèles plutôt que d'utiliser des modèles disponibles sur étagère.

39:38 C'est vrai qu'il y en a de plus en plus aujourd'hui. Tous les grands clouds ont quand même beaucoup, beaucoup investi sur leur stack IA. Tu dirais que c'est historique, c'est-à-dire parce que Deepomatic existe depuis longtemps et que sur les premières années, ça avait beaucoup de sens de faire vos propres algos? Ou est-ce que ça reste aujourd'hui pour vous le meilleur? par choix, si on commence un projet de zéro, de faire in-house plutôt que de prendre des produits sur étagère. Je pense que la réponse, c'est un peu des deux. C'est vrai qu'il y a huit ans, il n'y avait pas ces briques sur l'étagère qui étaient disponibles. Et du coup, on n'avait pas le choix, nous, de le refaire nous-mêmes. Après, on a la chance en interne d'avoir plein de types différents maintenant pour les développeurs, mais des gens avec des appétences machine learning. Et qui se sont spécialisés là-dedans. Donc, on avait ces compétences-là qui ne sont pas spécialement disponibles facilement, à dire, sur le marché, mais nous, on l'avait, donc on pouvait le faire.

40:41 Et après, le dernier point qui est intéressant aujourd'hui, c'est que... On a quelque chose qui marche bien et quand on a comparé par rapport à des entraînements sur étagère black box, c'est plus rentable d'avoir ce qu'on a. Mais c'est parce qu'on s'est cherché, c'est la vie de la startup qui pivote. Au début, on voulait être un chef d'âme de la mode, après potentiellement une boîte d'annotation, après une boîte qui fournissait des réseaux de neurones qui ensuite pouvaient être exploités par les clients. En fait, là où on est aujourd'hui, c'est la vie de la startup qui nous a amené où on est là. Si aujourd'hui, en vrai, on devrait recommencer de zéro et faire la même activité, je ne sais pas si on ferait la même chose, mais en tout cas, on voit qu'il y a des choses qui sont plus prioritaires. Que d'essayer de concurrencer un Google, un Amazon sur ces... sur ces sujets. Il me semble que Mehdi a aussi des infos par rapport à ça, côté cloud provider. Oui, absolument. Déjà, je souscris complètement à ces différentes possibilités.

41:44 Je souhaiterais ajouter qu'il existe un spectre, tout un spectre qui n'existait pas il y a une dizaine d'années. Il y avait les pionniers, on va dire, Scikit-learn, aventure française, je tiens à le préciser, qui proposait quelques datasets et voire quelques tutoriels très explicites, mais on n'avait pas la possibilité qu'on a, tout le spectre qu'on a entre quelque chose de très low level avec nos propres librairies jusqu'à quelque chose sur étagère. Un point d'équilibre instable se situant entre prendre une librairie open source, je souhaitais aussi citer une autre aventure française qui est Hugging Face, qui permet de mettre à disposition pléthore de modèles pré-entraînés qui permettent d'activer très vite les modèles. Peu importe l'infrastructure. En ce qui concerne le choix et les différentes modalités concernant la disponibilité des GPU, là pour le coup on est dans du concret, effectivement il s'avère que globalement 90% des coûts dans un projet IA

43:00 viennent de l'inférence. Et là aussi, effectivement, il faut savoir, il faut cadrer également cette approche-là. Quelle est la performance acceptable? Quelle est la latence? Quel est le temps de mise à disposition? Si l'utilisateur peut se permettre d'attendre une heure, alors effectivement, on peut choisir des options CPU. Il existe aussi, suivant les code providers, des options de... De prédiction, notamment sur CPU, avec une option en cas de forte charge d'utilisation du GPU. Alors, les possibilités sont là, peut-être parfois un peu trop. Je vous donne un petit article qui commence à dater, mais qui fait référence, qui parle de choisir une bonne instance GPU parmi les légions GPU. Il y a aussi d'autres possibilités qui sont un petit peu plus...

44:04 Un petit peu plus technique, où effectivement, est-ce que modulo une petite perte acceptable de performance, on peut sortir des modèles un peu plus légers. Donc là, on touche les domaines de distillation et de quantization. Et si vous voulez, on peut essayer de faire une démo ensemble de quantization d'un modèle Bloom, donc un modèle de prédiction de non-ensemble lors d'une table ronde. Donc voilà, globalement, il existe, suivant les cloud providers, il y a aussi des aspects de conteneurisation. Une machine virtuelle sur un cloud provider va être utilisée pour les services IA. Le delta se situe entre les deux, donc pour les instances GPU, entre 25 et 40%. Et plus la machine GPU est importante, et moins le delta est élevé. Donc, on arrive à 25. Qu'est-ce que ça veut dire ? En tant que décideur technique, on se dit, OK, est-ce que les 25% en termes de coûts, je suis prêt à les assumer?

45:12 À les assumer avec les compétences internes, sachant qu'on est tous d'accord pour dire qu'il n'est pas natif pour des data scientists juniors, il y a quelques années, il n'était pas natif d'utiliser des outils tels que la conteneurisation, telle que l'orchestration des containers. Ou bien, pour commencer, on peut assumer 25% de coûts supplémentaires par an. Il y a tout un tas de questions, mais qui sont très intéressantes. Le maître mot est de se dire qu'effectivement, le choix est là et les possibilités sont multiples. Oui, c'est clair qu'on a beaucoup plus de choix que ce qu'on avait il y a quelques années. Du coup, il faut savoir s'y retrouver. Et je pense que sur 2023, on est sur une année assez charnière en termes d'efficience. On voit bien l'actualité de la tech. On n'est plus dans une mentalité open bar, en tout cas dans plein d'activités.

46:14 On réfléchit un petit peu mieux à sa rentabilité, à ses dépenses. Et du coup, il faut en effet savoir où mettre le curseur entre le make or buy, entre du plus ou moins managé parmi tout le panel. d'offres cloud qui nous est proposée. Et moi, par exemple, je suis souvent sollicitée sur ça, sur Marie, on se lance sur tel projet d'intelligence artificielle. Est-ce qu'il faut qu'on prenne sur étagère? Est-ce qu'il faut qu'on prenne des prestataires spécialisés dans ce genre de solutions? Est-ce qu'il faut qu'on fasse nous-mêmes, etc. ? Et ce que je leur réponds souvent, c'est tout dépend de à quel point cette partie-là, c'est votre cœur de métier ou pas. Diplomatique, vous, clairement, c'est votre cœur de métier. Vous êtes une boîte d'intelligence artificielle. C'est une autre histoire quand on est une boîte avant tout de e-commerce, typiquement, qu'on vend des vêtements, que notre cœur de métier, du coup, c'est un petit peu de marketing, un petit peu de supply, etc. Et que l'IA, ça va être pour de la personnalisation, de la recommandation de produits via de l'email, via l'interface web, etc.

47:21 Là, aujourd'hui, avec tout ce qu'on a à notre disposition, directement on the shelf, en effet, ça mérite beaucoup plus de se poser la question plutôt que de construire from scratch une équipe data science. Autre point, merci beaucoup Mehdi d'avoir insisté plusieurs fois sur des petites pépites françaises, parce que, je me permets de le dire n'étant pas française, le français n'est pas toujours très fier, il parle pas mal de ce qui ne va pas super bien, et moins des belles réussites. Or, la France n'a vraiment pas de quoi rougir sur le sujet de l'intelligence artificielle. On est sur à la fois un vivier, de talent, une source de recherche énorme à l'échelle internationale. Je veux dire, on a quand même Yann Lequin, qui est une référence dans le domaine des réseaux neurones. Facebook, n'y s'y est pas trompé, a été choisir un Français pour prendre la tête de ces activités IA.

48:23 Les grandes latèques, beaucoup ont ouvert des bureaux à Paris spécifiquement pour l'intelligence artificielle, pour attirer des doctorants français, des diplômés français, etc. Donc, c'est bien de se rappeler de temps en temps qu'on fait des choses très, très bien. On a une éducation très forte en la matière. On est peut-être parfois moins rapide sur la mise en prod, mais justement... Ça vaut le coup d'en discuter comme aujourd'hui pour voir comment mieux faire plus rapidement et plus efficacement en termes de coûts. Mais si, Alexis, on arrive sur la fin de ce meet-up. Déjà, j'aimerais qu'on réponde à une question qui est restée sans réponse pour l'instant de Imen. Par rapport à tout à l'heure, quand on parlait d'entraînement. Et sa question, c'est est-ce que vous faites aussi du NAS, du Neural Architecture Search, de manière automatique ou pas? Tu as parlé de grid search. Pour ceux qui ne connaissent pas ce vocabulaire, quand on entraîne des modèles de machine learning, il y a tout un tas de paramètres.

49:25 Le modèle, c'est la machine. La machine, elle a plein de boutons. Et il faut savoir un petit peu sur quel bouton on va appuyer. Et là, en l'occurrence, sur les réseaux de neurones, on peut jouer sur tout un tas de paramètres, mais on peut aussi jouer sur l'architecture elle-même du réseau. Est-ce que vous itérez sur les architectures de manière automatique ou pas en interne? Nous, à Diplomatique, pas spécialement, on va dire, on essaie de prendre celles qui sont les dernières sorties ou qui sont l'état de l'art. On va lancer des entraînements jouant sur les hyperparameters, sur cet ensemble de... d'architectures qui sont disponibles, mais on ne va pas modifier à la volée les architectures. C'est dans les cartons. On a des livres qui nous permettent de faire ça, mais c'est plus en projet à caton que quelque chose qui est vraiment aujourd'hui en production. Merci beaucoup Alexis. Si j'essaie de… Pardon, Mehdi, bien sûr. Je me permets juste de compléter de manière pragmatique de ce qu'on a pu voir chez des clients sur ces aspects de recherche de meilleurs réseaux.

50:29 L'approche la plus pragmatique et qui offre les convergences les plus rapides est une approche bayésienne de recherche du paramètre. C'est ce qui permet d'aller le plus vite, de sélectionner le plus vite le meilleur set de modèles. Merci pour la précision, Mehdi. S'ils essayent de faire un petit résumé de tous les conseils que Mehdi et Alexia ont partagé avec nous aujourd'hui pour garantir la réussite de vos projets d'IA, c'est la qualité du cadrage, comme dans beaucoup de projets. Petite spécificité par rapport au fait qu'on est sur de l'IA, c'est le fait de bien définir là où les quelques métriques qu'on cherche vraiment à optimiser et aller jusqu'à la définition, typiquement avec les data scientists, de la fonction de coût, c'est-à-dire la façon dont le modèle va vraiment optimiser ses prédictions pour répondre à votre problématique métier. Le deuxième point, c'est un petit peu tout ce que je mettrais dans le conduit du changement, c'est vraiment réfléchir, ok,

51:34 mon algo c'est bien, il est performant, mais en fait il s'intègre dans quel processus métier, qui va l'utiliser, comment, il ne faut pas que ces personnes-là soient bloquées, il faut qu'elles comprennent comment il marche, donc aussi des questions à se poser sur l'explicabilité. Troisièmement, la guerre de base sur le machine learning, cette question de la représentativité des jeux de données. Donc toujours que cette question soit une obsession pour vous, de vous dire est-ce que j'entraîne mon algorithme sur des données qui sont ultra représentatives de la vie réelle et tout ce qui va avec, de détection sur le terrain d'anomalies, de stratégie de réentraînement, etc. Et quatrièmement, je pense que cette question d'anticipation et de gestion de l'aspect matériel et du coup de l'aspect financier, c'est aussi une clé de réussite des projets pour éviter des mauvaises surprises. Donc, être plutôt proactif là-dessus, se poser à cette question du make or buy, se renseigner sur les différentes offres qu'on a via les cloud providers, savoir trouver la bonne.

52:43 Pour ses besoins. Et comme le disait Alexis, mettre en place un minimum de choses sur son cloud provider pour éviter de l'overspending. Donc, arrêter l'autoscaling à un certain endroit, mettre éventuellement des alertes automatiques, des choses comme ça. Je pense que ça fait déjà quatre bons axes à partager avec tout le monde. Mehdi, Alexis, est-ce que vous envoyez à ajouter à la liste? Je pense que déjà, si on se concentre là-dessus, il y aura beaucoup plus de projets en IA qui serviront les utilisateurs. Très bien, Rémi. C'est extrêmement synthétique. Merci, Marie. Je finirai par deux one-liners. L'époque n'est plus au POC, ça je l'entends en IA depuis à peu près 8 ans. Donc cette allitération est toujours pertinente. Et le deuxième point,

53:46 Typiquement, il s'agit aussi de la conduite du changement. Il faut peut-être faire passer les data scientists, les ML engineers dans une approche beaucoup plus opérationnelle et peut-être un peu moins dans les aspects compétition Kaggle, qui sont honorables pour l'apprentissage, mais qui peut-être sont moins pertinentes pour les aspects de production. Voilà, pour ce que c'est. J'ai vu un grand sourire sur Alexis au moment de l'association Caguel. Non, ce que je veux dire, c'est parce que c'est un problème qu'on a eu au début de la startup quand on ne savait pas vraiment où on voulait aller. Mais en fait, un réseau qui a 95% d'accuracy, enfin de précision, c'est largement suffisant. Et il vaut mieux mettre ça en production et voir quelle est l'étape suivante, qui essaie de grappiller quelques petits pourcentages, parce que ça va ralentir, ça va servir. Pas spécialement, sachant que ces pourcentages, on va pouvoir les grappiller, justement avec des nouveaux sets de données qui seront plus propres, plutôt que de faire des petites optimisations qui ne sont pas spécialement nécessaires.

54:51 C'est d'où le sourire et le point de circuler. Alors, je partage quand même le lien qui a gueule, parce que c'est vrai que dans la data, dans le monde du ML, absolument tout le monde connaît, mais parmi nous, il y a peut-être des personnes qui ne savent pas ce que c'est, Kaggle, c'est un site de compétition data science. Ils se sont diversifiés, ils ont d'autres choses aujourd'hui, mais vraiment leur cœur de métier, c'est ça. Vous êtes n'importe quelle boîte, vous avez un jeu de données, vous voulez bénéficier de plein de bonnes idées sur comment faire du ML pour, j'en sais rien, reconnaître des baleines. À un moment donné, il y avait ça. Et bien, vous partagez votre jeu de données, vous expliquez votre enjeu et le ou le... La meilleure ou les meilleures équipes remporteront en général un prix, un prix financier avec parfois des prix très très intéressants, plusieurs dizaines de milliers de dollars. Donc Kaggle est très très très populaire dans la communauté des data scientists. Je rejoins, moi aussi j'ai eu mon petit sourire quand Mehdi a cité Kaggle, parce que c'est vrai qu'en tant que Head of Data Science,

55:56 dans mes postes d'avant, j'ai toujours été assez méfiante au moment des recrutements sur les data scientists qui parlaient beaucoup de Kaggle, parce qu'en fait c'est très peu représentatif ce que vous faites sur un Kaggle de ce que vous ferez vraiment. Dans un job de data scientist opérationnellement dans une entreprise, vous aurez tous ces enjeux de collecte de la donnée, mise en qualité, la comprendre. Et ça, sur Kaggle, on vous file un jeu de données tout propre, merveilleux. Et tout ce dont on a... à parler ensuite sur vraiment le passage en prod. Ça, c'est complètement absent comme enjeu sur Kaggle. Et donc, si j'ai un petit conseil à donner aux CTO, VPN parmi nous, qui peut-être seraient amenés prochainement à recruter leur premier data scientist, lead data science ou autre, c'est de veiller à ça, de veiller à... Au focus production des personnes que vous interviewez, en tout cas si votre but c'est d'aller en prod, pour éviter l'effet cagoule.

57:03 Je sais modéliser, je sais faire une petite pépite algorithmique, mais je ne sais pas la mettre en prod. Je vous remercie chaleureusement, Mehdi et Alexis. C'était un vrai plaisir d'échanger avec vous aujourd'hui sur ce sujet. En plus, avec plein de retours terrain comme on aime. Maintenant, on passe sur les tables de networking. Pour ceux parmi vous qui ne connaissent pas le principe, vous allez voir des petites tables apparaître à l'écran. Et puis, vous pouvez rejoindre une table sur laquelle vous verrez d'autres personnes pour poursuivre la discussion. Tout simplement. Et Alexis, je crois que vous avez un petit peu de temps justement pour continuer à parler avec les participants. Oui, tout à fait. On sera chacun sur une table, je pense, au début. C'est différentes questions à différents niveaux. N'hésitez pas à venir nous parler. Super. Et c'est parti. Merci. Beaucoup, encore. Merci. Au revoir. Je vous invite à partager.