Retex sur plusieurs projets d'IA générative du produit à la production

0:00 Ce que Manuel ne disait pas, c'est qu'il y a aussi l'efficience dans les équipes, elle se développe aussi justement avec l'altérité. Donc, puisqu'on est dans le thème de l'efficience, ce n'est pas uniquement prendre une douche et ne rien faire, c'est aussi avoir autour de soi des personnes différentes et comme ça, on est beaucoup plus efficient. Message personnel. Alors, notre prochaine session va nous permettre de bénéficier d'un retour d'expérience, encore un, et c'est formidable, sur l'IA générative du produit à la production. Là, il fallait au moins deux personnes pour traiter de ce sujet-là. Donc, je vous demande d'accueillir le duo composé de Maxime Thoonsen, qui est CTO de Théodo Group, et de Pierre-Henri Cumenge, CTO de Sicara. Messieurs. Maxime et Pierre-Henri, y a-t-il besoin d'une zapéto? Oui. Alors je vous laisse le zapéto. S'il y a un problème, vous savez où me trouver. Je descends. Merci beaucoup. Merci. Bonjour à tous. On est très content de vous retrouver avec Maxime pour vous partager quelques retours d'expérience.

1:05 Donc, Thodo, on est une société de service, donc on a la chance de faire des projets à la fois pour nous, pour nos équipes en interne et pour des clients, ce qui nous permet d'avoir une certaine variété de cas. Pour me présenter rapidement, je suis le sitio de Sicara, qui est l'entité spécialisée en data du groupe. Les gens que j'ai l'habitude de manager, c'est plutôt des data engineers et des data scientists. L'idée, c'était aussi d'avoir un regard croisé avec Max, qui vient plutôt du... monde du dev et qui va se présenter. Exactement, bonjour à tous. Donc moi, Maxime, CTO de l'entité web du groupe, pas du groupe, et moi j'ai plutôt l'habitude de travailler avec des software engineers et depuis le début de l'année, on travaille de plus en plus avec l'IA générative pour créer des features pour nos clients, des features d'IA générative. Et du coup, avec PH, on va vous faire un retour de quelques projets et de quelques apprentissages qu'on a eus les derniers mois. Et pour commencer, on l'a vu, on en parle beaucoup à ce summit, l'IA est en train de changer le monde. Et petite question, aujourd'hui, parmi vous, je ne vous vois pas trop, mais qui a déjà au moins lancé un POC de produits d'IA générative chez vous, dans vos équipes?

2:19 Levez la main. On est à peu près à 50%. Quel hasard magnifique. Donc le 50%, c'est le résultat d'une étude IBM cet été. Donc je pense que ça a un peu augmenté depuis. On va le voir, c'est hyper facile de créer d'époque et de mettre en production les premières features, mais rapidement, on tombe sur quelques écueils, n'est-ce pas Pierre-Henri? Effectivement, je pense qu'il y a des... Pour ceux qui ont... Oui. Bien sûr. Ça ne bloque pas l'écran? Très bien. Parfait. Donc, comme disait Maxime, je pense qu'on a tous rencontré plus ou moins les mêmes problèmes, au moins les problèmes classiques. Donc, le premier d'entre eux, les sujets d'hallucination, au sens où souvent avoir des réponses où les réseaux vont inventer des choses, renvoyer des informations qui sont potentiellement fausses, et même ceux qui ont les plus performants, donc on pense à GPT-4 qui est indiqué au sommet de ce benchmark, renvoie quand même quelques pourcents d'erreurs.

3:33 Deuxième sujet, proche mais un peu différent, on n'a pas de maîtrise absolue sur les retours. Je vous donne un petit exemple là, où on demande à, c'est OpenAI en l'occurrence, de ne pas mettre de smiley dans ses réponses. La première chose qu'il fait, c'est évidemment une réponse avec un petit smiley à la fin. Les réponses pour nous qui sommes habitués à avoir des sites web, des apps mobiles qui sont en général très performantes, peuvent paraître assez lentes, surtout quand on va faire plusieurs appels à des réseaux assez gros. On se retrouve avec plusieurs secondes, voire de l'ordre de la minute si on a plusieurs appels qui s'enchaînent. On n'est pas forcément habitué à ça. On a aussi des problèmes de sécurité. Il y en a qui sortent régulièrement. Pour ceux qui suivent l'actualité des chercheurs, il y a quelques jours, on a découvert qu'en demandant au réseau juste de répéter un mot jusqu'à l'infini, Spontanément, il va aller ressortir des informations confidentielles issues des données d'entraînement qui lui ont été données.

4:40 Ensuite, les coûts. Pour ceux qui ont essayé d'envoyer, d'appeler l'API d'OpenAI, ça peut monter assez vite. Pareil, même si on veut déployer un réseau, il y a un coût d'infrastructure qui est derrière, même si on le fait soi-même sur des open sources. Et dernier point, l'écosystème. Mais voilà, très rapidement, je vais raconter deux petites mésaventures en quelque sorte qu'on a eues. La première, c'est un projet sur lequel on a travaillé en début d'année. Et à un moment, on demandait une réponse qu'on voulait récupérer sous un format assez propre, sous format JSON. Donc l'équipe a travaillé pour s'assurer qu'on avait bien le bon format et qu'il n'y avait pas de ratage à ce niveau-là. Et un mois plus tard, il y a OpenAI qui sort une feature qui répond complètement à ce problème. Donc on peut se dire qu'on a un peu travaillé pour rien. Même chose sur un autre projet où on travaillait pour une société qui voulait générer des biographies et avoir un assistant qui aide à générer des biographies automatiquement. Donc on est sur des volumes de textes à générer qui sont assez costauds.

5:44 Et donc l'équipe a fait pas mal de travail pour la générer de manière progressive, pour contourner le problème de limitation de nombre de tokens, c'est-à-dire la taille de texte que peut prendre ou générer un... Un réseau et en fait un mois plus tard il y a Cloud2 qui sort qui va jusqu'à 100 000 tokens ce qui couvrait largement les besoins donc en fait on a pu simplifier ça énormément pour la solution qui a été conçue à la fin donc pareil du travail potentiellement inutile sur le sujet donc on peut se demander à quoi bon est-ce qu'il faut pas attendre que l'écosystème mûrisse néanmoins il y a quand même des Des signes très positifs. Je vais passer là-dessus. C'était une salle d'il y a deux semaines. sur les remous d'OpenAI, mais maintenant c'est du passé. Je vais laisser la main à Maxime pour la partie positive. Je vais récupérer la zapette. En mars dernier, avec des potes du Boncoin et quelques collègues, on a lancé un meet-up sur l'IA générative.

6:47 L'idée, c'est qu'on a fait venir des gens qui partageaient leur retour d'expérience sur comment ils ont mis de l'IA générative en production dans leurs produits. Et on a appris tous plein de trucs depuis. Et je vous partage un peu les quatre exemples que j'ai particulièrement bien aimés. Le premier, c'est Vincent qui est en train de créer une... Une startup qui s'appelle Webin qui permet de faire de l'A-B test qui est géré par des LLM et il a des bons résultats parce que pour un de ses clients il a réussi à augmenter le taux de conversion d'un site e-commerce de 8% ce qui est vraiment pas mal. Un autre exemple dans l'univers du gaming, une industrie qui grossit de plus en plus, on a eu deux retours d'expérience de scénario et de pop screen et en gros à ce moment là j'ai appris qu'une grosse partie du coût de création d'un jeu vidéo c'était toutes les petites assets, toutes les petites images, tous les petits textes que les gens devaient faire plus ou moins à la main jusqu'à maintenant. Et grâce à l'IA générative, le temps estimé que PopScreen nous partageait, c'est de passer d'environ

7:52 un an et demi de développement juste sur cette partie-là à environ trois mois. Donc il va y avoir des gains monumentaux dans la génération de ce jeu. ses assets et dans le développement des jeux vidéo. Un autre exemple, c'est 360 Learning, qui est une plateforme de cours en ligne que vous pouvez utiliser pour faire des cours pour votre entreprise. Il y a une nouvelle feature qui vous permet, si vous avez des cours internes chez vous, vous uploadez le PDF avec tout le savoir de votre entreprise. Et en quelques dizaines de secondes, 360 Learning va pouvoir vous générer le cours, générer les questions, des quiz sur la thématique du cours, ainsi que les réponses. Donc du coup, l'intégralité du parcours un peu pédagogique est réalisée en quelques dizaines de secondes, ce que ma mère, qui est prof, aurait bien aimé avoir au début de sa carrière, je pense. Et un dernier exemple que j'ai trouvé vraiment hyper impressionnant, c'est Goodjob. Goodjob, leur métier, c'est de trouver, enfin ils font de l'intérim, ils trouvent,

9:00 par exemple, s'il y a une grande surface qui a besoin de 20 personnes pour faire un inventaire jeudi prochain, ils vont trouver ces 20 personnes et ils vont les mettre en relation avec la grande surface. Et du coup, il y avait une grosse étape d'appeler des gens pour les sourcer, pour les qualifier. Est-ce que tu as le permis? Est-ce que... Plein, plein, plein de trucs. Et du coup, ils ont pu automatiser une grosse partie de ce process de sourcing de candidats en no-code avec Make, GPT et Twilio pour conversationner et pour échanger avec... les candidats. Et du coup, ils ont fait quasiment x100 sur leur capacité à sourcer des candidats. Et donc du coup, en termes business, avant, ils répondaient à 70% des demandes de leurs clients. Maintenant, c'est passé à 100% et il y a un impact de 30% du revenu. Donc, on le voit, il y a quelques industries qui ont trouvé comment utiliser les génératives et il y a un super gain direct. Je ne parle pas aussi des business de call center ou pareil. Sur le support, il y a plein de use cases.

10:03 Donc ça, c'était un peu autour de nous, ce qu'on a vu cette année. Et on va aussi vous partager des histoires où on a été un peu plus proactifs. La première, pour un client de Theodo, leur business, Ecoline, leur business, c'est de faire un outil pour faire de la veille réglementaire. C'est quoi? Imaginez que vous avez une usine, une fonderie, donc il y a plein de normes à respecter pour que votre fonderie soit norme. Par exemple, il faut que l'extincteur soit exactement à 2,50 m de la porte de sortie, sinon c'est un défaut de norme et vous pouvez avoir des ennuis. Il y a comme ça des milliers de normes à respecter, ce qui est très pénible. Et donc, pour aider, ils ont fait un logiciel pour, en gros, c'est comme une énorme checklist dynamique en fonction de votre contexte, avec justement tout ce que vous devez respecter. Ils avaient un problème, c'est que pour rechercher un texte de loi, pour savoir s'ils étaient aux normes, parfois les gens utilisaient des vocabulaires métiers qui ne matchaient pas avec les vrais textes de loi.

11:09 Par exemple, la loi AJEC, dans le métier, ils tapaient AJEC, mais ce n'est pas écrit comme ça dans les textes de loi, donc ça ne remontait pas. L'autre exemple, c'est par exemple un truc beaucoup plus bateau. Genre, si quand on cherchait chaudière, en fait, dans la loi, ce n'est pas écrit chaudière, c'est écrit système thermodynamique. Donc, du coup, ça ne marchait pas. Donc, c'est un peu embêtant. leur recherche en full text search ne fonctionnait pas. Du coup, c'est un super cas pour faire une recherche sémantique. Comment ça se passe une recherche sémantique pour ceux qui n'ont pas encore expérimenté? Grosso modo, on prend un corpus de texte, on en fait des vecteurs. Ensuite, on prend l'input d'un utilisateur, on en fait aussi un vecteur. Et après, on va faire une recherche mathématique qui est un calcul de distance toute simple. Et les objets les plus proches de la question de l'utilisateur, généralement, contiennent l'information qu'on cherche. Donc on a mis ça en place, ça a donné les premiers résultats, mais il y avait encore 40% d'erreurs. Donc ce n'était pas assez pour aller en prod. Et là, on a eu une idée, c'est qu'on a utilisé GPT pour rajouter du contexte aux recherches.

12:19 Parce que les recherches type AJEC, qui sont des acronymes business, en fait, pareil, d'un point de vue sémantique, ça ne marchait pas. Il n'y avait pas assez de contexte. Et donc, du coup, on a utilisé GPT. Donc, par exemple, quand vous tapez sur GPT, c'est quoi la loi AJEC? En fait, c'est génial, GPT les connaît. Il peut sortir une phrase entière et cette phrase entière, en fait, on peut l'utiliser pour en refaire un vecteur. Et là, on va trouver les lois qui correspondent bien à ça. Donc, la petite astuce que je vous partage, c'est que potentiellement, quand vous avez une recherche de similitude qui ne marche pas, vous pouvez rajouter une étape pour recontextualiser avec GPT. D'habitude, on l'utilise plutôt à la fin pour générer la réponse à l'adjudicateur et pas avant la recherche, mais dans ce cas-là, ça marche bien. Et d'un point de vue implémentation, vous voyez, ça se tient en quelques lignes avec un prompt et une étape de génération de texte en appelant OpenAI avant de faire la recherche dans mes lignes.

13:24 Et le résultat sur le produit, c'est qu'on a une recherche qui fonctionne et on a divisé par 8 les erreurs. D'un point de vue business, c'est quoi l'impact? Il y a le produit, les utilisateurs sont plus contents et eux, ils ont constaté qu'ils avaient 11% d'appels au support en moins, ce qui correspond à un demi-ETP. Et petit instant autopub, tout ça c'est fait en PHP. Il n'y avait pas de long chain en PHP. Long chain c'est un framework ultra connu en Python pour faire ce genre de choses. Et comme mon client a une stack en PHP, cet été, au grand dam de ma copine, j'ai développé un long chain en PHP. Ça s'appelle Elephant, c'est sur GitHub. Si vous voulez essayer, n'hésitez pas, ça me fera plaisir. Merci Maxime. Deuxième exemple, là c'est dans l'industrie, pour un acteur industriel qui est dans le monde entier et qui travaille avec énormément de fournisseurs.

14:27 En fait, un de leurs problèmes, c'était la gestion des factures des fournisseurs, dans le sens où il faut arriver à associer une facture avec les bons de commande qui ont été générés auparavant. Pour s'assurer que tout va bien et avant de mettre la facture au paiement. Ce qu'on observait, c'est qu'il y avait des grosses lenteurs liées au traitement manuel de cette vérification. Et en fait, la chose clé ici, déjà, c'était vraiment la partie produit, qui est d'identifier, puisque c'est le sujet de l'efficience aujourd'hui, là on est sur un sujet d'efficacité opérationnelle. où le but c'est d'essayer de trouver où est-ce qu'il y a des points qu'on peut vraiment améliorer. Et donc ce qu'on voit c'est que la première partie du travail en fait elle n'est pas du tout technique, elle est vraiment d'identifier les endroits où il y a des gros gains à trouver. Et donc en l'occurrence c'est dans cette phase d'analyse directe du document. Derrière, la première chose c'était d'identifier quelle est l'architecture qui va avoir du sens, où est-ce que les LLM vont vraiment apporter de la valeur.

15:29 Et potentiellement ça peut être à plusieurs endroits pour effectuer ces opérations. Sans forcément se poser la question de sur-optimiser, d'optimiser les coûts, d'avoir le LLM le plus léger, etc. Parce qu'en fait derrière, le but c'est d'avoir compris où est-ce qu'ils interviennent, et après on peut faire les modifications, et là encore une fois c'est relativement simple, ça se fait en quelques lignes de code. Donc là ce que vous voyez c'est que finalement j'ai presque une dizaine d'utilisations différentes, donc d'appels à des LLM dans la chaîne complète qu'on met en place. Donc ça c'est dans une deuxième phase du projet où en fait on va aller analyser tous les endroits où on fait des appels, en l'occurrence à l'API de PonyEye, pour voir si ça a du sens. De le faire avec telle ou telle version. Et ce dont on se rend compte, c'est qu'il y a une partie des cas où on a vraiment besoin d'une réponse précise où la version GPT-4

16:30 est nécessaire, et deux endroits où on peut gagner à la fois en performance, en temps et en coût, en passant sur du 3.5. Autre point là-dessus, toujours sur le même exemple, c'est vraiment prendre du temps sur la partie analyse produit, analyse des résultats, avec quelqu'un qui connaît bien le métier. C'est pas moi, je suis pas expert facture. Mais pour vraiment voir tous les petits cas d'erreur. Et en fait, ça va servir à deux choses. Évidemment, déjà améliorer la performance de notre chaîne. Et deuxièmement, ça permet aussi de définir un ensemble de cas de test, donc finalement un dataset de test sur lesquels on va pouvoir se baser derrière pour s'assurer qu'on garde un même niveau de performance avec les évolutions dans le futur. Donc là, le détail de traitement, alors il y a une petite arnaque, c'est que les deux minutes, ça ne porte que sur une partie de la chaîne. Donc la partie qui était la plus problématique, c'était, comme je vous disais, la partie analyse des factures pour voir où étaient les écarts entre la facture envoyée et le bon de commande initial.

17:41 Et en fait, ce qui faisait que ça prenait trois mois, donc ce n'est pas trois mois de temps passé par un humain, mais c'est plutôt qu'il y avait beaucoup d'attentes. Parce que les équipes étaient débordées pour essayer de traiter l'ensemble des dossiers. On va passer à un autre exemple, ce coup-ci, des projets internes. On a fait pour nos équipes et en open source. On va vous parler, Maxime. Oui, on a fait Quiver, qui est un outil de RAG open source, qui a été number one sur GitHub pendant quelques temps. Et Icarus, c'est pareil, c'est un RAG qui nous permet d'aller chercher n'importe quelles informations dans notre base de connaissances. Donc, il y avait HubSpot, Notion et quelques autres sources. Là, un des learning produits, c'est qu'on l'a vu, les applications, vous avez peut-être vu, c'est qu'au début, quand vous posez une question à ChatGPT ou à Bard, ils vous donnent une réponse, vous n'êtes pas tout à fait serein, vous ne savez pas s'ils vous mitent ou pas. Donc du coup, c'est un des problèmes inhérents à ce genre de produit. Et un truc qui a super bien fait Bard dès le début, c'est qu'ils ont montré les sources de pourquoi ils répondaient à cette question.

18:47 Et donc ça, d'un point de vue produit, on conseille de faire la même chose. Si d'afficher les sources pour indiquer d'où viennent les informations dans un rag, ça permet d'augmenter vachement la confiance dans le produit. Deuxième problème classique, c'est qu'on n'a pas forcément de vérité absolue sur ce qu'est une bonne réponse dans ce type de cas. Donc l'évaluation technique de« est-ce que j'ai un bon niveau de performance? » n'est pas forcément évidente. Donc là, par contre, ce qui est très facilement faisable, c'est de développer une interface, en l'occurrence avec des outils assez connus dans le monde de la data, qui sont Streamlit et Chainlit, qui permettent de voir au fur et à mesure quels sont les résultats et de tester en live les réponses en fonction des modifications que je peux faire. Pour info, Streamlit, ça permet de développer des interfaces, c'est du Python derrière. Et Chainlit, ça permet de rajouter une partie chat, si notre sortie, c'est un chatbot, pour simuler un chatbot dans une phase de développement.

19:49 Derrière, Langsmith, qui fait partie de l'écosystème de l'angchain dont parlait Maxime tout à l'heure, va récupérer l'ensemble des logs des interactions qu'on a avec le LLM. Donc là, en l'occurrence, c'est très facile de le connecter avec Chainlit aussi. Et ce qu'on a observé, c'est que c'est extrêmement utile comme interface pour travailler avec le Product Owner, en l'occurrence, sur ce projet. Donc, pas forcément technique, mais on a une interface simple et très compréhensible qui permet d'analyser les réponses et de voir tous les petits problèmes qui peuvent se poser. Autre petite astuce du X, de produit plutôt, on a un trade-off entre le fait de répondre tout de suite, encore une fois, qui est une attente qu'on commence à avoir de plus en plus aujourd'hui, et le fait d'avoir une réponse la plus pertinente possible. Et donc là en fait ce qu'on peut faire dans le contexte d'un RAC, donc de recherche sémantique dans un corpus de documents,

20:53 c'est qu'en fait on s'est rendu compte que les gens étaient beaucoup plus satisfaits si on leur envoyait d'abord la liste des documents pertinents a priori, ce qui peut être fait très rapidement parce que là c'est juste du matching vectoriel. Et derrière, la partie qui prend un peu plus de temps, qui va être l'appel au LLM pour aller générer une réponse à partir de ce document et identifier le document le plus pertinent parmi ceux-là, elle arrive après dans un second temps, mais l'utilisateur a déjà eu un premier élément de réponse qu'il peut aller explorer de suite. Ce qu'on observe, c'est que les premiers résultats, c'est qu'il y a 30% des gens qui s'en servent de manière quotidienne. parmi ceux qui ont installé l'outil. On a eu aussi des apprentissages transverses sur tous ces projets. Le premier sur la sécurité, on en a parlé rapidement. Tous les LLM sont sensibles aux prompt injections. C'est compliqué de s'en protéger. Donc là, un exemple où quelqu'un fait une prompt injection dans un CV pour que si un système automatisé qui lit le CV, son CV est hyper recommandé.

22:00 Pour se protéger de ça, il y a une technique qui s'appelle les pre-flight prompt. Comment ça marche? C'est que vous faites un premier appel test à un LLM avec un prompt hyper simple, genre« retourne-moi dog». Et vous ajoutez l'input de l'utilisateur. Et si l'input de l'utilisateur contre cette instruction hyper simple et que vous ne recevez pas dog, vous savez qu'il y a une grosse probabilité qu'il y ait une prompt injection. Et donc, du coup, vous ne faites pas, vous pouvez empêcher de faire le vrai appel LLM. Donc ça, c'est une des techniques qui est utilisée pour se protéger des prompt injections. Je te laisse la suite. Dernière petite question. Je me suis posé beaucoup de questions au début sur ce que c'était que les bons profils, les bons setups d'équipe pour ce type de projet. Ça, c'est une illustration issue d'un article de blog que vous pouvez regarder qui s'appelle The Rise of the AI Engineer, qui explique très bien ce sujet-là. L'idée, c'est qu'effectivement, dans ce type de projet, on n'est pas vraiment sur des projets classiques de machine learning ou le lec. Le cœur du travail, ça va être de créer des datasets d'entraînement, d'entraîner des modèles, d'essayer d'optimiser la vitesse d'entraînement, des choses comme ça.

23:07 On n'est pas non plus sur du pur développement, parce qu'il y a un truc en plus, typiquement le fait de travailler sur les promptes, potentiellement de déployer des infras dédiées, si on veut, si on a des modèles, si on utilise par exemple des modèles open source, le fait de gérer des chaînes ou d'essayer de construire des agents, qui est quelque chose d'assez nouveau. Ce qu'on observe, c'est que pour faire un POC, Maxime en est un excellent exemple d'ailleurs, quelqu'un de débrouillard sans bagage data peut très bien aller faire des projets. L'exemple des Colines par exemple, c'est une équipe de dev qui a travaillé là-dessus et ça a très bien fonctionné. Donc la question c'est peut-être, est-ce qu'il y a vraiment besoin de gens qui savent faire de la data finalement pour ce type de projet? Sans vouloir prêcher complètement pour ma part, je suis quand même convaincu qu'il y a des choses à apporter, mais en se reposant la question de quelles sont les skills qui restent vraiment utiles. Je dirais qu'il y a trois aspects. Il y en a un premier qui est juste le fait d'avoir l'habitude de travailler sur de la donnée, aller générer de la donnée propre, travailler sur des datasets, sur les métriques associées derrière.

24:19 Ce qui me permet d'enchaîner sur le deuxième point qui est travailler sur des expériences de R&D, c'est-à-dire comment je mesure que j'ai progressé ou pas d'un cran à l'autre. Avoir un système d'expérience qui est... Et troisième point, c'est la réflexion produit autour d'outils qui sont moins déterministes que d'habitude, si je puis dire. Et là, sur ces sujets-là, c'est vrai qu'on observe qu'effectivement, quelqu'un qui a l'habitude de travailler sur des projets d'IA va être plus à l'aise. Je ne vais pas se référer là-dessus, c'est la suite logique, mais ce qu'on observe empiriquement, c'est que ça marche pas mal quand on a des équipes mixtes, tout simplement. Parce que la personne avec de l'expertise data va apporter le savoir-faire dont je parlais avant. À côté de ça, en général, on n'a pas juste la partie LLM ou call à des API, mais ça s'inscrit dans une application complète. Et en fait, on a besoin d'itérer assez rapidement sur les sujets du X pour aller justement faire tester ça à des personnes métiers qui ne sont pas forcément expertes sur ce qui marche ou ne marche pas avec des LLM.

25:26 Pour répondre maintenant à la question initiale, même si l'écosystème évolue rapidement, les gains, ce n'est pas forcément la stack complète et l'outil complet qu'on aura développé, mais c'est surtout que ça aura permis de travailler sur où est-ce qu'il y a vraiment de la valeur à aller chercher, qu'est-ce qui va impacter le business. Bosser sur sa donnée, c'est-à-dire si on a travaillé sur de la donnée propre, si je change mon modèle derrière, c'est un travail qui aura été fait dans tous les cas. Si j'ai labellisé des données pour avoir des datasets de test, c'est quelque chose de toute façon qu'on va conserver. Et enfin, il y a le fait de gagner en maturité sur les équipes, quoi qu'il en soit. Si je reprends l'exemple de GoJob qui est vraiment sympa, en fait, ce n'est pas le premier projet qu'ils ont fait. Ils ont d'abord fait quelques tests sur des projets, ils ont essayé d'optimiser les process à droite à gauche, ce qui leur a donné du recul pour ensuite comprendre où est-ce qu'ils pouvaient vraiment impacter leur business sur ce qui est leur cœur de business, qui est le sourcing des candidats.

26:30 Et c'est tout. Merci beaucoup. Quel talent! Alors on a malheureusement très très peu de minutes pour les Q&A, il y a eu beaucoup de questions quand même, vous vous êtes posé des questions tous les deux, donc peut-être qu'elles ont été adressées dans la salle. Donc on a 4 minutes, 4 petites minutes de questions. Qui lève sa petite mimine et attend Manon ou Romain pour venir le cueillir avec le micro? Ah, voilà. Monsieur. Ça va être Romain. Oui, merci pour la présentation. Alors, moi, j'ai une question par rapport... Je sais que tout ce qui est LLM, ça coûte assez cher. Du coup, il y a de nouvelles habitudes du dev à... À faire pour réduire le coût. Est-ce qu'il y a une démarche que vous conseillez pour ne pas exploser le coût sur les tests, sur l'époque, sur les devs, avant d'aller vers un mode produit? Pour l'environnement de développement, ce que j'ai remarqué sur les projets, c'est que les coûts restent assez...

27:38 Enfin, ça dépend de l'usage, mais pour développer des features simples, tant qu'on ne lance pas des énormes batchs de traitement, on reste sur des coûts raisonnables. Et donc, une des tactiques, c'est si vous avez des gros volumes de données... Alors nous, notre documentation interne, il y avait, je ne sais plus... Il y avait 30 000 pages notions, donc ça commençait à faire un petit peu d'embedding à créer. L'idée, c'est d'itérer sous des sous-ensembles pour ne pas appeler les modèles à chaque fois. Je ne sais pas si ça répond à ta question. Mais oui, pour les phases de dev, ça va. Ce n'est pas ce qui va coûter le plus cher, je pense. Je ne sais pas si tu veux compléter. Pour compléter, pour ceux qui ont vu la conf de ce matin, Même sujet, parce que les coûts, ça va être assez lié à la consommation énergétique et à l'impact écologique, évidemment. Ce qui va vraiment coûter une finée, ça va être beaucoup les coûts d'inférence, c'est-à-dire les appels qu'on va faire ensuite derrière en production s'il y a du volume.

28:44 Il y a le coût initial, c'est une grosse base documentaire à faire, pour compléter l'exemple de Maxime, par exemple. Dans notre base documentaire, on a beaucoup de documentation interne sur nos pratiques, sur les technos qu'on utilise, des choses comme ça. Et en fait, le gros du volume, c'est tout ce qui est lié spécifiquement au projet qu'on fait. Où là il y a un peu moins de valeur en termes de connaissances spécifiques de la boîte. Donc la première chose qu'on a faite, c'est de commencer par développer un outil de recherche en excluant ces pages. Qui avait beaucoup de volume et moins d'informations utiles. Très bien, merci. Merci beaucoup. Une toute dernière question. S'il y a... Oui. Bonjour. Vous calculez comment les REI sur ces projets? Évidemment, il y a un gain en efficience. cherchant dans la base de données, utilisant le système de RAG. Mais vous avez fait un calcul spécifique, peut-être que j'ai raté quelque chose. Je ne vois pas qui a posé la question. Tout en haut, là-bas, monsieur, là-bas, à gauche. Ok, d'accord. Alors, la réponse honnête, c'est qu'on ne sait pas toujours faire.

29:47 Il y a des cas où on peut le calculer parce qu'on peut faire des estimations de temps gagné, par exemple. Quand on est sur des projets où il y a un gain de revenu clair parce qu'on gagne du business, c'est un peu plus facile. Clairement, typiquement, sur notre projet interne, le ROI n'est pas évident à calculer maintenant tout de suite. Parce qu'en fait, avec l'usage, il y a un gain de« j'ai trouvé la bonne information un petit peu plus vite», ainsi de suite. Ce qu'on va faire, c'est qu'on peut faire des carottages, on va dire, pour dire« ok, sur un exemple, et on fait ça, je le fais peut-être quelques dizaines ou cent fois, on va dire« à combien de temps j'ai gagné sur une recherche spécifique? Donc ça, typiquement, dans les dojos internes qu'on fait pour sensibiliser les gens sur ces sujets, ça peut être une sortie qui peut se dire, ok, on va faire telle recherche, il y a une personne qui va la faire comme il la faisait d'habitude. Pour ceux qui ont l'expérience dans la recherche notion, personnellement, c'est une des features que je n'aime pas trop, parce que je trouve ça assez lent, versus ce que je vais faire avec le chatbot, et on regarde le temps qu'on gagne.

30:49 Ensuite, on fait des extrapolations, des règles de trois, ça vaut ce que ça vaut, c'est pas magique, mais ça nous donne une petite idée d'où on en est. Et l'autre gain immense, c'est qu'en faisant cet outil interne, on est monté en compétence. Et en fait, si on se dit que, grosso modo, on n'a pas le choix, il faut monter en compétence en IA, parce que sinon, on sera à la ramasse dans un an, deux ans. En fait, le fait d'embarquer tout le monde sur des premiers outils et de monter en compétence, ça, c'est un gain top. Comme disait PH, GoJob, ils ont commencé par des rags. Et ensuite, ça leur a permis d'avoir une compréhension un peu plus profonde des LLM. Et ils ont compris dans leur core business comment l'implémenter et avoir un super gain. Donc le retour, c'est, et moi je le vois beaucoup avec le meet-up, c'est toutes les équipes qui ont commencé à l'utiliser, il y a une différence de conversation énorme, même trois mois après, les gens deviennent experts, ils comprennent vraiment comment utiliser la technologie beaucoup plus rapidement. Donc un des gains, ça va être de maîtriser cette... Cette techno pour après soit la mettre dans le produit ou dans vos process business interne.

31:55 Voilà, merci beaucoup à tous les deux. Vous me redonnez espoir, parce que je sens que je vais gagner moi aussi en compétences pour entraîner mon petit moteur personnel. Merci Maxime, merci Pierre-Henri. Merci. C'était passionnant.