← BibliothèqueToutes les vidéos
Tech.Rocks Summit 2025
Agents IA, la nouvelle frontière des LLMs
- Guillaume Laforge (Developer Advocate, Google Cloud)
Tech.Rocks Summit 2025 · 1er décembre 2025 · 35 min · en français
Résumé
Au Tech.Rocks Summit 2025, Guillaume Laforge revient sur les agents IA, buzzword de l'année, et en détaille les ingrédients clés : les modèles qui raisonnent, les outils et protocoles utilisés (function calling et MCP), l'orchestration de plusieurs agents (ADK, A2A) et les patterns importants.
L’essentiel
Concevoir des agents IA avec des tâches délimitées, des outils pertinents et une évaluation sur des cas réels.
Pour cadrer un prototype d’agent et préparer les critères qui permettront de l’évaluer.
Les idées clés
- Décomposer le travail en tâches spécialisées et fournir à chacune le contexte utile. Guillaume Laforge décrit un rôle de chef d’orchestre qui répartit recherche, résumé et synthèse plutôt que d’accumuler les cas particuliers dans un très grand prompt. à 15:00
- Donner les bons outils au bon moment. Selon lui, limiter ou filtrer les outils disponibles réduit la confusion et aide à obtenir un comportement plus déterministe. à 17:10
- Évaluer avec des cas réels et les experts métier. Des tests intuitifs ne suffisent pas : il propose de collecter de vraies questions et réponses pour mesurer la qualité, notamment dans un système de recherche documentaire augmenté par l’IA. à 22:49
Questions pour votre équipe
- Quelle tâche et quel contexte confier à chaque agent ?
- Quels outils sont réellement nécessaires à cette étape ?
- Quelles questions réelles utiliser avec les experts métier pour évaluer les réponses ?
Les outils et protocoles évoluent rapidement. Les pratiques présentées constituent un point de départ ; elles ne garantissent ni fiabilité ni sécurité pour un cas d’usage donné.
Chapitres
Summary
At the Tech.Rocks Summit 2025, Guillaume Laforge looks at AI agents, the buzzword of the year, and breaks down their key ingredients: reasoning models, the tools and protocols involved (function calling and MCP), orchestrating multiple agents (ADK, A2A) and the main patterns.
Thèmes : IA
Transcript complet
Transcription automatique, à relire : les noms propres peuvent être mal orthographiés.
Je vais vous annoncer notre prochain talk, celui de Guillaume Laforge. Alors Guillaume, il est Developer Advocate de Google Cloud et il va nous emmener au niveau supérieur, là où les IA deviennent un peu les opérateurs de la matrice. Alors on va parler MCP, Function Calling, orchestration d'agents. Il y aura évidemment plein de recettes et des patterns. Je vous demande d'accueillir sous un tonnerre d'applaudissements Guillaume Laforge. Let's go. Il y a du slide, Guillaume ? Il y a du slide, petite zapette? On part pour 25 minutes? Ah non, c'était 25. 25, mais il y aura une session de questions-réponses juste après. Et elles sont toujours très très nombreuses, n'est-ce pas? Voilà. A tout à l'heure. Merci. Bonjour tout le monde, c'est bien, j'ai gagné déjà 30 secondes parce que vous savez qui je suis. Ça fait 9 ans que je travaille chez Google et que je m'intéresse, enfin pas 9 ans que je m'intéresse à la Generative AI, il fait seulement 2-3 ans.
Mais je suis ravi d'être ici pour la première fois, c'est pour ça que j'ai un petit pin's rose, mais je vais essayer de le garder, pour parler d'agent IA qui est mon sujet en tout cas du moment chez Google. Je pense que vous serez tous d'accord avec moi sur le fait que l'IA, la Generative AI, les LLM, etc., c'est une vague inarrêtable. Et un petit peu comme toutes ces évolutions, voire révolutions technologiques, est-ce que c'est comparable à l'arrivée de l'électricité dans la société? Peut-être pas. Mais en tout cas, d'autres évolutions ou révolutions comme Internet ou le mobile, oui, c'est certainement une vague au moins aussi importante que ces révolutions-là. Donc du coup, c'est important d'être prêt, de savoir comment au mieux en tirer parti et essayer de trouver les bons endroits où on peut appliquer l'IA dans nos applications, nos sites web, etc. Donc si on refait... un petit peu l'historique, vraiment dans les très grandes lignes de ces dernières évolutions.
En fait, en 2017, le monde de la recherche, etc. A évidemment noté ce papier de recherche de Google sur une nouvelle architecture de réseau de neurones qu'on appelle les transformers. Et qui est à la base de toute cette révolution qu'on a des LLM, des chatbots, des coding agents, etc. Et ce qui est intéressant avec ces... Donc on faisait déjà des réseaux de neurones auparavant, mais avec cette architecture de réseau particulière, on a été capable d'entraîner des modèles sur... Déjà beaucoup plus grand et sur de plus en plus de données. Et on s'est aperçu que plus on entraînait longtemps et sur plus de données, et idéalement la donnée de qualité, on allait avoir des fonctionnalités et des nouvelles capacités qui allaient émerger. Par exemple, la traduction, le codage, etc. Alors que les plus petits large language models, mais qui n'étaient pas forcément sous forme de transformers, n'étaient pas forcément capables de faire tout ça.
Donc, en 2017, Google pose les rails. Et ce qui a vraiment popularisé, je pense que ça aussi vous le reconnaîtrez avec moi, même si je suis chez Google, je vais parler de ChatGPT, c'est quand même l'arrivée de ChatGPT qui a popularisé ce concept, en tout cas de donner une interface sous forme de chatbot à des LLM avec les différents modèles. GPT. Après, si on accélère un petit peu plus, il y a eu aussi des mots-clés qui sont arrivés. Donc là, je mets 2024, mais il n'y a pas vraiment de date très spécifique. Retrieval Augmented Generation. Les LLM, ils étaient entraînés sur des données publiques. Donc on pouvait leur demander des choses, des connaissances sur ce qu'il pouvait y avoir sur Internet. Et encore, ce n'était pas les dernières nouveautés qu'on pouvait trouver sur Internet ou dans les livres, etc. Parce qu'il y a ce qu'on appelle une cut-off date, c'est-à-dire la date de fin d'enregistrement des données qu'on donne au modèle pour l'entraînement. Mais Retrieval Augmented Generation, c'était enfin une approche pour permettre aux LLM de répondre à des questions sur vos données, sur vos documents, de vos utilisateurs.
Donc ça, c'était, on voit qu'on industrialise finalement cette utilisation des LLM. Donc on passe de la machine à vapeur au train, au TGV électrique, etc. Et puis cette année, le mot-clé qu'on entend vraiment un petit peu à toutes les sauces, c'est cette notion d'agent IA. Donc là, j'ai transformé un petit peu mon train en avion parce qu'on entend quand même beaucoup de science-fiction sur les agents IA. Et quand on essaie d'en développer soi-même, d'en mettre en place, etc., on s'aperçoit qu'il y a quand même certaines limitations. Et du coup, moi, dans cette présentation-là, je vous parlerai aussi de patterns, d'anti-patterns, de choses qui marchent ou qui ne marchent pas, et des choses auxquelles il faut faire attention quand on va dans cette voie-là. Il y a pour moi trois types d'agents. Il y a les chatbots, ceux que vous connaissez, des Gemini, des Claude, des chat GPT, Grok, etc. Ceux que tout un chacun peut utiliser, le grand public, etc. Après, il y a ceux aussi qu'on peut créer dans l'entreprise, bien sûr.
Deuxième grand persona, c'est les coding assistants. Donc ça va être GitHub Copilot, Gemini Code Assist, Cloud Code, Gemini CLI, etc. Donc là, c'est vraiment ces outils, ces agents qui vont aider les développeurs à coder, à être plus productifs, faire aussi bien de la complétion de code que là, on approche avec cette approche agent à automatiser et déléguer des tâches. On a vu déjà des choses super intéressantes depuis ce matin. Et ceux qui m'intéresseront un petit peu plus aujourd'hui, et mes conseils sont plus par rapport à ce type d'agent-là, c'est plutôt ces programmes, ces agents IA que vous, vous allez développer, intégrer dans vos applications, dans vos sites web, sur vos données, etc. Donc c'est plus moi, ceux-là qui m'intéressent, même si je donnerai quelques mots par-ci, par-là, par rapport aux autres, aux deux premiers personnages. Ce qu'il faut voir, il y a une définition, qu'on soit tous un petit peu sur la même définition de ce qu'est un agent.
Il y a une définition un petit peu ancienne qui est qu'un agent, c'est un agent. C'est un système qui a la capacité de ressentir son environnement et d'agir sur son environnement. On a des capteurs, des actuateurs, etc. Qui agissent sur l'environnement. Donc ça, c'est la définition un peu traditionnelle de cette notion d'agent. Les agents dont on parle aujourd'hui, ce sont des agents qui sont basés sur les LLM, les Large Language Models, mais il y a d'autres caractéristiques ou d'autres composants. C'est comme ça que je définis les agents, c'est mon équation des agents, qui est à peu près acceptée, on en a tous plus ou moins la même, mais moi j'aime bien le présenter sous cette forme d'équation. C'est-à-dire qu'un agent a besoin d'un cerveau, son cerveau c'est quoi? C'est le LLM. Le LLM a aussi besoin d'une mémoire, au moins une sorte de mémoire à court terme, qui est la mémoire, si c'est un chatbot, ça va être la conversation en cours avec l'utilisateur, si c'est un agent de codage, ça va être toutes les tâches qu'on va avoir données à l'agent de codage.
Après, il y a aussi des mémoires à long terme, donc peut-être qu'on va se rappeler qu'on a certaines préférences quand on code, ou que si ce n'est pas un agent de codage, si c'est un agent qui nous permet de faire des recherches documentaires, peut-être qu'il va se rappeler des recherches qu'on a faites la veille, etc. Et que ça va pouvoir permettre d'enrichir la conversation avec plus de contexte. Donc LLM plus mémoire plus... Alors un aspect très important, c'est quand même la planification. parce que les agents sont là pour atteindre un but, Mais pour atteindre ce but, il y a souvent certaines étapes à suivre. Ça peut être d'appeler des outils, des API, des choses comme ça. Et donc, il va falloir essayer de décomposer. Alors, soit ça peut être le développeur, soit ça peut être le LLM lui-même, le cerveau lui-même de cet agent, qui va définir les différentes étapes au travers desquelles il faut passer. Planification et qui dit étape, dit aussi appel d'outils justement.
Donc on adjoint à nos agents des outils. Donc ces outils-là peuvent être sous différentes formes. Vous avez peut-être entendu parler de MCP, vous avez peut-être entendu parler de function calling. Là c'est vraiment la fonctionnalité intrinsèque des LLM qui permet d'appeler aussi des choses comme MCP. Et en fait autour de tout ça on a une sorte de grande boucle while, boucle for, qui fait des itérations. Alors des itérations éventuellement pour reprendre un peu plus de feedback de l'utilisateur ou pour continuer la conversation avec l'utilisateur. Ça peut être aussi si c'est un agent qui fait, je disais de la recherche documentaire tout à l'heure, qui s'aperçoit que, ah oui, là je réponds à la demande de l'utilisateur, mais peut-être que si je recherchais encore un tout petit peu, je vois qu'il y a un petit trou dans la raquette dans mon document, je vais aller continuer la recherche, refaire une recherche RAG, Google Search ou n'importe quoi. Donc c'est ça l'équation des agents et on a besoin de tous ces composants là pour être capable d'avoir tout type d'agents, que ce soit codage, chatbot, etc.
Dans cette boucle, il y a quand même trois grandes caractéristiques de tâches qui sont effectuées, des tâches d'observation, des tâches de planification et les tâches d'action. Donc si on regarde en bleu ce que j'ai appelé observer, il y a la pensée du LLM qui est en train de se dire, ah oui, voilà, la requête de l'utilisateur c'est ça, j'ai mon prompt système, j'ai un but à atteindre, qui est paramétré par ce que j'ai fait. cette demande de l'utilisateur. Ensuite, le LLM a bien compris ce qu'il doit faire, et là, il va planifier, et il a des outils, on a dit, à sa disposition. Donc, le LLM va dire, ah, si on pouvait appeler pour moi, parce qu'en fait, les LLM, ils n'appellent jamais aucun outil par eux-mêmes. Ils délèguent cet appel, ils demandent au framework qui les intègre, est-ce que tu pourrais appeler, s'il te plaît, l'API Jira pour regarder les tickets? Le LLM n'appelle jamais rien, il ne fait que des demandes. Et on lui donne, au travers du framework, agentique, etc., qu'on utilise, on lui donne les réponses de ses appels. Donc bref, je referme la parenthèse, un petit détail, mais ça m'irrite toujours quand on dit« Ouais, les LLM, ils appellent des fonctions.
» Non, ils n'appellent pas vraiment des fonctions. Bref, dans cette planification, ils vont dire« J'ai besoin peut-être de faire une recherche, je rague sur ma base de données. documentaire, peut-être qu'il faut que je fasse un appel d'une API externe. Si l'utilisateur me demande la météo, je vais appeler Météo France. Il y a aussi des LLM qui sont assez futés. Je fais de la pub pour Google, mais Gemini, par exemple, il peut créer du code et l'exécuter dans une sandbox quand il a besoin de faire quelque chose qui est très logique, voire mathématique. Donc plutôt que d'halluciner des chiffres et des résultats d'algorithmes, certains modèles sont capables d'exécuter du code. De créer le code et de l'exécuter pour obtenir le résultat. Et ce que j'aime bien mentionner quand même, c'est que dans les actions, il y a aussi des actions où on intègre, l'humain. On ne va pas forcément tout automatiser. Alors parfois, c'est pour des raisons purement légales, c'est-à-dire qu'il faut qu'il y ait un tampon d'approbation par un être humain, parce que légalement, on est obligé, mais ça peut être demander plus d'informations, ça peut être de valider les nouveaux agents de codage type anti-gravity, etc.
On crée des plans d'action et on va les valider, on va les reviewer, on va travailler main dans la main avec les agents. Donc la partie action est une phase qui est potentiellement, alors pas forcément optionnelle, mais en tout cas elle n'est pas forcément là dans toutes les boucles et dans tous les types d'agents, c'est la partie réflexion. Donc c'est là où le LLM va se dire, ah oui c'est pas mal ce que j'ai fait, par contre peut-être que, ce que je disais tout à l'heure, il manque peut-être une section ou une recherche que je pourrais faire, une recherche complémentaire, pour que mon document final que je vais retourner à mon utilisateur soit plus pertinent et soit vraiment complet. Et du coup, la boucle peut continuer comme ça jusqu'à atteindre, soit une limite de tour, soit le LLM est content pour ce qu'il a généré, ou l'utilisateur a dit« ouais, ok, c'est bon, pas besoin d'aller plus loin». Donc voilà cette boucle autour de ces attributs de cette équation des agents. Donc venons-en maintenant à des patterns et anti-patterns que j'ai pu repérer, voir, soit moi-même, soit en discutant avec des clients, avec des développeurs, à des événements, des conférences, des architectes, etc.
Tout d'abord, quand on entend parler d'agent IA, on voit beaucoup de... d'influenceurs IA, etc., qui parlent d'autonomie, on n'aura plus besoin de personnes, plus personne n'aura besoin de travailler, vu que les IA feront tout à notre place. Et en fait, on imagine, c'est un peu de la science-fiction, et moi c'est le côté un peu magique qui m'ennuie, c'est-à-dire qu'on survend un peu le concept, les agents IA peuvent faire des choses très très bien, mais le concept d'agent complètement autonome et où on n'a jamais besoin des êtres humains, ça m'embête un petit peu. En fait, les LLM continuent, encore aujourd'hui, même les meilleurs modèles, continuent d'halluciner. Et en particulier, je vous disais, pour cette histoire d'appel d'outils, de fonctions, etc., on appelle ça le function calling, c'est un attribut des LLM en eux-mêmes. Et en fait, le function calling, c'est le LLM qui dit, oui, il faudrait qu'on appelle cette fonction avec tel paramètre, etc. Mais en fait, les LLM, parfois, ils disent, ah tiens, il faudrait qu'on appelle cette fonction. Ouais, mais attends, elle n'existe pas, où est-ce que tu l'as inventée, elle vient d'où?
Ou alors, on lui a dit, il y a plein de fonctions qu'on peut appeler pour toi, mais il nous dit, ah oui, tiens, on va appeler celle-là d'abord. Et après, ah oui, mais non, il faudrait d'abord que tu appelles l'autre avant d'appeler celle-là, parce qu'il faut que tu passes l'argument de retour de l'autre à cette fonction-là. Donc il y a quand même un ordre qu'il faut que tu suives. Ben non, ils sont encore capables d'halluciner. Et pareil, d'ailleurs, quand il y a des ordres d'invocation qui sont incorrects, justement, ils ont besoin des paramètres du précédent appel, parfois, j'ai vu les LLM halluciner les paramètres qui sont passés aux fonctions. Et du coup, on a des choses... Et puis les LLM, ils aiment bien quand même, avec aplomb, nous répondre« you're absolutely right», etc. Et ça ne leur pose pas de problème, ils ne s'aperçoivent pas forcément qu'ils ont tort. L'autre chose que je vois aussi, c'est qu'on part d'un prompt qui est déjà assez solide, pas forcément trop compliqué au départ, et dès lors qu'on met l'agent en face des utilisateurs, il y a des petits cas particuliers auxquels on n'avait pas pensé.
Je vais modifier mon prompt, je vais rajouter un prompt. petit paragraphe sur tel cas particulier, et en fait on rajoute des cas particuliers, des cas particuliers, et on s'aperçoit qu'on est en train de créer une sorte de monolithe, de méga, de giga prompt, et plus le prompt est grand, plus les LLM ont des soucis et hallucinent, et d'où aussi tout ce qu'on appelle context engineering, etc. Garbage in, garbage out, vaut mieux mettre que ce qu'il faut vraiment dans le contexte d'un LLM pour qu'il réponde correctement, plutôt qu'il soit confus parce qu'il y a trop de choses dans son contexte. Je vais en reparler après. Justement, dans ce slide-là, le pattern qui marche bien, c'est le pattern du chef d'orchestre, où on va exploser en plusieurs petites tâches ou sous-agents le boulot. Il va y avoir, nous, développeurs, éventuellement, les personnes qui designent ces agents IA, qui vont dire, voilà, clairement, il y a des sous-tâches.
Là, il y a une tâche de recherche, là, il y a une tâche de résumé, là, il y a une tâche de synthèse, etc. Plus les tâches sont spécialisées, et si on ne donne que les bonnes informations de contexte à l'agent IA, il sera... Plus performant et plus capable de répondre correctement. Donc il y a différentes manières de décomposer les choses, sous forme de graphes, par exemple en graphes, qui est un framework, ADK, Longchain4J, moi je les utilise et je suis contributeur à ces frameworks en Java, je suis un développeur Java, et on n'est pas obligé de faire du Python, pour faire de l'AI et du machine learning. On peut très bien faire tout ça et tous ces agents IA en Java. Une autre petite parenthèse, même si j'en choque peut-être certains d'entre vous. Après aussi, tout ce qui peut être automatisé ou défini sous forme d'un flowchart, on sait toujours que le processus passe par telles et telles étapes. Si on est capable de le décrire, c'est qu'on peut peut-être utiliser un outil de workflow type N18, où on peut même écrire de manière programmatique, on écrit l'algorithme
dans l'ordre dans lequel on veut appeler les LLM, les agents, etc., pour avoir vraiment des sorties déterministes. Et donc les outils, je vous parlais des hallucinations par rapport aux outils, parce qu'en fait, à la limite c'est plus l'antipaterne que je souligne ici, mais il ne suffit pas juste d'exposer une API REST à un LLM, parce qu'il y a énormément de ressources, énormément d'opérations sur ces ressources, get, put, post, delete sur tout un tas de ressources. Les LLM sont plus finalement RPC, il vaudrait mieux créer en quelque sorte des tâches métiers ou des fonctions métiers à appeler, plutôt que, par exemple, pour une planification de réunion, get la disponibilité de la personne, get la dispo de l'autre personne, est-ce qu'il y a des salles qui sont libres? Non, autant lui donner une fonction qui fait ce travail-là, plutôt que de se dire, ils sont malins les LLM, ils vont faire le boulot pour moi. Donc, si on est capable de donner moins d'outils, ou juste les bons outils au LLM au bon moment, Il y aura moins de confusion et plus de déterminisme et donc plus de performance.
Donc idéalement, essayer de sélectionner, de filtrer, voire dynamiquement. J'ai déjà discuté avec une startup qui avait ce besoin-là, de ne donner qu'un sous-ensemble dynamique en fonction du contexte d'un sous-ensemble d'outils. Troisième pattern, c'est un truc assez à la mode, MCP, modèle contexte protocole. C'est un protocole qui a été inventé il y a un an, il vient de souffler sa première bougie, par Anthropic, ceux qui font les modèles cloud, etc. Il a été décrit un petit peu comme l'USB des outils, un protocole pour standardiser les interactions qu'il y a entre les agents et des outils, des fonctions, des API, etc. Et ce qui est intéressant, c'est qu'une fois qu'on a développé, parce qu'un peu historiquement, j'allais dire, sur chaque projet qui avait besoin d'accéder à, je ne sais pas moi, Jira, pourquoi pas, pour récupérer les tickets, on n'a pas besoin de coder cette glu d'intégration dans chacun des projets. On utilise juste le serveur MCP Jira pour aller chercher les tickets. Soit on le développe, soit on en utilise un sur étagère, et on gagne beaucoup de temps.
Donc ce que vous pouvez faire, ce qui peut être intéressant, et aussi pour interagir, interopérer avec d'autres agents, d'autres sociétés, etc., c'est aussi créer vos propres serveurs MCP pour d'autres agents IA. Donc, vraiment à suivre. Une petite remarque aussi, c'est que le S dans MCP, vous le voyez, vous l'entendez, Vous entendez peut-être S-M-C-P ? Non. C'est vrai que c'est un protocole qui n'avait pas forcément été pensé encore au départ pour l'entreprise, et donc il y avait des enjeux de sécurité qui arrivent petit à petit dans les dernières évolutions de la spécification, mais c'est quelque chose à garder en tête, les problématiques de sécurité avec ce genre d'outils. Deuxième protocole que je voudrais mentionner avant de passer aux antipatterns, c'est A2A, Agent to Agent Protocol. C'est un standard qui a été lancé il y a 6 mois, 8 mois, je ne sais plus où. ou un truc comme ça par Google, et qui permet de définir un protocole pour que des agents discutent entre eux. Donc là, on ne parle pas de standardiser les outils, ça c'est MCP, on parle de standardiser les interactions entre agents.
Et l'idée de A2A, en fait, un agent peut présenter une carte d'identité et dire, voilà moi ce que je sais faire, Il va y avoir des échanges, pas forcément que textuels, comme on imagine deux agents qui chatent, un chat textuel, ben non, c'est pas vraiment ça. Donc oui, il y a du texte, mais ça peut être du JSON, ça peut être des images, ça peut être des vidéos, ça peut être d'autres types d'entrées. Et on va avoir des messages qui vont créer des tâches, et les tâches vont créer des artefacts, et les artefacts sont le résultat qui sont échangés entre ces agents. Donc c'est vraiment quelque chose qu'il faut regarder. C'est un protocole qui est extensible, et il y a déjà des extensions, par exemple, pour le paiement, même aussi les crypto-paiements, etc. Donc ça, c'est vraiment deux choses à regarder de près, parce que c'est les deux grands protocoles et standards qui ont été adoptés assez rapidement et qui continuent d'évoluer dans le domaine des agents. Ensuite, les agents IA, il y a quand même certaines limites, il y a certains antipatterns que j'ai pu voir.
Je vais commencer par le premier qui m'irrite, et j'en suis aussi en quelque sorte responsable, c'est quand moi je fais des présentations à des événements pour les développeurs, etc. Le plus facile pour faire une démo, souvent, c'est de faire un chat. pour discuter avec un agent. Mais le problème, c'est que je vois pas mal d'entreprises où, en fait, il faut vraiment qu'on ait de l'IA dans nos applications. Et si on faisait un chatbot? On va rajouter le chatbot. C'est la réponse à tout. Mais souvent, le chatbot, en fait, je ne sais pas vous, mais souvent, les chatbots, pour moi, c'est plutôt frustrant. Et je pense que tout n'a pas besoin d'être conversationnel dans le sens textuel, je tape directement avec le chatbot, mais penser plutôt multimodal, plutôt des composants riches, etc. Et les specs comme MCP et A2A sont en train de s'enrichir avec des éléments graphiques au-delà du texte. Et là, je prenais la petite illustration, c'est un head-up display dans les cockpits d'avions de chasse, par exemple.
En fait, imaginez la frustration du pilote s'il doit demander et taper sur son écran, sur son clavier, est-ce qu'il y a des ennemis autour? Ah oui, il y a un avion. Ah oui, attends, prépare les missiles, ça va être super long. L'idée, c'est plutôt au contraire d'augmenter, on parle de développeurs augmentés, etc., mais d'augmenter les utilisateurs, les développeurs, avec des choses qui peuvent être visuelles et avec lesquelles on peut interagir sans que ce soit aussi frustrant que de taper du texte. Donc ça, à regarder. Et encore une fois, les protocoles intègrent, commencent à intégrer ça dedans. Deuxième anti-pattern que je vois, c'est des startups, des développeurs qui partent billes en tête. « Ah ouais, allez, je sais ce que l'utilisateur veut, je sais qu'il va demander ça, ça, ça. Ils font des tests, ça a l'air de bien marcher, et dès lors qu'on met en production et qu'il y a des vrais utilisateurs, ça ne marche pas trop. Donc le vibe checking, c'est le premier test un peu intuitif qu'on peut faire. Sont verts, ils ont passé, mais en tout cas, ils ne répondent pas à l'épreuve du feu des vrais utilisateurs. Donc il faut être sûr de travailler avec les experts du métier, d'essayer de collecter de vraies questions, vraies réponses, qui peuvent faire un dataset de Golden Response, qu'on va pouvoir réutiliser pour fine-tuner un modèle, pour
faire de la vraie évaluation, en fait. Et on peut... Donc l'évaluation, c'est vraiment le truc clé ici. Si vous avez du RAG, il y a différents outils qui peuvent être utilisés, DeepEval, Promfou, etc., pour mesurer la qualité, la performance du RAG. Si on n'a pas de Golden Response, recherchez RAG Triad. C'est un truc très intéressant pour vérifier ce que génère un LLM par rapport aux données qui sont remontées, ou des patterns comme LLM as Judge, où on demande à un LLM de juger si ce qui a été généré a l'air d'être correct. Mais en tout cas, la phase d'évaluation dans un projet Gen AI est indispensable et clé, n'en faites pas l'impasse. Troisième exemple que je voulais montrer ici, alors IVO, vous ne le trouverez pas vraiment beaucoup sur Internet, mais c'est un de mes collègues à moi qui a inventé cet acronyme, Immediately Validatable Output. L'idée, en fait, c'est que... Par exemple, si vous faites du RAG, on sait que les LLM... Les LLM ont tendance à inventer des réponses avec force et conviction.
Ils vont nous dire« you're absolutely right», bien sûr, c'est comme ça que ça se passe. Alors qu'en fait, si vous avez donné au LLM enrichissement, la réponse, la véracité, la performance de cette réponse. Dernière chose, un petit peu comme dans tous les projets, on se rapproche aussi peut-être du persona agent de codage. Moi, je l'ai vécu personnellement encore la semaine dernière. En fait, on part un petit peu bille en tête. Je suis un développeur augmenté. Là, je vais utiliser l'IA pour m'aider à corriger mon problème. Et en fait, on commence à tirer le fil.
Et il n'arrive pas. L'agent va essayer de corriger son truc. Et là, il rajoute encore plus de code. Et puis là je lui dis, ouais mais t'as pensé à ce qu'elle a, ah non, il rajoute encore plus de code et dans mon vrai cas, la semaine dernière, il y a un senior engineer qui a trouvé le fixe, c'était juste une ligne et moi j'étais parti avec mon agent de codage en lui faisant confiance et il m'avait déjà pondu 100 lignes de code et toujours aucun résultat en deux heures. Donc, encore une fois, les senior développeurs pour reviewer le code ou pour juger ce qui est sorti, etc., je pense qu'ils ont un bel avenir devant eux. Mais voilà, il faut essayer de parfois être capable de relever la tête du guidon dans ses développements avec les agents IA pour essayer de se focaliser sur la valeur ajoutée, sur la pertinence de ce qui est fait, de ce qui est généré. Parce qu'aujourd'hui, même si honnêtement, les LLM s'améliorent par rapport à... Il y a un mois, il y a six mois, il y a un an, c'est le jour et la nuit ce qu'ils sont capables de faire. Mais malgré tout, il faut quand même encore les accompagner et les aider. Et aussi éviter, ce que j'aime bien, c'est ces agents qui vous disent« si vous voulez, on peut rajouter aussi cette fonctionnalité».
Oui, mais on va peut-être s'arrêter là, on va déjà se focaliser sur ce qui apporte vraiment de la valeur pour les utilisateurs et non pas d'en rajouter trop. Donc, j'allais dire lundi matin, on est déjà lundi, mais mercredi, quand vous allez retourner au bureau. Est-ce que l'agent fait le bonheur ou est-ce qu'il y contribue? Vous allez en tout cas préparer votre petite to-do list et essayer de... Déjà d'imaginer que vous n'avez pas forcément besoin d'un chatbot, parce qu'on n'en a pas toujours besoin. Essayez de penser à différentes manières de faire. Travaillez aussi avec vos UX designers, etc., parce qu'ils ont souvent de très bonnes idées sur comment pouvoir intégrer des processus intelligents dans vos applications, sites web, etc. Et du coup, essayez de vous dire, qu'est-ce qu'on pourrait faire pour améliorer, là où il y a le plus de friction dans nos applications, est-ce qu'un agent IA pourrait aider à simplifier ça? Et puis voilà, il faut apprendre aussi. Donc on va commencer avec des premières applications, les premiers pas agentiques. Et puis on va apprendre, voir ce qui marche, voir ce qui ne marche pas.
Mais en tout cas, n'oubliez jamais d'évaluer, de mesurer. Et au final, c'est quand même vos utilisateurs qui seront là pour valider ou non la pertinence des choix que vous aurez faits. Voilà, merci beaucoup pour votre attention. Bravo! C'est quand même rouge. Allez, à 30 secondes près, j'étais bien. Non, mais c'est parce que tu as un badge rose. J'ai un badge rose, voilà. C'est de la bonne... C'est la première fois. Et c'est la première fois. Oui, c'est pour ça. Mais j'ai plus l'habitude de 50 minutes plutôt que de 25. Il a fallu... Parce qu'on est plus oral maintenant. Oui, mais moi, je peux en parler pendant des heures. Et d'ailleurs, il paraît que déjà, je peux leur parler tout de suite. Et en haut, apparemment, à l'étage. Alors là, on part pour 10 minutes de session. Mais surtout, ensuite, à l'étage, au premier étage, je pourrais leur parler même lors du petit pot qui suit le Tech Rock Summit. Alors justement, on va... Allumer ce parterre incroyable pour mieux vous voir. J'ai l'impression d'être sur une scène de concert. C'est un peu ça. Alors, qui a une question? Il y a quelqu'un qui a très vite levé la main. Voilà, qui a une grosse question à mon avis.
On sent que... Le micro arrive. Oui. Bonjour Mathieu, merci beaucoup pour cette présentation. J'ai une question architecture. On est tous et toutes très malheureux des occurrences d'hallucinations qu'il y a aujourd'hui. Apparemment, le propos sur le marché, c'est qu'une architecture basée sur les transformers ne permettrait pas de contourner ou de régler le problème. Est-ce que vous avez une position sur le sujet? Alors, malgré tout, les LLM s'améliorent beaucoup et diminuent le nombre d'hallucinations qu'ils ont tendance à faire. Donc les choses s'améliorent, mais c'est vrai que ce sont des systèmes non déterministes. Et par définition, oui, il y aura forcément un petit pourcent ou un pouillème de pourcent. où potentiellement il pourra y avoir des hallucinations. Ça, c'est toujours vrai. Mais l'idée, c'est aussi de mitiger le risque et justement de décomposer en sous-tâches, sous-agents, d'essayer de faire du context engineering. Donc il y a quand même pas mal de choses qu'on peut faire pour arriver à avoir des résultats qui sont plus pertinents et qui évitent au maximum les hallucinations.
Après, est-ce qu'on peut totalement... s'abstraire et oublier les hallucinations. J'ai vu il n'y a pas très longtemps, il y a un mois, il y a des chercheurs qui ont trouvé une manière en tout cas de faire et de... d'avoir des résultats plus déterministes, mais il faut voir que ça a des impacts en termes de coûts. C'est-à-dire que le non-déterminisme vient de la méga-paralysation des opérations de calcul matriciel dans les GPU, et TPU, etc. Et en fait, il peut y avoir des erreurs d'arrondi, parce qu'on ne fait les choses pas toujours dans le même ordre, le GPU réorganise les instructions, et c'est un peu l'effet papillon, une petite erreur à un endroit va se répercuter, et même si on met la température à zéro, etc., en fait, on va s'apercevoir qu'au bout de 100 tokens ou 1000 tokens, il va y avoir des variations de toute façon. Donc il y a des chercheurs qui essaient de trouver une manière d'éviter ça, mais souvent ça veut dire avoir un seul GPU pour une seule personne à un instant T donné, et bien ça coûte très très cher, donc il y a peu de chances qu'on le voit demain. Est-ce qu'il y aura d'autres modèles qui arriveront? Peut-être, mais il y a quand même toujours le côté génératif, c'est quand même ce qui est intéressant, c'est justement parce qu'ils sont créatifs et il y a une notion d'aléatoire, qu'on a des choses, qu'on a des belles images, qu'on a des belles vidéos, qu'on a des beaux poèmes ou je ne sais quoi, ça vient quand même aussi de cet aspect-là.
Donc supprimer complètement le déterminisme? À voir. Enfin, les hallucinations, pardon. Non, ça on ne sait pas. Est-ce qu'il y a d'autres questions? On a 5 minutes? Ah oui, pardon, je ne vous avais pas vu. Bonjour Rémi, merci pour votre présentation. Je me posais la question dans des entreprises... Des domaines hyper réglementés type... le nucléaire, l'aéronautique, l'industrie pharmaceutique. Justement, comment on peut aborder la qualification de systèmes basés sur de l'IA? Parce qu'aujourd'hui, c'est quand même hyper compliqué. Est-ce que vous avez des retours d'expérience sur comment s'y prendre? Alors non, en tout cas sur des domaines aussi pointus et spécifiques, non, je n'ai pas de retour. Après, c'est vrai, ce qu'il faut voir aussi, alors il y a aussi des questions de souveraineté, de choses comme ça aussi, en plus, au-delà du déterminisme, des hallucinations. Et par exemple, chez Google, on a aussi une manière de faire tourner Gemini sans que Google lui-même sache en réalité ce qu'il est en train de générer dans des sortes d'enclaves privées, des choses comme ça.
Donc on a aussi des réponses par rapport à ces besoins de souveraineté et autres. Sans parler des modèles locaux, on a aussi un modèle qui s'appelle Gemma, qui est dérivé de Gemini, qui est aussi un modèle qu'on peut faire tourner localement dans son data center, etc. Mais après, au-delà, ça revient à cette question qu'on avait posée sur les hallucinations et le déterminisme, où ce n'est peut-être pas forcément les LLM qu'il faut utiliser pour certaines choses, mais peut-être d'autres types de modèles ou d'algorithmes, parce que les LLM, il faut aussi les utiliser à bon escient, et de la génération, oui, mais si c'est du calcul scientifique, ce n'est pas le bon outil. Voilà. On ne connaît pas beaucoup plus sur ce domaine-là, vu que je n'ai pas eu l'occasion, en tout cas, de me plonger dedans. Allez, je fais une dernière question pour deux minutes. Ah, il y en a une. Quelle chance. Bonjour. Bonjour. Du coup, j'avais une question parce que je me suis rendu compte qu'on a beaucoup parlé de MCP. Oui. Et vous avez évoqué des potentiels problèmes de sécurité.
Est-ce que vous avez des exemples de problèmes de sécurité qu'on pourrait rencontrer? Je ne suis pas un expert en sécurité, mais il y avait plusieurs articles qui sont apparus sur... Le rug pool, où en fait, on peut très bien avoir exposé certains outils, mais si à un moment, d'autres outils sont arrivés, on ne sait pas trop comment, peu importe le détail, mais on peut avoir un autre provider qui va avoir des outils qui vont, comment dire en français, shadower des outils existants, mais qui sont des outils malicieux, c'est-à-dire qu'ils apparaissent comme des outils valides, mais qui vont faire autre chose, exfiltrer des données, etc. Donc il y a différentes problématiques. Il y a ça, il y a les problématiques aussi de droit d'accès, c'est-à-dire qu'un LLM n'a pas de notion de droit d'accès. Donc ça veut dire que nous, quand on expose les outils MCP, comment est-ce qu'on transfère la notion d'identité de l'utilisateur pour savoir quelles données on a le droit de remonter, quelles données le LLM a le droit ou pas de voir aussi, même pour générer une réponse.
Donc il y a tout un tas de problématiques de sécurité, mais ça mériterait un autre... J'ai encore 25 minutes? Non, je n'ai pas encore 25 minutes. Je suis désolée. Mais il y a plein d'autres aspects importants de sécurité, d'authentification, etc., qu'il faut pouvoir gérer avec MCP. Suite au prochain épisode. Guillaume, merci beaucoup. Merci beaucoup. Merci infiniment. Merci. Et si vous avez aimé le talk de Guillaume, vous scannez le QR code pour nous faire part de vos commentaires. Merci bien. A très bientôt. En haut, si on continue la conversation. Et tout à l'heure. Voilà, exactement. Et puis, on a vu votre adresse e-mail. qui était à la fin, enfin, tu l'as adressé à la fin, sur ton dernier slide. Ça marche. Tu auras beaucoup d'amis, tu vas voir. Merci infiniment. Merci, amis.
