Marc 00:00:00 – 00:00:09 : Aujourd’hui, je reçois Jean-Marie John-Matthew, cofondateur et CPO de Giscard. Giscard est le leader open source du test pour les intelligences artificielles. Bonjour Jean-Marie. 

Jean-Marie 00:00:09 – 00:00:10 : Salut Marc. 

Marc 00:00:10 – 00:00:14 : Alors Jean-Marie, est-ce que tu peux nous parler un petit peu plus de Giscard? ? 

Jean-Marie 00:00:14 – 00:00:57 : Oui, donc Giscard, c’est une solution française qui a été fondée en 2021 avec mes deux autres cofondateurs, Alex et André. L’idée de Giscard, c’est de traiter un problème qui est assez fondamental aujourd’hui avec l’appropriation de l’IA, qui est la qualité des modèles d’intelligence artificielle. Et on le fait de différentes manières avec un gros parti pris vers l’open source, où aujourd’hui on est leader dans la partie open source sur la manière de faire des tests des modèles d’IA et aussi avec un gros travail sur les parties, plus standardisation, il y a de confiance pour facilement réussir à certifier des modèles d’IA. Donc c’est jusqu’à, on est une boîte, on est une trentaine aujourd’hui et on est basé à Paris. 

Marc 00:00:57 – 00:01:00 : Quel était le constat sur le besoin au départ ? 

Jean-Marie 00:01:00 – 00:02:13 : Le constat, c’est parti d’un problème qu’on a vu dès 2021. Alors moi, plutôt du côté de la recherche, parce que moi, je travaillais, j’avais fait ma thèse plus sur comment on fait pour débiaiser des modèles d’IA, mais aussi comment on fait pour les expliquer. Je voyais qu’il y avait de plus en plus d’outils techniques, notamment dans la recherche, pour pouvoir mesurer les biais et ainsi de suite. Et en même temps, je voyais aussi qu’il y avait plein d’initiatives plutôt de type gouvernance pour créer soit des chartes éthiques ou des standards. On était au début des standards en 2021. Donc déjà, je voyais qu’il y avait ce besoin-là. Et de l’autre côté, il y avait Alex, mon associé, lui qui avait travaillé en tant que software engineer chez Dataiku et qui a vu qu’en fait, il y avait une maturité beaucoup plus forte dans le software engineering de manière générale, notamment en termes de qualité. Par exemple, dans la CIA, où on automatise les tests, plein de métriques de tests, les tests unitaires, les tests d’intégration. Et on s’est dit, il y a quelque chose à faire pour transposer l’ensemble de ces techniques-là dans le monde de l’intelligence artificielle. Et c’est un peu comme ça qu’est né le constat de départ, un problème particulier. Après, là, aujourd’hui, certaines choses qu’on avait vues en 2021 sont devenues des évidences aujourd’hui, en 2024, notamment avec l’arrivée de l’IA générative. Mais à la base, c’était quand même un marché très immature qu’on adressait. 

Marc 00:02:14 – 00:02:26 : Oui, si on essaye d’énumérer un peu les différentes évaluations qu’on a envie de faire avec des modèles de Marchine learning, on a quoi ? Si on se compare justement à ce que tu parlais des tests automatisés et de software. 

Jean-Marie 00:02:27 – 00:04:04 : Alors ça va dépendre des types de modèles d’IA, donc par exemple si on allait directement sur l’IA générative, en général beaucoup de gens aujourd’hui développent des chatbots, des RAGs en utilisant des modèles fondationnels. Là, par exemple, on peut prendre des taxonomies déjà existantes de vulnérabilité des modèles d’IA, de type IAGN. Évidemment, tout ce qui est hallucinations, omissions, toute la partie prompt injection aussi, vis-à-vis de plein d’attaques différentes. On peut imaginer, par exemple, des attaquants qui vont injecter des bouts, des paragraphes dans l’IA et qui vont faire complètement vriller le modèle. On a évidemment tout ce qui est stéréotypes, discrimination. On a beaucoup, beaucoup de sujets autour du data leakage. Qu’est-ce que ça veut dire le data leakage ? Je ne sais pas, vous avez mis en place un chatbot interne dans la boîte. Et là, il y a quelqu’un qui s’amuse à poser des questions très confidentielles dans la boîte. Par exemple, c’est quoi le salaire du CEO ou ainsi de suite. Donc, la révélation d’informations sensibles. On a beaucoup de contenus malveillants aussi, des contenus toxiques, contenus adultes, ainsi de suite. Donc voilà, il y a un ensemble de vulnérabilités qu’il faut traiter. Et après, si c’est plus sur des IA plus « traditionnels », comme la classif, la régression, c’est un peu low-level, mais il y a évidemment des biais de performance. Par exemple, sur des sous-populations, des datas où on a des performances très faibles, on peut avoir des enjeux autour des corrélations fallacieuses, des sous-populations avec une forte confiance. Alors qu’en réalité, c’est incorrect. Ou au contraire, des choses très borderline. Il y a beaucoup de choses à détecter. L’incertitude, ce genre de choses. Il y a un ensemble de problèmes, de tests à faire. 

Marc 00:04:04 – 00:05:28 : D’accord. Tu as bien divisé l’IA générative et l’IA classique, si on l’appelle comme ça. Du côté IA générative, tu nous as parlé. Hallucination, c’est quand le modèle invente. Omission, il n’a pas répondu alors qu’il aurait pu avec ce qu’on lui a fourni. Tu nous as parlé de… D’injection de prompte, c’est quand on vient changer les consignes du modèle dans le corps de la question qu’on lui pose. Contrôler un peu côté censure d’une certaine façon au sens large. Tu parlais de contenu adulte, de discrimination. Tout ça, c’est côté IA génératif et côté génératif de texte. On est sur du texte exclusivement ? Et côté modèle de Marchine learning classique, donc celui qui va prédire des ventes, qui va catégoriser des transactions, ce genre de choses. Là, ici, il s’agit, si on reprend les différents problèmes, il y avait La sous-performance sur une petite population, arriver à isoler des circonstances dans lesquelles ça ne marche pas bien, ça permet ensuite de se poser la question pourquoi. Donc ça, c’est quelque chose qui se fait automatiquement. Vous, vous allez faire une batterie de test qui va dire, dans tel genre de sous-catégorie, on a une performance qui est très mauvaise et ça peut lever une alerte, par exemple. 

Jean-Marie 00:05:28 – 00:06:52 : Exactement. Prenons un exemple par exemple sur du crédit scoring. Si le but c’est de scorer l’appétence d’un demandeur de crédit sur sa capacité à rembourser son crédit, on peut par exemple trouver automatiquement que sur une sous-population particulière, par exemple des gens qui habitent à tel ou tel endroit, on a une performance extrêmement faible. Donc ça, c’est quelque chose qu’on peut trouver. Et comment on fait, nous, pour trouver ce genre de choses ? On met en place d’autres modèles, d’autres modèles d’IA basés à base d’arbres, où là, l’idée, c’est vraiment d’identifier ces segments qu’on identifie automatiquement. Le but, c’est vraiment… Nous, ça, c’est quelque chose qui est très important pour nous. Quand les gens vont commencer à tester l’IA, on a remarqué que quand les data scientists, on leur demande, vas-y, teste, ils vont se dire, en fait, OK, mais quoi ? En fait, qu’est-ce que tu veux que je teste ? Parce que les tests sont infinis. parce que ça dépendait de la donnée et donc forcément il y a une configuration infini test et ce n’est pas aussi facile que d’avoir des scénarios dans le logiciel traditionnel où c’est beaucoup plus déterministe. Il y a tel ou tel cas qui sont des cas nominaux. Donc là dessus ce qui est vachement important c’est de commencer par une procédure extrêmement automatique où vous avez un point de départ, où vous avez des scénarios, des problèmes qui sont déjà, on va dire, un premier point de départ qui va vous permettre d’ensuite d’enrichir et d’ajouter des tests qui sont plus spécifiques au domaine. Donc, c’est un peu ça le parti Pritjiska, c’est vraiment de commencer par une phase automatique. 

Marc 00:06:52 – 00:06:59 : Est-ce qu’on peut développer un peu le data leakage ? Parce que tu nous en as cité quelques fois. Qu’est-ce que c’est ce problème-là qu’on veut détecter ? 

Jean-Marie 00:06:59 – 00:08:40 : Alors, quand on fait une IA générative, par exemple un RAG, un RAG, Retrieval Automated Generation, qu’est-ce que c’est exactement ? Vous avez une première partie qui va réussir, qu’on appelle le retrieval, qui va prendre une knowledge base particulière, qui va essayer de récupérer les parties de cette knowledge base qui sont très proches d’une question qu’on va poser au chatbot, Et à partir de ces bouts de contenu, essayer de demander à une IA générative par-dessus de générer une réponse. Donc c’est comme ça que ça fonctionne. Et le gros problème de ces règles-là, c’est que justement, ils sont en contact du knowledge base qui peut être extrêmement varié et qui peut potentiellement contenir des informations différentes. qui sont confidentielles. Et du coup, si on pose des questions un petit peu fourbes, on va dire, où on va essayer de trouver des espèces de edge case, on peut réussir à trouver de l’information qui n’était pas censée être disponible. C’est quelque chose d’assez facilement faisable. D’ailleurs, par exemple, il y a aujourd’hui plein de boîtes de la cybersécurité qui vont essayer d’auditer Copilot de Microsoft sur Teams ou autre, PowerPoint, pour essayer de voir s’il y a du data leakage, notamment par exemple sur des questions RH, des ressources humaines. Je parlais par exemple du salaire du CEO, c’est un cas d’usage extrêmement connu, mais ça peut être aussi sur les arrêts maladie ou plein de choses de ce type-là. Donc on va avoir une liste de questions un petit peu sensibles qui pourraient récupérer l’information sensible et on va vérifier qu’effectivement ce n’est pas le cas. Et donc souvent, c’est très lié aussi aux informations personnelles. Par exemple, sur certains rags, on ne veut pas que des prénoms et des noms sortent, des dates de naissance, ce genre de choses. C’est une chose qu’on voit très souvent dans le monde de l’entreprise. 

Marc 00:08:40 – 00:09:04 : Donc là, ça serait une couche qui est en prod, sur l’opérationnel, même pas en mode… Il y a un volet contrôle de qualité offline dans votre produit. Vous vous demandez à date quelle est la qualité. Mais là, ici, c’est pendant l’usage, une sorte de couche qui vient filtrer ce qui a été produit pour dire attention, là, il y a un nom, attention, là, il y a un prénom. 

Jean-Marie 00:09:04 – 00:09:45 : Oui. Le filtre, ça vient un petit peu après, on va dire, mais d’abord, il y a le diagnostic, tout simplement. Ce que nous, on appelle un scan, qui permet déjà, avant de mettre en prod, de voir déjà s’il y a des soucis. Après, effectivement, si à travers ces outils-là, on voit qu’il y a des cas limites ou des choses qui se marchent mal, on peut créer des évaluateurs qu’on peut ensuite mettre sous la forme de filtres, ce qu’on appelle des gardes, qui permettent justement de vérifier De un, que les outputs sont conformes vis-à-vis de la politique de la boîte, mais aussi que les inputs sont conformes, notamment si on a des attaques, filtrer directement des inputs qui sont de type attaque et de le renvoyer dans la bonne branche. C’est important aussi. 

Marc 00:09:46 – 00:09:49 : Alors comment a démarré l’aventure ? 

Jean-Marie 00:09:49 – 00:10:44 : L’aventure a démarré vraiment à la base d’une discussion qu’on a eue avec Alex. On voyait qu’il y avait un problème, clairement, c’est ce que je disais, le fait que les pratiques de test des ingénieurs en Marchine learning étaient assez rudimentaires, de un, et de deux, qu’il y avait déjà beaucoup d’outils qui existent. On avait vu aussi la particularité du marché de l’IA, qui est un marché qui, en tout cas en 2021, était très immature, qui l’est encore aujourd’hui. Dans le sens où les gens investissent beaucoup pour des pocs ou de l’innovation et pas forcément toujours pour la robustesse en prod. Donc, on était sur un marché immature. Et donc, voilà, on s’est dit on a le problème. Maintenant, il va falloir trouver des solutions. Mais on a… Avant d’avoir une solution en tête, on s’est vraiment focalisé sur le problème. Et d’ailleurs, c’est pour ça qu’aujourd’hui, on se rend compte que sur ce même volet de problème, on a différents personas qui sont très différents. Et du coup, ça ouvre à des solutions qui sont très différentes aussi. Donc voilà, c’est un peu comme ça qu’on l’a pris. 

Marc 00:10:45 – 00:10:53 : Alors, est-ce que tu as des exemples de grands verrous ou obstacles que vous avez dû surmonter pour mettre en place ce produit ? 

Jean-Marie 00:10:53 – 00:11:52 : Je pense qu’on est sur un marché qui est ultra incertain, pas stable du tout. D’une part parce que, étant donné l’immaturité en termes d’appropriation d’IA, nous, on est sur le volet robustesse. Et effectivement, il y a comment convaincre des personnes d’investir sur ce sujet-là, sachant qu’ils sont au tout début de l’IA, donc c’est un vrai sujet ? Ensuite, il y a un autre sujet qui est plus le fait que la techno évolue énormément. Par exemple, l’IA générative, le boom est arrivé il n’y a pas très longtemps et ça change beaucoup dans les méthodes de test, dans les méthodes de debugging, dans les méthodes de scan aussi, de diagnostic. Ça changeait beaucoup de choses. donc il faut adapter. et aussi le fait que chaque fois qu’on a un nouveau modèle fondationnel il y a pas mal de choses notamment en termes d’injection de prompt qui sont corrigées ça demande aussi toujours d’être très update et de mettre en place des solutions pour y arriver. donc je pense que l’incertitude du marché l’instabilité du marché c’est le volet le plus difficile de loin de ce qu’on fait. 

Marc 00:11:53 – 00:12:03 : Si on prend les avancées technologiques qu’il y a eu depuis le début de Giscard, ça vous a impacté comment ? Je parle bien évidemment de ChatGPT, LLM et toute cette classe. 

Jean-Marie 00:12:04 – 00:12:58 : Oui. Alors, bizarrement, l’IA générative, notamment chez GPT, ça a plutôt renforcé des intuitions qu’on avait eues et qu’on avait du mal à pousser avant l’IA générative. Je prends des exemples. Typiquement, nous, on poussait beaucoup les data scientists à loguer des cas limites, donc des exemples particuliers où les prédictions sont mauvaises. Avant, la pratique était moins courante, alors qu’aujourd’hui, c’est devenu le B.A.B.A Quand on teste l’IA générative, c’est de faire des tests un peu unitaires sur des cas très limites. Alors qu’avant, les gens nous rétorquaient souvent que ce qui était important pour eux, c’est d’avoir une base de tests relativement représentative de leurs données en prod. Aujourd’hui, c’est moins le cas. Les gens comprennent qu’il faut taper sur les cas limites, les plus gros edge cases, en fait. Par exemple, ça, c’est quelque chose qui nous a vachement facilité. Un autre point qui nous a vachement… 

Marc 00:12:58 – 00:12:59 : Ça a évangélisé pour vous. 

Jean-Marie 00:12:59 – 00:13:50 : Ça a évangélisé pour nous, oui. Par exemple, nous, on poussait énormément sur le fait que la responsabilité autour de la qualité de l’IA, ce n’est pas quelque chose qui doit être porté uniquement par les techs, notamment les data scientists ou les ML engineers, mais aussi énormément par les product managers ou les personnes métiers qui n’ont rien à voir avec la technique. Alors c’était quelque chose d’assez difficile au début dans l’IA traditionnelle, alors qu’aujourd’hui avec l’IA générative, c’est tellement facile pour une personne non technique de pousser une query particulière où il y a un bug, parce que c’est du langage naturel, qu’aujourd’hui la collaboration est devenue beaucoup plus facile. Donc en fait, des choses qu’on avait développées dans notre outil à la base, aujourd’hui, ça nous a accéléré énormément dans le monde de l’IA générative. Donc, bizarrement, ça n’a pas été des obstacles, l’IA générative. Au contraire, ça nous a évangélisé le marché. Donc, c’était très bien à ce niveau-là. 

Marc 00:13:50 – 00:13:55 : Et alors, quels ont été plutôt les freins à l’adoption ? 

Jean-Marie 00:13:55 – 00:17:53 : Les freins à l’adoption, c’est encore une fois, c’est ce que je dis, c’est sur la partie. Les gens investissent beaucoup de l’argent dans l’innovation et souvent, ce que les gens ont en tête, c’est que c’est d’abord l’innovation. Je teste un truc et une fois que ça marche relativement, après, je vais m’inquiéter de la question de la. de la prod et d’ailleurs on sait que dans certains domaines particuliers de l’IA comme en computer vision ça peut devenir des gouffres financiers. donc une fois qu’on a un POC la maintenance des IA c’est un gouffre financier parce que tout coûte cher il faut tout relabeler donc il faut recréer sa bonne donnée pour essayer d’évaluer et donc ça devient très difficile et donc il faut prendre en compte ces aspects là dès le début. Et même chose, encore une fois, cet obstacle-là, avec l’IA générative, a été facilité. Pourquoi ? En fait, ça a été résolu de manière générale. Pourquoi ? Parce que quand on fait des RAGs, en règle générale, on a souvent beaucoup de prompts, enfin beaucoup de sous-procédures qui sont imbriquées les uns dans les autres. Et souvent, on a beaucoup de problèmes où… J’ai besoin, par exemple, de changer un de mes prompts et je ne sais pas à quel point ça a cassé l’ensemble de mon modèle. C’est quelque chose qui arrive assez souvent parce que les gens changent souvent les hyperparamètres de leurs rags. Qu’est-ce que c’est les hyperparamètres ? Par exemple, quand on fait des rags, on peut vouloir découper différemment sa knowledge base, on peut vouloir projeter différemment les contenus dans des espaces variés. Et ces choses-là, c’est de la configuration. En gros, c’est de la bidouille. Et cette bidouille, elle se fait souvent par essai-erreur. En fait, il n’y a pas de règle. Ça se fait, j’essaye, je vois que ça marche. Si ça marche, je continue. Sinon, je fais autre chose. Et dans ce contexte-là, il est devenu une évidence que si je veux bidouiller et avancer, j’ai besoin d’avoir des métriques, des KPIs clairs d’évaluation pour ne pas avancer à l’aveugle. Et donc du coup, même chose, Ça joue en notre faveur, puisque aujourd’hui, les gens mettent en place plein de métriques. Et d’ailleurs, on sait aujourd’hui qu’il faut, pour mettre un RAG en production, c’est peut-être 200, 300 tests de métriques à mettre en place. Donc, c’est énorme. Et on est très, très loin de la philosophie dans l’IA traditionnelle où on se dit, il faut que mon AUC, mon accuracy, ma précision soient bonnes. On a deux, trois métriques, on s’arrête là. On est très, très loin de ça. Donc voilà. Et après, sur les obstacles, disons, qui ont été des vrais verrous technologiques, c’est de, un, justement, il y a plein de test cases. Donc, il y a plein de tests. Il peut y en avoir 300, 400. Et donc, du coup, c’est extrêmement fastidieux à les créer. On ne peut pas imaginer qu’un data scientist ait les 300 en tête. Du coup, ça suppose beaucoup d’automatisation pour réussir à avoir toutes ces idées en tête de cas limites. C’est un premier enjeu. Il y en a beaucoup des tests et des cas limites. Un deuxième enjeu, c’est que les cas limites sont extrêmement spécifiques au domaine, notamment à la knowledge base. Je prends des exemples, si tu es dans le retail et que tu mets en place un chatbot qui est censé répondre à des questions sur des produits particuliers, par exemple est-ce que la télévision LG avec le numéro de série et une télévision LCD par exemple, un truc extrêmement précis, sur ce type de questions? c’est super métier en fait. et donc du coup peut-être qu’il faut avoir des experts métiers qui ont les bonnes idées de task case à mettre en place. donc le data scientist est souvent démuni face à ce genre d’enjeu. donc ça c’est une deuxième chose. et puis peut-être un troisième obstacle qu’on a beaucoup vu toujours dans l’IA générative c’est la régulation. en fait tout simplement. en fait aujourd’hui on sait que Le marché va de plus en plus vers la standardisation avec des normes, ISO, des labels. Et en fait, ces labels, la norme ou l’AI Act, la régulation européenne, ce que ça demande, c’est de la doc. Concrètement, c’est de la doc. C’est de la transparence, de la doc, de la doc. La doc, c’est ultra fastidieux à écrire. Parce que la doc, ça va demander de justifier tous ces choix. Et comme je le disais, vu que c’est beaucoup de bidouilles, tu as beaucoup de choix très différents. Et donc, il va falloir écrire, écrire, écrire plein de documentations. Ça, c’est aussi un énorme obstacle. 

Marc 00:17:53 – 00:18:11 : Oui, c’est intéressant parce qu’en fait, ce que je comprends d’une certaine façon, c’est que tout ce travail qu’on fait sur la qualité des données, c’est aussi un premier pas vers l’écriture de la doc qui est très fastidieuse. Donc, quelque part, on peut faire d’une pierre deux coups en mettant en place une QA dès le début. 

Jean-Marie 00:18:11 – 00:18:42 : Oui, complètement. Et d’ailleurs, sur la question de la qualité de la donnée, souvent, on fait la distinction qui est juste, en fait, parce qu’aujourd’hui, les nouveaux standards, les labels portent vraiment sur le modèle. Mais c’est très lié aussi avec les qualités de la donnée, puisque c’est souvent des volets de ces standards-là. Donc oui, nous, on pense vraiment que la qualité, ça se fait dès le début, dès la phase de prototypage, parce que sinon, tu développes à l’aveugle. Et ça, aujourd’hui, ça devient presque une évidence, mais ça ne l’était pas au début. 

Marc 00:18:42 – 00:19:26 : C’est ce que tu dis, le Marchine learning old school se base sur d’énormes corpus de données. Donc on a tout de suite la possibilité de faire des essais-erreurs, réentraîner, etc. Là où sur ce qu’on fait aujourd’hui avec les larges language models, on a beaucoup moins besoin de données pour démarrer. Et donc du coup, on est beaucoup plus vite confronté parce qu’on a les mêmes optimisations à faire. Comme tu dis, on a plein de questions à se poser. comment est-ce que je découpe mon document, comment est-ce que j’encode le texte, etc. Et donc, en fait, finalement, on est démuni au moment où on veut faire l’optimisation. Et donc, ce que je comprends, c’est que le fait d’être démuni fait poser les bonnes questions aux gens. 

Jean-Marie 00:19:27 – 00:19:44 : Oui. En fait, ça fait créer les bonnes métriques. Ça fait aussi créer, justement, vu que si on n’a pas de données, puisque ça arrive souvent avec l’IA générative, puisqu’on n’a pas besoin d’en avoir, pas toujours, il faut les créer. Il faut créer les cas limites, il faut créer les cas nominaux aussi. Et donc, ça demande de mettre en place toute une stratégie dès le départ. 

Marc 00:19:45 – 00:20:00 : Si tu te projettes dans 10 ans, 20 ans, je ne sais pas, qu’est-ce que tu imagines complètement différent par rapport à quelque chose qui est aujourd’hui un gros effort d’évangélisation ? Qu’est-ce que tu penses être un acquis dans 10 ou 20 ans et qui est aujourd’hui ton quotidien ? 

Jean-Marie 00:20:00 – 00:22:14 : Même chose, ça devient une évidence aujourd’hui, mais c’est que dans toute industrie mature, aujourd’hui, si tu veux industrialiser quelque chose, ça passe par une forme de standardisation ou de la labellisation qui est valorisée. Quand tu veux essayer de vendre le truc que tu as construit, ça s’est valorisé. On dit, voilà, mon truc-là, c’est le label européen. Et donc, j’arrive à le valoriser. Et ça, c’est quelque chose qui arrive dans l’IA puisqu’on a aujourd’hui des normes ISO 40 2001, le label européen qui est en train d’être construit, qui est important, il y a les actes qui permettent aussi d’avoir un tampon européen. Et donc, on arrive vers ça. Et c’est super intéressant parce qu’aujourd’hui, les gens le font mal ou en tout cas, ils ne savent pas comment le faire parce que la régulation européenne n’existe pas encore. Et je pense que dans 10 ans ou dans 20 ans, ça va être une évidence que ces choses-là permettent de valoriser les outils. Et aussi, je pense qu’on va arriver à une normalisation de l’IA qui va beaucoup plus prendre appui sur des procédures de développement logiciel plus traditionnelles. Notamment, je pense aux procédures qualité où on verra moins l’IA comme quelque chose d’expérimental. Il y aura des process qui vont se mettre en place. Et donc, je pense que oui, le marché va vers là. Puis nous, on essaye d’accompagner le marché là-dessus. Donc nous, notre vision Giscard, c’est de se dire que très rapidement, si tu es un développeur d’IA, tu peux directement faire toute la partie pré-assessment vis-à-vis de n’importe quel label automatiquement parce que derrière, tu as tous les outils techniques qui permettent de le faire. Donc tu as d’une part toute la création des preuves. Donc les preuves, ça peut être des tests, ça peut être des rapports de scan, des rapports de red teaming, mais ça peut être aussi parce qu’on a des outils qui vont permettre, qui seront directement intégrés avec ta doc interne et avec tous ces outils de preuve qui arriveront à piocher la bonne preuve au bon endroit et te dire, écoute, là, vis-à-vis de l’ISO 4001, tu es plutôt à 60% et tu devrais être à 80%. Et de pouvoir gérer la gouvernance de l’IA dès la phase de prototypage, réussir à avoir ce genre de choses en tête. On sait qu’aujourd’hui, c’est extrêmement demandé dans les grands groupes d’avoir ce niveau de maturité-là. Et c’est vers là qu’on va aussi. 

Marc 00:22:14 – 00:22:40 : Si on se met un peu en situation, imaginons que demain, j’accompagne un client sur un chatbot ou un assistant interne personnalisé. Donc, on met en place un outil drague. Quel conseil est-ce que tu as à me donner sur ce que je dois mettre en place dès le début, à cette phase d’innovation? du coup, puisqu’on commence forcément par un POC ? Qu’est-ce que tu as comme conseil sur la qualité en général ? 

Jean-Marie 00:22:40 – 00:24:36 : Alors, si on est vraiment en phase amont, souvent, souvent dans un développement de RAG, on fait d’abord un petit prototype et après, on essaie de complexifier les choses. Donc, soit vraiment la partie amont dans la manière de traiter la knowledge base. Ça peut être aussi parce qu’on va faire ce qu’on appelle du ranking, donc souvent des étapes intermédiaires. qui permettront de mieux classer les documents pertinents. Mais ça peut être beaucoup plus en aval aussi avec la génération. Donc souvent, il y a des étapes où on complexifie les choses, notamment parce qu’on a vu que notre ag a des soucis. Donc la première étape, c’est de savoir quels sont ses soucis pour justement arriver à complexifier dans un bon sens. Pour arriver à savoir quels sont les soucis, on peut le faire de manière très manuelle, c’est très important de le faire, mais on peut le faire aussi de manière un peu automatique pour avoir une forme d’exhaustivité. On peut le faire de manière très top-down parce qu’on a des taxonomies de vulnérabilité qu’on connaît, qui commencent à s’imposer, et qui vont vous permettre d’aller directement à partir d’une catégorie de la taxonomie. Je prends l’exemple de l’injection de prompt, pour vérifier que votre rack que vous venez de développer est plutôt safe à ce niveau-là. Mais vous pouvez aussi le faire de manière très bottom-up. Donc le bottom-up, ça serait de prendre sa knowledge base, chunk par chunk, bout par bout, et essayer de voir si les informations ont bien été remontées. Donc je pense qu’il faut créer ces métriques-là avec un hybride de top-down et de bottom-up pour justement se générer une première batterie de tests qui va vous permettre ensuite, quand vous allez complexifier votre RAG, de dire « écoute, là, je viens de perdre beaucoup en hallucinations, mais par contre, j’ai quand même pas mal gagné en contenu, j’ai de moins en moins de contenu toxique ». et du coup de pouvoir engager une discussion avec les différentes parties prenantes, le PM et ainsi de suite, pour se dire est-ce que ce trade-off qu’on a tranché à ce niveau-là va dans le bon sens ou pas. Donc c’est ce genre de discussion qu’il faut arriver à engager dès le début du process. 

Marc 00:24:36 – 00:24:46 : Ok, je fais un pas en arrière, on parle de ton produit, quelles erreurs est-ce que tu peux nous partager pour nous faire gagner du temps ? 

Jean-Marie 00:24:46 – 00:24:53 : Alors plutôt dans la phase un peu entrepreneuriale de Nangiscar ou plutôt quand je développe un RAG, quelles sont les erreurs ? 

Marc 00:24:53 – 00:24:57 : Plutôt la phase entrepreneuriale, mais si tu réponds à l’autre question, on sera content aussi. 

Jean-Marie 00:24:58 – 00:26:24 : Sur la phase entreprendre où il y a beaucoup de choses qu’on a fait dans Giscard, étant donné qu’on est dans un marché très incertain, on a vraiment testé plein de choses. On a vu qu’il y a des choses qui marchent, qu’il y a des choses qui ne marchent pas. Un truc simple qui est assez facilement transposable à d’autres métiers, c’est nous, on est allé vers l’open source et l’open source, c’est un monde. C’est un truc. nous à la base quand on est allé vers l’open source on s’est dit on avait un repo GitHub qui était privé. et on a dit on le met en public et c’est bon on est open source c’est aussi simple que ça. et en fait non c’est mille fois plus compliqué c’est pas juste. ça c’est aussi penser son outil de sorte à ce qu’il soit adapté à l’open source. alors qu’est-ce que ça veut dire? ça veut dire par exemple un outil qui permet la contribution. Donc ça suppose une forme de documentation très précise. Ça suppose aussi de la communication, un marketing qui soit très orienté développeur. Mais ça suppose aussi de savoir découper ce qui est privé ou pas dans son outil. Par exemple, les développeurs aiment beaucoup le code, évidemment. Et du coup, par exemple, les parties code, les mettre plus en open source, les parties peut-être visuelles, ce genre de choses, l’éviter. Donc c’est vraiment un découpage un peu stratégique qu’il faut faire pour que les développeurs puissent le plus facilement s’approprier l’outil et contribuer dessus. C’est aussi un grand travail marketing où il faut aussi embaucher des personnes, des développeurs advocate pour animer une communauté via différents canaux. Donc, ce n’est pas juste prendre son repo et le passer du privé au public. 

Marc 00:26:24 – 00:26:38 : Ok, mais c’est très intéressant sur l’open source, la dynamique open source. Par exemple, sur votre repo aujourd’hui, quelle est la proportion qui est écrite par des gens qui ne sont pas des employés de Giscard ? 

Jean-Marie 00:26:38 – 00:27:36 : Justement, ça c’est aussi un très bon point. Nous, sur les contributions, il faut avoir une stratégie très claire de ce qu’on veut, les types de contributions qu’on aimerait avoir. Il faut être très clair là-dessus. Nous, au début, on ne l’était pas forcément très bien. Là, aujourd’hui, on sait que ce qu’on veut avoir comme contribution, c’est les tests. On sait qu’on a une couverture de tests, on a un catalogue de tests. Et souvent, les data scientists, les développeurs peuvent avoir d’autres idées de tests ou des variantes. Ça, on a envie qu’ils contribuent, par exemple. Donc là, on a eu des contributions à ce niveau-là. Mais par exemple, c’est ça qu’on veut avoir. On ne veut pas forcément avoir des contributions sur des features plus traditionnelles. Si, on est toujours content d’en avoir, mais c’est quand même un coût de faire la review de personnes qui ne sont pas dans la boîte, qui ont d’autres manières de faire. Donc c’est quand même un coût qu’il faut prendre en compte. Alors que sur des parties très isolées du repo, sur par exemple la partie test, sur la partie détecteur du scan, il faut coder aussi d’une certaine manière pour que ce soit très modulaire et facilement documentable. 

Marc 00:27:36 – 00:27:47 : C’est vous qui écrivez les tickets en disant si quelqu’un est preneur, voilà ce qu’on aimerait faire ? Ou est-ce que chacun peut arriver avec sa suggestion ? 

Jean-Marie 00:27:47 – 00:28:12 : C’est toujours un petit mélange des deux, mais souvent ce qu’on fait, c’est qu’on met des issues sur GitHub ou on le tag en first good issue. Ça, c’est des choses qui sont extrêmement prisées par notamment des étudiants qui veulent, c’est toujours valorisé dans un CV, de dire j’ai contribué dans tel ou tel repo open source, ils vont d’abord s’intéresser aux trucs les plus faciles à faire, et donc le taguer proprement permet à ces étudiants de pouvoir contribuer. 

Marc 00:28:13 – 00:28:21 : Et du coup à la fin, sur 100 lignes de code en 30, il y en a combien faites par la communauté ? 

Jean-Marie 00:28:21 – 00:28:47 : je ne saurais pas répondre de manière aussi précise. on a eu sur nos tests. après c’est un peu compliqué aussi à répondre à ces questions parce que nos tests il y en a qui ont été complètement développés par des gens de manière externe mais après il y en a beaucoup qui ont été juste. l’idée nous a été insufflée par des gens externes et on l’a fait nous même. la frontière est toujours assez floue à ce niveau là. après on a eu d’autres contributions plus traditionnelles. J’aurais du mal à répondre. 

Marc 00:28:47 – 00:28:57 : D’un point de vue business, parce que c’est vraiment toujours le pendant de l’open source qui fait peur, en tout cas, je ne sais pas s’il est compliqué, mais en tout cas, il fait peur. C’est quoi votre business model compatible avec l’open source ? 

Jean-Marie 00:28:57 – 00:29:55 : En fait, il n’y a pas mille manières de monétiser l’open source. En règle générale, il y en a trois. Soit on rajoute des features payantes non open source par-dessus l’open source, soit on fait du SaaS, donc on héberge nous-mêmes notre logiciel qui est open source, ou soit on fait du support, de l’accompagnement de support. Et en règle générale, les boîtes font un peu d’étroits. C’est ce qu’on fait, nous. On fait un peu d’étroits. Sur le support, on fait du red teaming, on fait de la certification. Quelquefois, on fait un espèce d’amendement SaaS sur notre outil. Et puis, on a effectivement des features payantes, notamment le hub Giscard qui permet d’avoir l’ensemble des tests qui ont été exécutés, les avoir au même endroit, de pouvoir collaborer aussi, ce qui est relativement traditionnel dans la manière de monétiser l’open source. c’est d’adapter son outil à des contraintes plus corporate, notamment sur du login, l’authentification, les contraintes de sécurité et la partie collaboration évidemment. 

Marc 00:29:55 – 00:29:57 : Qu’est-ce que tu préfères dans ce métier ? 

Jean-Marie 00:29:57 – 00:31:54 : Sur mon métier plus produit chercheur, je suis dans un marché qui est très intensif en recherche, on va dire, pour pouvoir innover. Donc souvent, ce qu’on apprend dans le milieu startup, c’est vraiment d’arriver avec des formes de MVP qui te permettent de générer un peu de validated learning et de pouvoir itérer au fur et à mesure pour avancer dans un marché incertain. Et nous, dans notre cas, non seulement nos utilisateurs. Enfin, évidemment, si tu les interviews utilisateurs, ils ne connaissent pas forcément leur propre peine parce qu’ils sont eux mêmes en train d’innover et ils ne le voient pas forcément. Donc déjà, il y a ce souci là. Et même si on met en place des expérimentations avec eux, des trucs un peu quick and dirty pour essayer de voir si ça marche. Même ça, ça, c’est limite parce que le marché bouge extrêmement vite. Et donc, du coup, tu es obligé d’avoir une grosse phase recherche où tu vas embaucher des chercheurs en Marchine learning, en LLM, qui vont essayer d’avoir une roadmap un chouïa plus long terme pour avoir toujours une longueur d’avance. Donc, tu avances les vulnérabilités, les détecteurs, les… les tests. et donc ça c’est une particularité de mon marché que moi j’aime beaucoup puisque dans les procédures d’innovation il faut jongler avec les parties très MVP expérimentation avec des vraies personnes qui payent et puis de l’autre côté la partie recherche et à essayer de voir toujours essayer de faire un hybride des deux pour que les idées viennent un peu des deux. donc ça c’est une partie que j’aime beaucoup. et après dans la partie entrepreneuriale je pense qu’on est dans un moment extrêmement particulier en tout cas moi sur mon marché il y a une crise des startups clairement en termes de financement mais nous on est pile poil là où les financements arrivent bien. donc c’est l’intelligence artificielle ce marché là et en plus nous vu qu’on est un outil qui permet aux gens qui créent du Marchine learning enfin de l’IA d’assurer la qualité. donc on a eu la chance d’être médiatisé de gagner pas mal de choses. donc on a cette chance d’être là au bon moment au bon endroit avec des bons partenariats qu’on fait avec plein de gens. donc ça c’est quand même une partie très intéressante en tant qu’entrepreneur d’être là au bon endroit au bon moment. donc ça c’est cool. 

Marc 00:31:55 – 00:31:57 : Est-ce que tu as une opinion à nous partager ? 

Jean-Marie 00:31:57 – 00:32:59 : Je ne sais pas si c’est vraiment une opinion, mais souvent, ce que nous, on dit, c’est que créer une IA, en tout cas aujourd’hui, c’est assez facile dans le sens où faire un premier prototype, ça peut se faire avant très vite. En quelques lignes de code, on a aujourd’hui des très belles librairies qui fournissent des modèles déjà préentraînés. On a besoin à peine de toucher, pour un chat GPT où on a à peine besoin de toucher, mais Il y en a d’autres, mais c’est assez facile d’avoir un premier prototype. L’enjeu, c’est la mise en production, la maintenance et faire en sorte que votre IA vraiment s’assurer que l’IA que vous venez de développer, elle répond bien à un enjeu business et qu’elle crée de la valeur de manière récurrente. Et ça, c’est l’enjeu qui est la définition même de la gouvernance de l’IA. C’est vraiment d’aligner les contraintes business et les contraintes techniques. Et c’est vraiment ça. l’enjeu en fait c’est de créer le bon process avec les bonnes personnes en partageant les bonnes responsabilités entre les différentes parties prenantes pour vraiment s’assurer que la valeur qui est créée par l’IA elle soit alignée avec le process. Donc pour moi c’est ça l’enjeu principal. 

Marc 00:32:59 – 00:33:02 : Alors le futur de Giscard qu’est-ce que c’est ? 

Jean-Marie 00:33:02 – 00:33:51 : Nous, on se voit comme un espèce de bureau véritable de l’IA, c’est l’ambition. Disons, le leitmotiv de Giscard, c’est de se dire, on est pour un développement raisonné de l’IA, c’est-à-dire un développement fait par des humains, pour des humains, en prenant en compte les différents enjeux qu’on peut avoir, sociétaux, aussi environnementaux. Donc ça c’est vraiment notre leitmotiv et à partir de là, si on veut la mettre en place cette vision-là, ce qui est important pour nous c’est de construire cette confiance avec plein de dispositifs qui peuvent être très techniques quelquefois, donc ça peut être des tests, des scans, du monitoring, ou quelquefois moins techniques, écrire la bonne documentation, impliquer les bonnes parties prenantes. trouver des bons process de gouvernance. C’est d’être un acteur majeur dans l’ensemble de ces dispositifs qui participent à la création de la confiance de l’IA. 

Marc 00:33:51 – 00:33:57 : Et dernière chose, qui est-ce que tu aimerais entendre dans un prochain épisode de Data Driven 101 ? 

Jean-Marie 00:33:57 – 00:34:07 : Si on reste sur notre marché qui est le marché de l’IA, peut-être quelqu’un de chez Mistral, puisqu’ils font énormément de bruit en ce moment. Ça peut être une bonne occasion de voir ce qu’ils font et comment ils le font. 

Marc 00:34:07 – 00:34:16 : On a déjà reçu Guillaume Lample dans un épisode précédent, mais on invitera sans doute d’autres gens. Je pense qu’il y a de la place pour plusieurs invités. Merci Jean-Marie. 

Jean-Marie 00:34:16 – 00:34:17 : Avec grand plaisir.