Bruno:
C'est marrant, quand j'étais gamin, on me disait que les ordinateurs faisaient exactement ce qu'on leur demandait, pas plus, pas moins. Aujourd'hui, avec la Gen AI, c'est un élève un peu plus turbulent. Parfois, il surprend, parfois, il invente carrément ses propres réponses. Mais alors, comment évalue-t-on un élève comme ça ? Est-ce qu'il suffit d'un petit test unitaire comme au bon vieux temps ? Ou faut-il plutôt distribuer des notes selon l'inspiration du moment ? Et surtout, est-ce qu'un jour, on pourra vraiment lui donner des devoirs à la maison sans qu'il hallucine sa fiche de lecture ? Pour répondre à ces questions de barbu, je ne reçois pas un prof de philo, mais il sait comment corriger une copie faite avec ChatGPT. Louis, bonjour.
Louis:
Bonjour Bruno.
Bruno:
Alors Louis, est-ce que tu peux te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Louis:
Donc, je suis Louis, le cofondateur et CTO de Dialogue, qui est une startup dans l'IA pour les sites e-commerce. Donc on fait un petit assistant qu'on met dans les fiches produits des e-commerçants pour vous aider à répondre à toutes les questions que vous avez et auparavant j'ai été développeur chez Théodo pendant 4 ans Ok.
Bruno:
Alors toi t'es une boîte AI first c'est vraiment le coeur de votre produit, qu'est-ce que ça change concrètement d'être comme ça AI first donc t'as bossé chez Théodo avant, tu connais l'industrie logicielle de manière plus classique, plus traditionnelle on va dire qu'est-ce que ça change dans la manière de travailler ?
Louis:
Je pense qu'aujourd'hui, il y a de plus en plus de boîtes qui se disent AI first. La question, c'est qu'est-ce que c'est ? Je dirais qu'en premier lieu, tu as les SaaS qui étaient là avant, qui sont établis, qui vont... Tout le monde a intérêt à mettre des features IA dans leurs produits. Donc, eux, ils vont aller... Je ne sais pas. Au lieu de pré-remplir un formulaire, ils vont, grâce à la Gen AI, te le personnaliser un peu plus parce qu'ils te connaissent. Donc, ils vont le pré-remplir différemment en fonction de chacun de tes users. Je veux dire, c'est le niveau un peu 1 de la Gen AI. Et t'as des boîtes qui n'auront davantage concurrentiel que si la data est au coeur de leurs produits, et qui auront besoin de vraiment leverager toute la data qui va être produite grâce à l'IA générative pour survivre sur le long terme et je pense que c'est ça les boîtes, qui vont être AI first c'est des boîtes pour qui la data est au coeur du projet et c'est là dessus qu'elles vont construire ce qu'on appelle le moat donc vraiment l'avantage qu'elles auront par rapport à leurs concurrentes.
Bruno:
Et donc ça veut dire que tu as des équipes qui sont structurellement différentes tu as une organisation de projet qui est fondamentalement différente de ce que tu as pu connaître avant.
Louis:
Ouais donc dans la première boîte que je décris je pense qu'en fait tu mets des bons software engineer que aujourd'hui on rebrande en AI engineer globalement tu t'appelles des API d'IA tu compose, tu gères des erreurs tu fais ton taf d'appeler des API comme on a toujours fait et tu apportes de la valeur à l'HGA et c'est top et ça marche très bien Dans notre cas, pour, pouvoir utiliser toute cette donnée qu'on a, il y a un moment où il y a besoin d'expertise et je pense d'équipe plutôt avec les profils ML Engineer. Donc moi je suis pas du tout d'accord, il y a des gens qui disent le ML Engineer est mort, tout le monde peut faire de l'IA maintenant. En fait non, quand t'es une boîte AI First qui veut utiliser la donnée, t'as besoin de gens qui comprennent comment on évalue un modèle de machine learning, qui comprennent un minimum comment concrètement marchent ces modèles derrière, les architectures transformers, etc. Et qui t'aideront plus tard à peut-être te sortir de la dépendance que tu peux avoir au grand, provider qui savent évaluer, qui savent ce que c'est qu'un A-B test parce que savoir interpréter un A-B test c'est pas non plus un truc, c'est pas forcément un skill de software engineer etc etc donc tu changes vraiment la manière, tu construites tes équipes.
Bruno:
Oui, effectivement, je suis d'accord avec toi. Je pense qu'il y a des gens qui disent que le métier d'ML Engineer, effectivement, est entre guillemets voie disparaître parce que tout le monde peut en faire. Mais en soi, je pense que de manière assez régulière, tu as des technos qui, entre guillemets, simplifient ou facilitent l'accès à certains niveaux technologiques. Tu vois par exemple aujourd'hui avec le cloud tu peux faire du scaling, que t'étais incapable de faire de manière aussi fluide qu'avant, la cybersécurité c'est un sujet qui est plus facilement taclé aujourd'hui que d'autres mais ça n'empêche pas que quand tu deviens spécialiste d'un sujet, ou que tu te focalises sur un domaine tu peux pas te contenter de produits tout fait sur étagère, t'es obligé effectivement d'avoir apporté une expertise sur ta.
Louis:
Spécialité ouais ouais c'est ça c'est moi qui suis un gros utilisateur d'AWS, je suis pas du tout aussi fort que je pense que je pouvais être, un sysadmin il y a 10 ans enfin il y en a encore mais tu vois dans la boîte classique le SaaS classique qui avait besoin de la personne qui gérait ses serveurs, sa base de données etc je suis moins fort que ces gens là je suis capable d'utiliser le cloud, en revanche si demain je lançais une boîte qui faisait du cloud j'aurais quand même besoin de gens hyper solides sur ces sujets là, de networking, de mise en place de machines peut-être même pas virtuel et c'est pareil avec l'IA si tu considères que tu fais une boîte l'IA dont c'est le coeur, t'as encore besoin de ces gens là qui savent comment ça marche derrière.
Bruno:
Ce que je trouve intéressant du coup comme sujet avec toi c'est que sur ce podcast on a déjà parlé plusieurs fois de cette notion, toute la notion sur la politique de test, t'es venu faire le compilé à l'épisode de Geoffrey où on parle de fiabilisation de l'usine logicielle, toi qui aujourd'hui est sur une solution AI First, donc tu utilises beaucoup ou des LLM qui sont au cœur de votre produit. Il y a une vraie question qu'on peut avoir aujourd'hui, c'est quand tu crées des systèmes qui sont non déterministiques, comment tu fais pour tester de manière sûre et fiabiliser au final ton logiciel pour t'assurer que ce que tu produis, garde le niveau de qualité que tu espères avoir ?
Louis:
En fait, c'est exactement la question auxquelles répondent des gens qui font des modèles de machine learning depuis assez longtemps. On va avoir envie d'évaluer comment ça fonctionne, donc ça ne va pas être aussi rouge ou vert qu'un test unitaire. Mais on va essayer de construire un dataset d'éléments d'entrée, dans notre cas ou dans le cas de chat GPT, ça va être les recats utilisateurs, et de la sortie attendue, espérée, et donc qui est dans notre cas et pareil dans le cas de chat GPT la bonne réponse ou une réponse qui est jugée comme bonne et le coeur du problème ça va être de construire première étape de construire ce dataset ce qui demande déjà un minimum d'outillage et ensuite mettre en place, des évaluations alors qu'est-ce que ça veut dire évaluer ça ? C'est un grand sujet mais mettre en place des évaluations qui vont nous permettre de dire que avant on avait un score de 85% de bonnes réponses et maintenant on est passé à 87, 88, 89 et petit à petit d'être capable de mettre à jour les modèles les promptes qu'on utilise pour essayer de faire grimper ce pourcentage.
Bruno:
Allons creuser un peu ces deux éléments que tu as évoqués déjà sur la partie outillage ça correspond à quoi ?
Louis:
C'est des outils d'observabilité alors ça reste, qui aujourd'hui sont beaucoup basés sur OpenTelemetry qui commence à être un grand classique qui n'est pas utilisé que du tout dans la partie machine learning mais, qui permet de tracer tes entrées tes sorties, le temps que ça t'a pris etc parce qu'il y a aussi est-ce que je fournis une bonne réponse mais est-ce que je la fournis vite qui est aussi important donc tout ce qui est timing on va avoir envie de surveiller tout ça donc aujourd'hui, les grands leaders du marché il y a notamment Longfuse, qui est un gros leader de l'observabilité LLM mais il y en a d'autres, qui te permettent globalement de facilement mettre tout ce que tu fais dans, tes procès de GNI dans un outil où tu pourras aller requêter, ensuite récupérer tes entrées, tes sorties, tes sorties intermédiaires, si tu as un système un peu complexe. Donc voilà, pour l'observabilité, c'est ça qu'on utilise aujourd'hui.
Bruno:
J'avais vu passer une techno, alors je ne trouve pas le nom, c'était LISP, un truc qui permettait justement d'observabilité des LLM, qui te permet de voir en fait, dans ton prompt d'origine, quel impact chaque élément enfin chaque token de ton prompt a eu un impact et a généré qui te permet de voir, comment est-ce que ton LLM a généré la réponse qu'il a généré en fait une espèce de backtrace du truc.
Louis:
Alors ça doit marcher sans doute qu'avec des en vrai je ne suis pas non plus machine learning engineer de base mais je me demande si ça ne marche pas que si tu connais un minimum les poids de ton modèle sur un modèle close source comme OpenAI ou Anthropics, je pense que ça ne doit pas marcher, mais sur des modèles où tu as accès, à tous tes poids, à toutes les couches, tu dois être capable de, a posteriori, expliquer, mais ça doit être assez... Je suis hyper curieux, si tu retrouves, de voir...
Bruno:
Je suis en train d'essayer de chercher, mais je...
Louis:
Et de voir comment ils arrivent à faire... Oui, de voir comment ils arrivent à visualiser ça. Ça ne doit pas être si simple.
Bruno:
Bon, je n'arrive pas à retrouver, écoute, je te retrouverai ça. Mais donc aujourd'hui, vous, ce que vous utilisez en observabilité, c'est quoi ? C'est juste quelque chose qui va t'étudier le temps de traitement d'une réponse, la disponibilité ? C'est quoi les maîtrises que tu ressors ?
Louis:
Ouais, alors nous, déjà derrière, j'ai envie de dire, la route de chat un peu principale qu'on a derrière Dialog, t'as en fait plein d'étapes intermédiaires avant la génération de la réponse finale, dont certaines sont des petits LLM qui vont répondre à des sous-questions de la réponse finale dont d'autres sont juste des requêtes en base de données ou à une base vectorielle, Et nous ce qu'on trace c'est tout ça, c'est l'entrée principale, le premier call OLLM avec la réponse, le temps que ça a pris, le premier call à base de données, la réponse, le temps que ça a pris, etc. Sous forme d'une trace comme ce qu'on peut avoir dans un Sentry quand tu traces tes données de performance. Et donc pour chaque trace on a toutes les observations qui ont été faites, donc chaque résultat un peu intermédiaire. Et ça c'est visualisé bien et ce qui est bien c'est que c'est intégré avec les outils de workflow, qui sont utilisés, que ce soit le long chain pour construire des ou la main index pour construire tes workflows de LLM et du coup en un minimum de temps de setup t'as accès à ça Ok.
Bruno:
Aujourd'hui ça vous permet de travailler avec n'importe quel LLM qui dispose sur le marché ou du coup ça te met des contraintes quand même sur les différents fournisseurs ?
Louis:
Non, en ensemble c'est là où les premières valeurs ajoutées, alors plutôt des outils comme Longchain et Lamarindex c'est qu'ils ont fait un peu l'adapteur entre tous les modèles du marché et les modèles se copient un peu entre eux aussi maintenant mais entre tous les modèles du marché et leurs modèles à eux donc c'est hyper facile en ligne de code tu changes le modèle tu changes le provider et quasiment tous les gros providers sont disponibles et surtout maintenant les modèles essayent d'avoir des API qui se ressemblent Ok.
Bruno:
Est-ce que vous avez quand même des tests unitaires dans une boîte AI First ?
Louis:
Oui, alors on fait quand même des tests unitaires, mais pas tant que ça sur la partie IA, plutôt, en revanche, ce qu'on peut avoir à faire, c'est de parser des outputs de LLM, donc on demande au LLM de... Moi j'ai le cas sur des... On demande au LLM de répondre dans un langage de query un peu structuré, et ça on a besoin de le parser pour le transformer en une query, alors pas SQL, mais en Elasticsearch, et donc du coup la transformation de... Ta string qui est une query par ton LLM à ta requête Elasticsearch un truc que tu as envie de continuer à tester unitairement parce qu'il y a beaucoup de logique donc oui on continue à en faire mais pas forcément sur la partie IA où là c'est plutôt l'évaluation qui prend le pas.
Bruno:
Vous avez un système d'agent où aujourd'hui tu as juste des LLM qui te sort du contenu texte que tu traites.
Louis:
Alors ça dépend de ce que tu appelles agent et disons que communément on distingue un peu deux choses c'est les trucs purement agentic, où en fait t'as un LLM qui prend des décisions d'appeler des tools, qui boucle un peu tout seul et qui quand il juge que c'est bon par rapport à un prompt il te dit c'est bon je te renvoie ma réponse, c'est ce que les gens entendent le plus souvent quand on parle d'agent mais aussi des trucs qu'on a plutôt agentic workflow où en fait c'est plutôt un assemblage de plein de LLM assemblés d'une manière un peu prédéterminée, et il se passe la balle entre eux mais de manière un peu plus déterministe que dans la partie agentic et donc nous on est plutôt sur la deuxième option, parce qu'on est dans le cadre du e-commerce, on sait à peu près quel genre de questions les gens peuvent poser sur un e-commerce on sait à peu près dans quel cas on veut appeler quel outil, ça dépend juste de l'impôt du utilisateur on a juste besoin de quelqu'un pour nous aider à décider d'où l'intérêt d'ALM mais on est capable de faire, de résumer ça sous forme d'un workflow un peu global là où quand tu utilises un cloud code ou des outils, qui ont l'air d'être beaucoup plus agentiques tu vois que c'est plus imprévisible la manière dont on va tous utiliser ça donc c'est vraiment un élève qui décide lui-même quand est-ce qu'il t'envoie la réponse quoi.
Bruno:
C'est quoi aujourd'hui ce fait que vous soyez sur cette deuxième option de style d'agent et pas sur les agents qui ont une capacité à appeler des tools c'est quoi c'est que vous n'avez pas le besoin actuellement ou il y a une volonté, de sciemment éviter ce genre de modèle.
Louis:
Alors je pense qu'on n'en a pas besoin parce que comme je disais on a une meilleure connaissance on a une bonne connaissance des workflows qu'on veut être capable de faire, L'autre truc c'est que c'est souvent un peu plus lent aussi de passer par un truc purement agentique parce que le lemme qui boucle un peu sur lui-même, ça peut prendre du temps parce que souvent t'as besoin d'un gros modèle pour orchestrer tout ça donc ça peut prendre un peu du temps et surtout ça coûte du coup souvent plus cher donc en fait tout bout à bout c'est plus intéressant pour nous d'aller sur des workflows et d'être capable de répondre en fait parfois dans certains cas très vite là où un agent, un truc purement agentique il va faire au minimum une boucle sur lui-même et ça va déjà être trop long surtout dans le cadre du e-commerce où il y a quand même un enjeu de performance.
Bruno:
Donc j'imagine que t'es différents LLM qui vont te fournir des réponses qui fonctionnent beaucoup sur des systèmes de rag tu nous as parlé de base vectorielle et autres donc je pense que tu es sur des systèmes un peu similaires, comment tu fais pour déjà pour évaluer la qualité d'une réponse, et du coup après tu évalues quoi aussi bien la qualité de ton embedding côté base vectorielle ou la qualité du LLM ou du prompt qu'est-ce que tu vas essayer de tester en priorité.
Louis:
Alors déjà c'est ce qui n'est pas évident c'est déjà de se mettre d'accord sur c'est quoi la métrique que tu cherches à optimiser, donc ça va vraiment dépendre de ton use case, si on prend l'exemple le plus simple, on va dire que c'est du routing de query, donc t'as un utilisateur qui vient faire une requête, t'as envie de la classifier dans différentes classes, donc nous dans notre cas c'est des questions sur les produits, des questions sur les livraisons, les retours ou des hors-sujets, donc là c'est assez simple dans le sens que ta métrique c'est combien, de pourcentage du temps j'ai eu une bonne réponse, après tu peux aller regarder les faux positifs les faux négatifs, donc déjà tu peux selon ton business et la manière dont c'est construit, tu peux avoir une tolérance qui est différente au faux positif ou au faux négatif Quand.
Bruno:
Tu parles de faux positif et faux négatif, c'est le faux positif d'une réponse jugée comme bonne qui en fait ne l'est pas ou c'est une c'est à quel niveau de l'impression de faux positif ?
Louis:
Si moi je suis sur un site e-commerce qui vend des voitures et je commence à te parler de dev, on est sur un truc qu'on a envie de classifier en hors sujet, si je Je le qualifie en... Dans un autre c'est un faux positif voilà je m'en brûle totalement mais tu peux avoir des modèles qui sont très qui sont précis sur certaines catégories mais qui pour autant dans sur certaines laissent passer, par exemple tu classifies trop en hors sujet trop souvent ce qui même au final sur ton dataset d'évaluation de 1000 samples a peu d'impact mais en fait ces 10 hors sujet là ils t'embêtent tellement que, t'as envie de minimiser plutôt le nombre, de hors-sujets qui ont été mal classifiés alors en fait ça marche mieux quand t'as que deux classes le faux positif et le faux négatif donc si t'as un truc dans le sujet et un truc hors-sujet tu peux avoir envie plutôt de te tromper dans un sens que dans l'autre, c'est-à-dire te mettre plutôt des hors-sujets dans la catégorie, in-topic que de classifier trop de in-topic dans la catégorie hors-sujet.
Bruno:
Ah bon ? T'aurais pas plutôt...
Louis:
Là j'ai essayé d'expliquer rapidement mais toujours est-il que quand t'as une classification à deux états tu peux te tromper soit en mettant, des éléments qu'aurais dû aller dans le bucket A dans le bucket B soit en te trompant en mettant des éléments du bucket B dans le bucket A et avoir des scores qui sont semblables et toi selon ton business selon ce que tu testes c'est comme l'histoire des tests Covid on en parlait beaucoup à cette époque là tu préfères avoir, trop de A dans B ou trop de B dans A selon ton truc dans le cas du Covid c'est que dans l'ensemble dans le cas des tests des malades on préfère, dire à quelqu'un qu'il est malade alors qu'il ne l'est pas plutôt que dire à quelqu'un qu'il est malade qui en fait il l'est pas exactement voilà donc c'est tout ça donc ça ça dépend de ton métier ça dépend de la question que tu poses à chaque fois quoi.
Bruno:
Ok mais donc sur cette évaluation c'est à dire que le le, Ce qui est compliqué avec les LLM, c'est que du coup, c'est un outil qui est non déterministique. Sauf si tu arrives à faire en sorte d'ajouter du déterminisme dans ton système. Mais je pense que ce n'est pas forcément ce que vous recherchez. Mais comment tu fais pour t'assurer que ton évaluation de ce que tu considères comme étant une bonne réponse est juste ? Parce que ça passe par un LLM aussi, cette évaluation-là ?
Louis:
Alors là, tu as deux options. Première étape, labelliser tes questions. Donc tes questions dans le sujet questions produits, questions sur les retours, tu les labellises à la main bon ça sur un cas comme le routing c'est un humain qui est capable de pas trop se tromper et il n'y a pas trop de débat mais parfois tu peux avoir débat c'est pas tout le temps évident si tu poses une question si t'es sur une question sur un retour mais qui est spécifique à un produit qui a des conditions de retour particulières est-ce que c'est une question sur le produit ou une question sur les retours en général même là tu peux avoir des cas où tu dois labelliser ça à la main et tu dis bon je sais pas trop en fait, donc t'as quand même déjà un enjeu là dessus et ensuite si tu veux le faire, un peu scaler ce truc là tu vas vite avoir envie de demander à un LLM de classifier pour toi donc dans l'ensemble tu vas prendre un LLM plus gros que celui que t'as en production, plus intelligent pour classifier pour toi les bonnes réponses et les mauvaises réponses en espérant qu'ils se trompent pas mais là t'as une marge d'erreur déjà, et ensuite tu vas faire tourner, ton prompt ou en tout cas ton algo qui prend les données d'entrée, tu vas lui faire, craché ses données de sortie à lui et tu vas comparer par rapport à ce que tu avais labellisé et là dessus tu vas pouvoir calculer ton taux de faux positif, ton taux de faux négatif, ta précision et en fonction de tout ça et de la latence et peut-être du coup tu vas pouvoir prendre une décision de quel modèle tu maintiens en prod ok.
Bruno:
Ce qui me semble aussi un petit peu abstrait, en tout cas, je n'ai peut-être pas encore suffisamment d'expérience sur ces sujets-là, mais c'est que si moi, je vais te faire renaître tous mes tests unitaires, tes intégrations et tes tests end-to-end, sur une code base traditionnelle qui ne contient aucun LLM, si à un moment, je détecte qu'il y a certains résultats qui ne sont pas adaptés, je peux remonter la chaîne de valeur et voir qu'en fait, je peux retrouver le moment de l'opération qui a posé problème. Là, toi, aujourd'hui, entre ton embedding d'un côté sur ta base vectorielle, ton prompt qui est fait la manière dont tu vas requêter ta base vectorielle pour récupérer les trucs, il y a beaucoup d'éléments, et surtout, c'est difficile de savoir, de mon ressenti en tout cas, c'est difficile de savoir, quel élément de ton prompt ou quel élément de ton embedding a généré ce petit changement de réponse et autres, comment tu fais en fait pour, identifier d'où vient la source d'un problème quand tu détectes que ça va pas dans le bon sens.
Louis:
Alors il y a c'est assez bon déjà il y a des systèmes que tu sais que tu veux évaluer donc là je prends l'exemple de ton système de routing tu sais que tu veux l'évaluer, ton entrée est claire c'est la courroquette d'utilisateur, peut-être plus historique comme ça c'est jamais totalement clair, ta sortie est à peu près claire, c'est les classes qu'on t'a données et c'est assez facile de savoir, et t'as un composant milieu qui est censé te classifier ça peut être un ILM, ça peut être un modèle sur mesure de NLP classique mais c'est assez simple et là, a priori t'as pas d'histoire d'embedding ou alors tu considères ton modèle comme une black box et voilà dans le cas du, toi tu parles plus de la partie rag et de comment t'évalues la réponse finale pour la construire t'as commencé par récupérer des documents. Pour récupérer ces documents du coup t'as fait une recherche peut-être une recherche sémantique mais d'ailleurs même pas sûr et euh... Et avant ça, du coup, tu as utilisé un modèle d'embedding pour les transformer en vecteurs. Et avant ça, tu as utilisé une requête spécifique qui n'est peut-être pas la requête du utilisateur pour aller requêter ta base de données. Donc tu as plein d'étapes. Une approche, c'est juste de dire, en gros, ma grosse black box, mon entrée fixée, c'est l'input de l'utilisateur et son historique à lui. Et ma sortie, c'est là où... À voir, mais nous, ce qu'on considère aujourd'hui, notre sortie, c'est les documents qu'on va donner au LLM final. Pour répondre pourquoi ? parce qu'en fait on n'en est pas encore à si on avait notre propre LLM pour faire la génération de la réponse finale on aurait envie de l'évaluer aujourd'hui on n'est pas encore à évaluer à quel point, Sonnet ou GPT-5 est capable une fois qu'il a la bonne réponse de effectivement la donner donc on s'arrête plutôt à l'étape d'avant parce que c'est là où nous on a le plus de valeur ajoutée et. À partir du moment où tout ça s'est fixé le reste tu peux tout faire, enfin tu fixes ton entrée c'est la requête plus historique ta sortie c'est les documents que tu veux avoir en output et le reste tout est variable, tu évalues tout ton système donc tu peux tout faire varier, est-ce que ton modèle d'embedding, ta manière de retrieve est-ce que c'est sémantique ou pas, et tout ça tu fais varier et tu peux comparer alors là tu as plein de possibilités différentes mais au moins tu as une baseline qui est là.
Bruno:
Est-ce que ça veut dire que dans votre démarche de production logicielle, tu t'approches parfois un peu plus d'une démarche très orientée recherche ? C'est-à-dire qu'en fait, tu vas tester plusieurs approches, tu vas voir un peu les différents résultats et du coup, tu en choisis une, plutôt que ce qu'on fait en dev de manière plus traditionnelle, où en général, en fait, tu fais un choix d'implémentation, tu le mets en prod et après, tu vas corriger les petits problèmes ou les effets de bord qu'il peut y avoir. Donc, on ne teste pas plusieurs implémentations d'une même feature.
Louis:
Alors concrètement comment on a fonctionné nous c'est qu'on a commencé par mettre en prod le truc le plus simple pour nous et pour moi quand j'avais pas encore de ML Engineer pour m'épauler, donc c'était appelé des LLM un peu choisi au hasard et on voit ça nous fait une baseline et ensuite ouais on est carrément dans une démarche où, on essaye de faire de la recherche donc c'est un grand mot parce qu'on écrit pas encore de papier mais peut-être un jour mais moi j'aimerais bien que quand la boîte grossisse on puisse faire ça, et ouais on a une démarche, en tout cas qui est clairement expérimentale sur certains aspects. Donc par exemple on est tout on lit les papiers qui sortent sur, on a des newsletters qui t'envoient un peu les papiers, il y en a énormément qui sortent sur la partie Gen.ai, t'en as plein sur comment en ce moment le grand truc c'est le contexte engineering donc comment tu crées justement le contexte pour ton LLM et on regarde ça de près, on essaie de comparer les approches, comparer la manière de compter, la manière de re-ranker tes documents après, sur un re-ranker, quelle est la bonne approche, comment tu... C'est vraiment très, très itératif et du coup on compare ensemble deux, trois approches, mais tu peux les comparer, ce qui est bien c'est que ton dataset de... De questions et de documents derrière tu es capable d'itérer dessus et de savoir que ton score actuel c'est je suis à 85% de bonnes réponses c'est ta baseline et après tu essayes mais parfois on essaie des trucs qui sont pas meilleurs et c'est là où c'est de la recherche tu testes un truc t'es pas sûr d'avoir un résultat.
Bruno:
Donc ça change un peu ta manière de produire du call entre guillemets enfin de produire de la feature.
Louis:
Ouais mais alors du coup ce process le moment où on commence à vraiment mettre en place ce process d'évaluation, et de recherche c'est quand la feature elle est déjà en fait elle est déjà live là où le paradigme du, machine learning a un peu changé c'est qu'avant pour faire du machine learning il fallait avoir beaucoup de données pour pouvoir aller tester plusieurs approches et prendre la meilleure aujourd'hui tu peux mettre en prod 100 données au préalable grâce à la GNI des features où t'as de l'IA, mais si tu veux l'améliorer il faut il faut il faut avoir quelqu'un qui va te mettre en place ces process là donc en fait, on lance des features où un software engineer classique appelle des API d'IA et on arrive à aller à proposer quelque chose et ensuite on essaye de l'améliorer ok.
Bruno:
Tu disais tout à l'heure qu'une des différences dans une boîte qui est AI-Fer, c'est notamment les ML engineers qui ne sont pas un métier en voie de disparition. Tu as glissé tout à l'heure que tu avais commencé à faire des choses avant d'avoir un ML engineer. Qu'est-ce que ça a changé dans la manière de travailler et dans le gain technologique ? Est-ce que tu as senti que quand ton ou ta ML engineer est arrivée, est-ce que tu as senti un step-up dans la manière de faire les choses ?
Louis:
Ouais carrément, je pense déjà, en l'occurrence c'est Soufiane, donc c'est un il, mais il a apporté une vraie sensibilité de data à la boîte, que moi j'avais pas spécialement, donc en fait ce truc de tout ce qu'on peut collecter, tout ce qu'on peut tracer, ça peut être intéressant pour plus tard pour améliorer un modèle, pour faire quelque chose, donc ça veut dire, nous ce qui va être hyper intéressant c'est de savoir combien on a de data to cartes, de premièrement on pourrait dire que ce qui est intéressant c'est juste est-ce que notre réponse est bonne mais en fait savoir si la personne a posteriori a fait un atout carte c'est hyper intéressant pour nous parce que c'est un signal faible ou plus ou moins faible d'ailleurs pas si faible que ça, que notre réponse est qualitative si ça a poussé à l'atout carte, donc c'est vraiment cette approche de ok plus j'ai de données plus je suis content du ML Engineer qu'on a pas forcément en réflexe en tant que software engineer, ça a vraiment été important et après sur la mise en place, d'outils de toute la rigueur que tu peux avoir sur les métriques justement ne pas regarder que ta précision brute mais le mettre en balance avec tes faux positifs tes faux négatifs et où est ton trade-off ça aussi il a porté beaucoup sur la partie je parlais un peu d'AB testing c'est aussi un truc où savoir interpréter un AB test à quel moment, creuser quand on a un résultat qu'il soit positif ou négatif sur est-ce qu'il n'y avait pas un biais induit par la donnée enfin voilà tous ces réflexes d'aller voir si ta donnée elle est biaisée elle n'est pas biaisée etc qu'on a moins en tant que software engineer je pense.
Bruno:
Je trouve ça effectivement intéressant de se dire que le fait d'ajouter un élément à son panier, comme tu le disais, soit un critère important qui permet de voir en fait l'impact que tu as sur l'utilisateur. Malgré tout, est-ce que c'est un indicateur pertinent sur la qualité de la réponse que tu fournis ? Parce qu'en fait, un des risques avec l'LLM, c'est que tu peux avoir un LLM qui hallucine, qui répond à côté. Donc en fait dans une certaine mesure on pourrait se dire que le fait que quelqu'un ajoute un produit à son panier ça veut pas dire que ta réponse elle était juste ça veut peut-être juste dire que ta réponse a donné envie de l'ajouter mais potentiellement le contenu était faux.
Louis:
C'est quoi un bon vendeur en magasin est-ce que c'est celui qui t'apporte la bonne réponse ou est-ce que du point de vue de ton boss c'est celui qui a réussi à vendre le truc après souvent, les bons vendeurs sont des gens qui sont de bons conseils qui t'écoutent qui te posent les bonnes questions etc au final tout est un peu lié mais c'est sûr que nous vu qu'on, on est pas en train de manager un humain mais plutôt d'essayer d'objectiver, d'entraîner une IA on peut être tenté, d'être vraiment du point de vue on va dire que le e-commerce nous embauche pour, convertir mieux et du coup d'optimiser plus la conversion que la qualité des réponses, et c'est clairement une question qui se pose, est-ce que notre objectif c'est d'optimiser le taux de conversion donc en fait on pourrait, juste faire des A-B tests en permanence de nos modèles et juste aller vers celui qui augmente le plus la conversion sans regarder vraiment la qualité, la vérité c'est qu'on a dans tous les cas on a un enjeu d'être crédible, t'as un besoin rien que pour vendre, pour faire un bon marketing d'apporter des réponses qualitatives donc ça reste un critère important mais c'est hyper important de regarder aussi la conversion, et d'essayer idéalement d'aller sur le meilleur des deux mondes C'est à dire quelque chose qui répond bien mais tout en Tout en augmentant le taux de conversion.
Bruno:
Je ne sais pas si c'est uniquement les derniers éléments qu'on a évoqués ou si c'était le cas sur tout l'épisode, mais là du coup, de ce que je note, c'est que tes tests les plus, en tout cas qui me semblent les plus pertinents aujourd'hui, c'est de la BTS, c'est les tests que tu fais en prod où tu vois comment est-ce que les utilisateurs se comportent face à une nouvelle fonctionnalité ou à nos produits ou un update que tu as poussé en prod. Est-ce que ça veut dire que tu es nécessairement dans une démarche où en fait tu lances alors je me doute que c'est pas complètement à l'aveugle mais un peu à l'aveugle en disant je pense que ça va mieux marcher et on voit ce que ça donne ou t'as quand même une capacité à faire des tests avant chez toi en pré-prod pour évaluer, tu me parlais tout à l'heure des scores de 85 passé de 85 à 87, c'est quoi ces scores comment tu détermines le score.
Louis:
Je pense qu'idéalement tu fais les deux en vrai, tu commences par trouver des bons candidats grâce à qualité de réponse que t'auras jugée, en labellisant tes bonnes réponses en disant ça c'est une bonne réponse, c'est une bonne réponse t'essaies d'augmenter ton taux de bonne réponse, t'essaies de trouver des nouveaux candidats et ensuite tu l'abétesses sur ton taux de conversion pour voir si effectivement ton candidat qui était bien sur ton dataset, il a aussi l'effet d'augmenter ton taux de conversion, le truc c'est que faire un abétesse ça veut dire exposer tes, enfin il y a toujours un risque tu exposes deux variantes, potentiellement une qui est moins bonne, donc en fait est-ce que c'est pas dommage et combien de temps tu fais pour être sûr qu'une variante est vraiment meilleure donc il faut de la volumétrie pour que ton ABTS soit significatif vite ce dont on n'a pas forcément le alors on a, quand même exposé à pas mal d'e-commerçants mais tu peux pas forcément te permettre de mettre tout le temps un ABTS live sur tous tes e-commerçants en même temps donc on peut pas non plus le faire de manière systématique et même en termes de volume on est pas encore, c'est un des fondateurs de Photoroom qui racontait que eux ils pouvaient eux ils ont le luxe donc Photoroom c'est une appli de retouche photo et ils sont utilisés par des millions d'utilisateurs c'est une app. IPhone, enfin mobile et eux voilà s'ils veulent tester un truc ils font une nouvelle version de l'app ils ABTest dans leur app en quelques heures je pense qu'ils ont un résultat de est-ce qu'ils ont amélioré le modèle ou pas, parce qu'ils ont un feedback de leurs clients quasiment centaines nous sur certains on fait des ABTest parfois par les commerçants parfois c'est une semaine ou deux donc tu peux avoir envie d'aller plus vite quoi.
Bruno:
Ouais mais donc comment est-ce que tu fais pour faire des tests tu vois tu parles tout à l'heure de tes scoring donc ça c'est des tests qui ont lieu avant une mise en prod.
Louis:
Ouais C'est des tests qu'on les fait pas en fait ces tests là tu veux les refaire tourner quand ta data change, donc si t'es une boîte très mature enfin très mature un peu mature sur la partie données t'as toute la donnée qui est générée en prod de tes inputs et outputs qui va quelque part et qui est réutilisée pour potentiellement recalculer tes scores, peut-être que j'en sais rien une énorme mise à jour CHGPT une adoption de la population si les gens qui utilisent ton app changent potentiellement tes scores vont changer je sais pas s'il y a des personnes un peu plus âgées qui viennent peut-être que tu as des queries différentes sur lesquelles t'es moins bon et donc du coup ton score va changer donc tu vas avoir envie de le refaire évaluer, donc c'est à ce moment là c'est quand ta donnée change que tu veux dans les faits, nos données changent quand ? elles changent quand on arrive à annoter plus de, plus de samples elles changent quand on a des nouveaux clients potentiellement donc c'est le moment où tu as envie de réévaluer ton modèle à.
Bruno:
Ce moment là donc ce que tu dis en fait c'est que t'as pas besoin de faire autant de tests sur ces systèmes là, qu'on ferait des tests unitaires à chaque à chaque pull request ou à chaque mise en prod en fonction des cas parce qu'en fait c'est tu testes uniquement quand t'as un changement de contexte on va dire, et donc comme ça arrive moins souvent tu peux te permettre de faire des tests qui sont plus intensifs, plus extensifs, parce que ça arrive rarement c'est ça un peu le...
Louis:
Non, en vrai après si tu touches le prompt de ton truc évidemment t'as envie d'avoir fait tourner le truc aujourd'hui c'est juste que c'est plus dur d'automatiser totalement je pense que, toute ta pipeline d'évaluation que d'automatiser des tests unitaires dans une CI donc on refait pas tourner et puis c'est potentiellement plus long, si t'as un LLM qui s'occupe de dire si oui ou non tes résultats sont tu dois annoter etc ça prend quelques secondes à chaque fois tes tests unitaires tu peux en faire tourner 1000 en quelques secondes donc c'est un trade off entre le temps que ça prend à mettre en place, le temps que ça prend à tourner, et la vitesse à laquelle tu veux aller.
Bruno:
Donc aujourd'hui c'est encore beaucoup des tests manuels ?
Louis:
C'est fait enfin c'est, Automatisé mais c'est nous qui décidons Quand est-ce qu'on les fait tourner, Mais après Dedans T'as des cas, Où tu sais que tu vas apporter Une émulation T'as un nouveau modèle qui est plus intelligent Moins cher Tu veux tester rapidement que c'est mieux Tu le fais une fois, Tu sais que c'est pas un échantillon de données Pour que ton choix soit mauvais Il faudrait qu'il y ait vraiment beaucoup de nouvelles données Beaucoup de nouvelles infos pour qu'il y ait une régulation.
Bruno:
On parle aussi beaucoup des sujets d'hallucinations, quand même l'impression qu'on en parle de moins en moins je sais pas si c'est un sujet qui est de mieux en mieux adressé par les fournisseurs des différents LLM mais comment tu fais toi pour tester et t'assurer que ton modèle est pas en train de partir en cacahuète.
Louis:
Alors déjà il me semble avoir vu passer un truc qui disait que GPT-5 était limite moins bon en hallucination que ses prédécesseurs donc c'est pas du tout un problème résolu et surtout, il en ressort souvent que c'est en fait un peu une feature des LLM c'est en fait quand ils sont entraînés. Dans le procès d'entraînement il y a des moments où on récompense le fait que le LLM invente quelque chose plutôt que répondre je ne sais pas, et il y a plein de cas où en fait à la base le grand use case des LLM fait moins un poème dans le style de Victor Hugo on est très content qu'il soit capable d'halluciner et d'inventer un poème qui ne soit pas du tout de Victor Hugo mais dans son style, donc c'est inhérent à la manière dont aujourd'hui ils sont entraînés et donc ils fonctionnent donc on va pas s'en débarrasser et nous on a quand même envie de les réduire au maximum et donc du coup bah là aussi c'est, sur tes métriques d'évaluation t'as à la fois est-ce que je fournis des bonnes réponses est-ce que parfois je réponds je sais pas est-ce que parfois je réponds une grosse bêtise. Et ça fait partie de notre trade-off quoi est-ce que je préfère avoir 85% de bonnes réponses, 10% de je sais pas et 5% de bêtises, ou est-ce que je préfère avoir 80% de bonnes réponses, 19% de je sais pas et seulement 1% de bêtises, et donc en gros c'est ça qu'on essaie d'équilibrer, de trouver le juste milieu de nous aujourd'hui. Là-dessus, ce que ça implique c'est d'avoir à la fois une évaluation d'un côté qui est est-ce que je réponds bon ? Et est-ce que j'ai eu en fait je sais pas ça a priori plutôt être un non c'est pas bon en revanche c'est pas une mauvaise réponse après combien de fois je réponds des bêtises et ça on l'évalue de la même manière avec un peu d'annotation manuelle quand on peut et après on essaie de généraliser avec, ce qu'on appelle des LLM as a judge qui vont essayer d'aller détecter quand est-ce que des hallucinations et on essaie de trouver le bon trade-off pour nous qui marche bien.
Bruno:
Est-ce que ça veut dire qu'en prod à chaque fois que t'as une réponse qui est générée il y a ce LLM as a judge qui va intervenir avant de la diffuser ou au final c'est fait de manière.
Louis:
Alors bah ça c'est pareil c'est encore une fois un trader si tu le fais avant de la générer bah potentiellement ton, ton hallucination enfin tu réduis ton taux d'hallucination effectif puisque tu vas potentiellement pas l'envoyer à l'utilisateur ou avoir le temps de la corriger etc, ou alors tu le fais en asynchrone ce qui te permet quand même d'avoir un début d'évaluation de pouvoir l'afficher, donc là nous dans les faits aujourd'hui on le fait plutôt en asynchrone parce qu'on trouve que notre taux de base est acceptable et du coup, on n'a pas envie de ralentir plus, on pense que ça ralentit plus la réponse systématiquement pour tout le monde c'est-à-dire que dans 95% des cas on répond vraiment la bonne chose ça serait dommage pour quelques cas où il peut y avoir une hallucination.
Bruno:
Tu nous disais tout à l'heure qu'il y a ce trade-off tu choisis en fait, ta répartition idéale entre les bonnes réponses, les je sais pas et les hallucinations, aujourd'hui ça chacun de vos clients est capable de définir de lui-même ce que lui veut sur sa plateforme ou c'est vous en tant que plateforme qui imposez une certaine, norme de qualité ?
Louis:
C'est plutôt nous en tant que plateforme qui essayons d'imposer notre qualité, déjà parce que, si on arrive à avoir un standard qui est au bon niveau c'est un peu plus simple pour nous de tout gérer c'est plus opérationnel gérer qu'une vraie volonté mais ça fait sens aussi d'être un gage de qualité et de ne pas avoir à demander aux clients, c'est standard.
Bruno:
J'avais une discussion, je ne sais plus si c'était sur un épisode ou juste une discussion ou une préparation d'épisode, mais j'ai eu une discussion pas très longtemps avec quelqu'un qui me faisait une analogie entre l'injection SQL et l'injection de prompt. En m'expliquant notamment qu'aujourd'hui les injections SQL on arrive à peu près à régler le sujet parce qu'en fait on passe beaucoup par des ERM qui du coup nous séparent la notion de commande de la notion de données, là aujourd'hui en fait les prompt, t'as une espèce de mélange global qui est fait entre la commande et la donnée et la capacité de décision, d'exécution de cette commande aussi est ajoutée dans le lot, est-ce que vous aujourd'hui vous avez des moyens d'éviter de l'injection de prompt ou est-ce que vous considérez que de par votre activité l'injection de prompt a peu de risque.
Louis:
Alors on a des gens qui essayent parfois, c'est marrant parce que nous on les voit dans les logs, des gens qui sont là quel modèle utilises-tu ? Qui essaient un peu de savoir qui oublient toutes les instructions mais souvent c'est à un niveau qui est trop basique pour que ça marche. Moi je sais que même dans les même sur la partie sql ou sécurité classique il y a toujours des toujours des files le but c'est juste de mettre le plus de couches d'obscuration pour que les gens, n'y aillent pas mais un des outils enfin le premier truc que de mettre à disposition les modèles de langage c'est qu'ils ont ce qu'ils appellent le système prompt qui quand tu appelles l'api d'un tropique tu as par exemple tu as, un message qui a un rôle particulier qui est le système prompt qui du coup est interprété différemment parce que le modèle a été entraîné comme ça et qui du coup il prend plus en considération les consignes qui sont dans le système prompt que celles qui sont dans le human message ou l'AI message donc ça c'est une couche de sécurité que t'apportes les gros modèles bon les gros modèles font énormément sur la sécurité parce qu'ils sont bien plus exposés que nous donc on se repose quand même aussi pas mal sur ça et après nous des sujets comme le fait de faire du routing et de détecter c'est de détecter les requêtes hors sujet ça fait aussi partie du truc, en fait si quelqu'un ignore toutes les instructions et, réponds-moi à ça, bah du coup nous on sait qu'a priori on est capable de le détecter comme étant hors sujet et donc d'affecter un prompt particulier à ce genre de cas qui va être hyper restrictif et qui fait que t'as zéro chance de pouvoir bypasser la sécurité.
Bruno:
Est-ce qu'il y a une... Alors c'est peut-être pour essayer de conclure, mais, on voit des gens qui mettent en avant le fait qu'ils ont des êtres humains qui répondent à leur chat et non pas des IA. Est-ce que justement sur ces questions à air-sujet, il y a parfois une volonté de mettre un peu d'humanité dans les questions à air-sujet, de dire... Tu vois par exemple il y a aussi le fameux test de demander à des chatbots c'est quoi la recette de la tarte aux pommes, Olivier c'est quoi c'est de se dire toutes les requêtes qui sont hors sujet on les traite pas ou est-ce qu'il y a des clients qui vont dire bah nous on veut bien qu'on les traite mais avec un certain tu vois en respectant une image de marque un truc tu vois de manière à ce que ça reste d'ajouter un peu d'humanité au final dans cette IA.
Louis:
Ça clairement il y a des ça peut dépendre des clients, t'as des clients qui sont plus, qui sont plus stricts et qui ont plus ou vraiment la priorité c'est de pas répondre à côté donc du coup on va mettre en place des règles plus strictes pour vraiment pas répondre t'en as qui sont plus ok bon c'est l'IA c'est cool c'est bien si on peut répondre hors sujet tant qu'on dit pas des, énormes bêtises et du coup là t'es un peu plus là que c'est plus cool ça dépend vraiment des cas, mais oui parfois c'est aussi enfin c'est aussi il y a des cas où t'as envie de, t'as des cas où t'as envie que ton IA elle soit vraiment hyper restreinte au contexte que tu lui donnes et que t'as décidé de lui donner et tu as des cas où on a des clients selon ce que tu vends en fait tu peux aussi avoir envie qu'elle soit capable d'aller chercher sa connaissance, où là du coup c'est forcément plus risqué parce que tu t'exposes forcément plus sous la définition mais tu as envie qu'elle soit capable de te parler de choses qui sont pas explicitement dans le site, pour répondre au client et leur apporter de la valeur et là c'est un curseur qui est pas facile à fixer.
Bruno:
Je ne sais pas ce que tu fais, mais il y a fort longtemps, le fondateur de Zalando, il avait fait un bouquin justement sur la notion de service client, et il expliquait que quand tu es Zalando qui vend des chaussures, que quand tu appelaies le service client de Zalando, tu leur demandais de commander des pizzas, ils t'ont commandé des pizzas en fait. L'idée c'était de fournir un service au client quoi qu'il arrive.
Louis:
On va pas encore livrer les pizzas grâce à nos IA mais ouais il y a un peu de ça dans l'idée de t'as vraiment des clients qui ont pas envie qu'on réponde je sais pas ou je suis pas je peux pas t'aider sur ça et t'as envie de si la personne vient de poser une question bah exactement sur où est-ce que je peux aller au cinéma voir tel film, bah prononcièrement t'as peut-être envie de lui répondre pour être le meilleur service client, mais disons que c'est pas notre priorité non plus de réussir à répondre à ces requêtes là.
Bruno:
Pour terminer un peu sur ces sujets là on parlait au début de donc toi tu as bossé pendant longtemps chez Theodo qui est une ESN où tu travailles de manière un peu classique sur du software engineering, on pourrait presque dire à l'ancienne aujourd'hui, aujourd'hui tu es sur une activité très orientée AI first comme tu disais, est-ce que tu penses que ce changement de paradigme que tu connais aujourd'hui que tu pratiques aujourd'hui, est-ce que pour toi c'est un, changement de paradigme sur lequel on va tous devoir passer un moment, est-ce que pour toi le LLM ou l'IA en général c'est devenu un élément indispensable pour quasiment toute fonctionnalité et que cette manière de travailler, cette nouvelle manière de produire du logiciel, c'est pas juste un métier à part c'est la future norme de notre métier à tous.
Louis:
Alors il y a deux aspects, il y a l'aspect un peu produit, quand tu construis ton produit, est-ce que tu mets l'IA à un moment dans ton produit je pense que les produits qui en mettront seront meilleurs, donc gagneront à terme même sur des, sur des sujets un peu qui sont pas qui s'y prêtent pas, enfin qui n'ont pas l'air de s'y prêter je pense qu'ils gagneront, après la question c'est combien de temps ça va prendre, enfin avant que, je sais pas quel marché un peu obscur qui est peu digitalisé se mettre à la full IA genre ça va peut-être prendre 10 ans avant que les ERP spécialisés dans la plomberie soient AI first la gestion.
Bruno:
Des transactions bancaires ça va peut-être pas passer par des LLM.
Louis:
Tout de suite ça va prendre un peu de temps mais je pense que tous les secteurs vont, que les gens qui s'y mettront vont gagner selon les secteurs ça prendra plus ou moins de temps et après en tant que dev comment ça va, je pense que, ça change déjà notre manière de travailler, enfin d'ailleurs on le voit c'est là où l'IA a le plus pénétré, c'est sur l'utilisation par les développeurs, et je pense que il faut essayer on peut pas être réfractaire au changement là-dessus je pense que ce serait la pire erreur en tant que développeur, il faut regarder ce qui se fait il y a beaucoup de, chiffres marketing, 95% du code est généré par IA, bon c'est pas trop si vrai mais ce qui est sûr c'est qu'il y a des boîtes qui en génèrent énormément et qui vont vite et qui sont capables de le faire je pense qu'il faut s'y intéresser, parfois ça marche pas parfois on est déçu, quand on est déçu, moi ma conviction aujourd'hui c'est que quand on est déçu par ce que l'IA a rendu c'est sans doute que on a pas la doc au bon endroit on l'a pas prompté de la bonne manière on a pas été capable de donner du contexte, donc c'est sans doute qu'il faut faire évoluer nos process, mais le rejeter parce qu'on a pas réussi à le tester sur une fois je pense que c'est une énorme erreur et je pense que c'est la responsabilité des CTO de tirer cette transformation top.
Bruno:
Merci beaucoup Louis pour cette discussion j'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast, la première c'est est-ce qu'il y a un contenu que tu souhaiterais partager à l'ensemble des auditeuristes.
Louis:
Alors moi j'ai un contenu qui m'a, dans cette veine de comment on transforme notre métier de dev avec l'IA, qui a été écrit par Thomas Voltaire, qui est CTO chez Theodo actuellement, qui est un ancien collègue, du coup qui a écrit un super article de blog récemment qui a été partagé par Theodo, donc je pourrais te retrouver le lien, sur comment, je crois que le titre de l'article c'est comment j'ai codé 3 mois de feature en 2 semaines, ce genre là, et très détaillé, avec les prontes qu'il utilisait dans Cloudcom, comment il a découpé son travail il y a un vrai process tu sens le process d'itération derrière comment ils sont arrivés à ça et comment maintenant ça va être intégré dans le process de dev je l'ai vraiment beaucoup aimé je le mets en avant, il était vraiment top.
Bruno:
Oui j'ai eu l'occasion de parler avec Thomas il n'y a pas très longtemps effectivement il y a des trucs qui sont faits avec la Genet chez Théodro qui sont hyper intéressants donc merci beaucoup pour cette recos, j'aurais une dernière question qui est la question la plus importante de ce podcast Louis est-ce que tu es plutôt espace ou tabulation plutôt espace très bien merci beaucoup Louis merci Bruno et merci à tous d'avoir suivi cet épisode voilà j'espère que ça vous a peut-être même donné envie de devenir une, entreprise AI first ou pas du tout mais je pense que comme le disait Louis il y a quand même une tendance de fond qui est en train d'arriver. Je pense qu'effectivement la génération de code c'est un truc par lequel on va tous devoir s'y mettre donc n'hésitez pas à aller tester il y a plein d'outils qui existent, Il ne faut pas attendre d'avoir le meilleur outil parce qu'en fait, ils sont tous à peu près équivalents. Il y a peut-être certains qui ont une courte tête, mais en fait, le delta entre ne pas en avoir et en avoir un est beaucoup plus important qu'entre en avoir un et avoir le meilleur. Donc, mettez-y vous. Mettez-vous... Enfin, bref. Mettez-vous à l'IA. Je vous remercie aussi, comme toujours, de partager ce podcast autour de vous. N'hésitez pas à aller checker le Tipeee si vous voulez contribuer à ce podcast et l'aider à se développer. Et puis aussi à checker les différents réseaux sociaux, notamment sur TikTok où il va se passer pas mal de choses. Je vous remercie beaucoup, je vous souhaite une très bonne fin de semaine, je vous dis à la semaine prochaine et d'ici là, codez bien !
