Le HTML5 des LLMs ?

Bruno:
Dans Matrix, les agents surgissent à travers n'importe quel humain, n'importe quel téléphone, n'importe quel programme. Ils ne posent pas de questions, ils exécutent. Mais imaginons que ces agents de demain ne soient plus là pour nous traquer, mais pour consommer des services. Plus besoin de Red Pill, juste un protocole. Mais alors, pourquoi MCP pourrait-il devenir la matrice des front-agents agentiques ? Qui sont ces nouveaux utilisateurs, humains, agents ou les deux ? Et surtout, comment on design une expérience pour un client qui n'a pas d'yeux, pas d'oie, mais juste un tokenizer ? Pour répondre à ces questions existentielles, je ne reçois pas l'adjant Smith, mais il s'y connaît en appel bien formé. Frédéric, bonjour.

Frederic:
Bonjour Bruno.

Bruno:
Alors Frédéric, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?

Frederic:
Oui, bien sûr. Je m'appelle Frédéric, mais tout le monde m'appelle Fred. Je suis CTO d'une entreprise qui s'appelle Alpic, qui fait de l'infrastructure pour MCP. Et j'ai fait mes classes notamment chez Theodo qui est une boîte de conseillers de développement pendant 7 ans où j'ai fait beaucoup d'infrastructures, notamment de serverless, une grosse communauté dont je faisais partie également.

Bruno:
Donc.

Frederic:
Touché à pas mal de trucs différents.

Bruno:
Alors j'imagine que si t'as une entreprise qui fait l'infrastructure pour du MCP t'as une entreprise qui doit avoir 15-20 ans d'existence j'imagine déjà.

Frederic:
Oui c'est exactement ça On a commencé au début de l'année, on a quelques mois de plus que le protocole lui-même.

Bruno:
Qui a commencé.

Frederic:
Fin novembre 2024 pour te donner une idée.

Bruno:
Et donc aussi un petit disclaimer parce qu'on est sur des technos qui bougent extrêmement vite on enregistre cet épisode, on est début août 2025, donc en fonction de quand vous écoutez cet épisode les choses ont pu peut-être beaucoup bouger depuis, avec tout ce qu'on va raconter avec Frédéric aujourd'hui donc voilà, n'hésitez pas à aller contacter Frédéric après l'écho de cet épisode si vous voulez avoir des éléments encore plus, encore plus nouveaux là-dessus. Donc l'idée effectivement c'est de creuser un peu aujourd'hui avec toi le sujet, du MCP parce qu'on en a parlé un peu quand on en discutait tu m'as ouvert les yeux sur plein de sujets tu m'as apporté aussi une nouvelle approche une nouvelle vision de ce que ça a apporté, et du coup je serais ravi de pouvoir creuser ça avec toi aujourd'hui, donc MCP en fait on est l'idée c'est de remplacer les API complètement avec le MCP, de pouvoir passer par des agents, comment est-ce que tu expliquerais le protocole de manière très simple en premier lieu ?

Frederic:
Oui, alors effectivement, on peut commencer par une petite explication sur le protocole. C'est un standard, c'est une manière de fournir un moyen de communiquer entre deux parties prenantes. En l'occurrence ici, d'un côté, un client, une application agentique, typiquement un chat GPT, un cloud, un VS Code, un cursor, un windsurf. Il y en a un pléthore aujourd'hui. Et de l'autre, un serveur, souvent la propriété d'une entreprise ou d'un fournisseur de services ou de produits. Et MCP va régir les communications qui ont lieu entre ces deux acteurs-là pour fournir du contexte supplémentaire à l'agent qui est présent côté client. C'est pour ça que ça s'appelle le modèle contexte protocole. C'est un protocole qui vise à fournir du contexte à un modèle.

Bruno:
Ok. Mais donc, c'est une explication de ton API REST pour qu'un agent type chat GPT puisse l'utiliser de manière simple et fluide ?

Frederic:
Alors, ce n'est pas qu'un mode d'emploi. C'est vraiment un point d'entrée. donc tu faisais le parallèle tout à l'heure dans ton introduction avec des frontages antiques MCP côté serveur c'est le front spécifique fait pour être consommé par une application agentique de la même façon que ton front web ou mobile est fait pour être consommé par des humains ou ton API REST est fait pour être consommé par des développeurs ou des applications tierces donc MCP ça vient vraiment répondre à des conditions des, contraintes particulières à ce dont un agent a besoin ce dont un modèle a besoin et ça vient répondre à ces contraintes là avec une nouvelle spécification un nouveau moyen de communiquer.

Bruno:
Donc en fait quand on parle d'un serveur MCP on pourrait dire qu'on a notre serveur web qui va être consommé par des humains on a notre API Gateway qui est on va dire un serveur API qui va être consommé du coup par les devs et un MCP server qui serait consommé par des Siri.

Frederic:
ChatGPT.

Bruno:
Gemini et autres.

Frederic:
Ouais tout à fait c'est exactement ça donc ça a beau avoir le nom serveur ça reste un front d'un software plus traditionnel enfin qui compose un ensemble de choses que tu peux faire avec ce software là exposé de façon, efficace, performante pour les besoins d'une IA, d'un modèle.

Bruno:
Mais du coup, en termes de dev pour ce serveur-là, on se rapproche plus du travail d'un serveur d'API ou d'un serveur web ?

Frederic:
Ça ressemble plus à du front, en vrai.

Bruno:
OK.

Frederic:
C'est un peu contre-intuitif, mais on va rentrer dans le vif du sujet. Une des premières fonctionnalités qui est disponible dans un serveur MCP c'est ce qu'on appelle les tools qui est un moyen pour le serveur d'exposer des fonctionnalités que peut appeler le client donc que peut appeler le chat GPT ou Cursor pour résoudre un problème donné, ces tools là c'est des fonctions pour faire du function calling qui prédate MCP. La quantité de tools que tu mets à disposition en tant que serveur MCP a un impact énorme sur les performances du modèle pour sélectionner le bon tool avec les bons arguments donc si tu lui donnes. La même quantité de tools que tu as d'endpoint dans ton API, il y a de fortes chances qu'il se perde dans la quantité d'informations, de chemin possible, si en plus de ça, pour pouvoir faire un parcours complet il faut que tu appelles cette API en premier puis celle-là trois fois, puis celle-là une fois par exemple pour initier un panier ajouter trois items dans ton panier et check out t'as sur ces 5 actions ces 5 tools calling une chance plus importante que le modèle se perde ou te donne le mauvais paramètre ou appelle le mauvais tool au mauvais moment alors que si tu lui condenses toute cette expérience là dans un seul tool qui représente plus l'expérience utilisateur de je vais remplir un panier et checkouter comme une personne en fronte le ferait à travers un tunnel d'achat t'as moins de chance que ton MCP que ton que l'agent se plante en termes d'utilisation de ton MCP serveur, Donc, ça ressemble vraiment plus à du design et à de l'implémentation de ce que tu ferais sur un front, parce que la problématique que tu as, c'est un agent, il va avoir tendance à t'utiliser de la même façon qu'un utilisateur va venir t'utiliser. Et du coup, les endpoints que tu as intérêt à mettre à disposition via des tools dans ton agent, c'est un peu des expériences utilisateurs complètes plutôt que des éléments micros que va pouvoir composer le modèle en espérant qu'il arrive jusqu'au bout dans les bonnes conditions.

Bruno:
Et donc, ça veut dire qu'il faut que tu gardes aussi tes différents, tes nouveaux endpoints, on va dire, ou tes nouvelles fonctions. Il faut que tu les gardes aussi extrêmement simples pour qu'ils puissent bien en comprendre l'usage, que ce soit en termes d'input à mettre dedans, ou de quand on l'appelait, ou comment on l'appelait.

Frederic:
Ouais, alors, pour te donner un exemple, pour illustrer ça, il y a l'extrême inverse en termes de design sur des MCP serveurs, où tu voudrais limiter au maximum la quantité de tools que tu mets à disposition. Et il y a une société qui s'appelle Goose qui a sorti un article il y a quelques temps. Goose qui est une société qui fait un client justement argentique avec un modèle et un client MCP qui ont sorti un pattern d'architecture pour des serveurs MCP qui s'appelle le Layer Tool Pattern dans lequel en fait tu n'aurais que trois tools, toujours, quel que soit le service que tu proposes. Un premier pour permettre au modèle de découvrir les services un peu généraux qui existent sur ton software. Par exemple Payment Service ou Catalog Service etc qui retournerait sans prendre aucun argument la liste de tous les grands domaines métiers qui existent sur ton application un deuxième qui pour un domaine métier en entrée retournerait une liste de fonctionnalités micro qu'il est possible de faire dans ce domaine métier par exemple sur le service Payment de créer un transfert ou de créer un virement ou de créer un payout et le troisième Endpoint qui permettrait d'appeler un tool spécifique, d'un des services spécifiques avec les arguments qui vont avec du coup avec ces trois tools théoriquement tu pourrais couvrir un besoin infini de fonctionnalité sans pour autant perdre le modèle puisque à aucun moment il aurait l'intégralité de ce qu'il est possible de faire avec ton serveur, il le découvrirait au fur et à mesure à chaque fois, mais comme on en parlait tout à l'heure, ce genre de choses là vient toujours avec une contrepartie, c'est un compromis que tu fais et là le compromis que tu fais évident sur ce genre de patterns là, c'est que l'agent va toujours devoir avoir trois interactions avec ton serveur, trois allers-retours pour pouvoir faire une chose. Le curseur, il est toujours à placer un peu au milieu. Soit je fais trop de tools et c'est des actions trop micro et quand j'arrive à 40, 50 tools, mon modèle est complètement perdu. Soit j'en fais que 3, mais la quantité d'aller-retour entre le modèle et mon serveur MCP est 3 fois plus importante pour qu'il réussisse à faire une action. Et en termes d'expérience utilisateur, qu'attendre derrière que son chat GPT fasse ses courses pour la paella qu'il fait ce soir, c'est horrible ce temps d'attente. Du coup, il y a vraiment ce curseur à mettre au milieu de là aujourd'hui mon business qui a une présence en ligne qui jusque là avait un site web et une app mobile pour permettre à mes utilisateurs de faire quelque chose et une API pour permettre à des softwares tiers de s'intégrer, qu'est-ce que je veux cristalliser comme parcours utilisateur les plus importants à travers mon MCP serveur pour qu'un agent puisse les faire pour un être humain.

Bruno:
Est-ce que du coup cette limite là que t'évoques quand tu dis que si on a trop de tools ton modèle il se perd, est-ce que tu penses que c'est quelque chose de très actuel et en fait peut-être que dans un an tu pourras avoir 200 tools et en fait le modèle il sera géré très bien ou est-ce que tu penses que quoi qu'il arrive il faudra essayer de rester sur quelque chose de sobre là-dessus.

Frederic:
La réponse que je donne toujours c'est meet me in the middle donc on peut rester côté développeur MCP Server sur, l'envie d'avoir 200 tools à disposition et parier sur le fait que dans 6 mois les modèles qui aujourd'hui galèrent avec 15 tools ne galèreront plus avec 200 tools à disposition. Mais j'exhorte les gens à développer de telle sorte à se rapprocher le plus possible d'un compromis fait avec le client qui les consomme. Parce que dans cette équation, tu n'as jamais la garantie que l'utilisateur qui va tasquer un agent professionnel, Travailler avec ton MCP serveur et faire quelque chose. Utilise le modèle dernier cri qui sera sorti par OpenAI ou Anthropic ou quelqu'un d'autre. Dans le lot, tu vas aussi avoir des gens qui utiliseront des modèles qui ont un an, deux ans, peut-être trois ans pour des raisons de coûts et surtout de contrôle des coûts pour ne pas utiliser les modèles qui sont les plus chers au token. De la même façon que dans l'écosystème web tu as plusieurs navigateurs qui accèdent à ton site front et qu'il faut que tu sois capable de gérer des navigateurs qui ne sont pas ceux qui sont sortis le mois.

Bruno:
Dernier en même temps sur le marché des navigateurs il y a quand même une concentration aujourd'hui quasiment tous les navigateurs fonctionnent sur le moteur chromium, on suppose aujourd'hui que les navigateurs se comportent à peu près de la même façon je ne sais pas quand est-ce que tu as commencé le développement web, moi j'ai commencé le développement web dans les années 90, 87, 98 t'en avais plus que moi du coup à l'époque on avait beaucoup de navigateurs et les navigateurs se comportaient de manière extrêmement différente, tu vois quand on a vu des librairies arrivées qui géraient cette, disparité entre navigateurs et que t'avais plus besoin de gérer toutes tes fonctions toi-même selon chaque navigateur ça a été une bouffée d'air frais, est-ce qu'on va avoir et tu vois quand tu parles aussi du MCP ma vision que j'en ai aujourd'hui c'est que c'est un truc qui est très poussé par OpenAI Anthropik.

Frederic:
C'est Anthropik qui.

Bruno:
L'a sorti ah bah tu vois ma vision c'était OpenAI donc finalement ça a réussi non mais en fait ma question c'était dans le sens où, tu vois aujourd'hui le web est formaté d'une telle manière qui correspond à ce que Google demande aux gens parce que Google a une telle place que quand ils disent en fait si vous voulez te référencer voilà la structure adoptée, les gens le font parce que si t'es pas sur Google t'es dans le dark web à peu de choses près quoi.

Frederic:
Je vais aller sur ce parallèle là quand tu dis Google met en place des standards que tu dois suivre typiquement d'avoir un score lighthouse de plus de 90 pour être bien référencé en termes de SEO t'as un risque non négligeable que demain il y ait Anthropic ou OpenAI qui arrivent et qui disent votre serveur MCP doit avoir moins de 20 tools parce que sinon je vois pas l'intérêt d'aller le pousser à mes utilisateurs s'il y a des serveurs MCP qui font la même chose que vous mais plus efficacement à côté, donc on en est pas encore là mais ce Meet Me in the Middle il est vraiment nécessaire pour que les équipes de développement qui mettent à disposition des serveurs elles fassent l'effort d'aller faire quelque chose d'efficiant pour être sûr que le modèle en face il ne galère pas et il ne se perde pas et cet effort il sera forcément récompensé parce que du coup il y a des modèles moins performants qui pourront être utilisés et on ne sera pas en attente de ce qui va sortir dans un an deux ans pour pouvoir faire en sorte que l'expérience utilisateur soit quand même bonne.

Bruno:
Tu peux te retrouver comme on l'a aujourd'hui avec Google tu peux te retrouver avec un acteur qui dicte un peu ce qu'est la norme est la bonne façon de faire.

Frederic:
Oui, c'est vrai que c'est un risque que ça puisse arriver. Je pense que le consensus, même un Google avec les scores Lighthouse avait quand même établi un consensus sur ce qui était bien à faire. Le fait que rapidement, que tu aies un time to first pane qui soit assez bas pour que rapidement l'utilisateur ait un contenu visuel avec lequel il puisse interagir, avec un time to first interaction qui est aussi bas. Ce n'était pas qu'un diktat d'un Google qui était intéressé pour son business. C'était aussi un dictat d'un Google qui était intéressé pour l'expérience de ses utilisateurs et du coup ça a...

Bruno:
Ce qui sert son business derrière.

Frederic:
Ce qui sert son business c'est vrai mais ce qui a servi par intermédiaire les utilisateurs si aujourd'hui tu fais un MCP serveur qui marche mieux avec un chat GPT ou un cloud, t'as des chances que les utilisateurs qui soient derrière ils soient contents in fine de chat GPT et de cloud, c'est sûr que ça va leur servir eux mais aussi du service que toi t'as fourni en tant qu'entreprise à cet utilisateur final à travers chat GPT ou cloud.

Bruno:
Pour continuer un peu sur ce parallèle justement avec Google, est-ce que dans cette construction de ton serveur MCP, tu as aussi toutes ces notions de comment être bien référencé par ton moteur ou c'est du coup des sujets très différents ?

Frederic:
Là, en ce moment, août 2025, du coup, la discovery, c'est un vrai sujet. Il y a des initiatives qui commencent à se mettre en place, notamment dans le groupe du modèle contexte protocole, donc le steering committee qui pilote la direction que prend le standard. Il y a une initiative d'un registry open source déjà pour pouvoir lister l'ensemble des serveurs. Il y a eu beaucoup d'initiatives à plein d'endroits différents dans la communauté mais aucune qui a été cristallisée au sein du protocole lui-même. Donc ça c'est déjà un truc qui est bien avancé, qui devrait sortir d'ici septembre. Et ça, ça reste de la discovery pour des techs. Le registry, comme on en a un sur NPM, par exemple, c'est quand même un outil à la base pour des développeurs. MCP, ça a vocation à aller plus loin que la communauté de développeurs, puisque le but, in fine, c'est d'outiller même le commun des mortels à travers son chat GPT avec des interactions sur ces outils du quotidien. Et du coup on peut pas uniquement se reposer sur un registry et là on voit des initiatives arriver typiquement côté anthropique qui a commencé à sortir une marketplace, un app store grosso modo où des grands acteurs aujourd'hui sont référencés mais sur lequel il y a déjà un formulaire pour pouvoir en tant qu'entreprise qui a crafté son MCP serveur postuler à être présent sur le store et du coup on voit l'histoire se répéter de ce qui a été la naissance de l'app store il y a maintenant pratiquement 20 ans de ça, avec Apple qui a poussé la présence d'un App Store sur ses mobiles pour que les développeurs puissent y shipper des expériences.

Bruno:
Ça, OpenAI, ils ont essayé avec CHGPT en 2022, quelque chose comme ça je crois, de souvenir. Ils avaient aussi un plugin store où tu pouvais ajouter un plugin à des conversations. Il y avait notamment un plugin de Kayak pour la comparaison de vol ce genre de choses. Ça a complètement disparu. Pour toi, c'est quoi ? C'est que MCP n'était pas encore prêts, les développeurs n'étaient pas prêts, c'était quoi le...

Frederic:
Il y a certainement une combinaison de plein de facteurs positifs, il y a aujourd'hui des gens qui ne comprennent toujours pas pourquoi MCP par rapport à un autre protocole, par rapport à 8Way et des fois il y a juste une solution vers laquelle les gens convergent parce qu'un peu de traction à un moment du coup il y en a de plus en plus qui vont derrière alors que peut-être qu'in fine si on avait regardé toutes les solutions qui existaient à un instant donné c'était pas la solution la plus optimale il y a beaucoup de choix technologiques qui nous entourent même pas juste dans la tech dev qui sont des choix technologiques qui sont apparus par consensus mais qui n'étaient pas le choix le plus optimal à un instant donné. Du coup, qu'est-ce qui fait que MCP est anthropique avec sa marketplace aujourd'hui, va mieux ou pas réussir par rapport à ce qui a été fait par ChatGPT il y a deux ans avec le ChatGPT Store ? Je n'ai pas la réponse à la question. Une fois de plus, c'est une initiative à la deux semaines dans les pattes. Donc ça, c'est un truc qui, on pense, va aider parce qu'on a besoin de ce système de discovery pour les end-users pour venir connecter son calendar, connecter son Gmail, connecter son plan, connecter ses messages, son WhatsApp, etc. Et que du coup, s'il y a de la demande, le store, il n'y a pas de raison qu'il arrête de grossir. Ça permet réellement, en plus, ce genre de store-là, de sortir de ce précepte de MCP. C'est une technologie faite pour des développeurs parce qu'à la base c'était surtout ça c'était moi en tant que dev sur Cursor je veux connecter mon file system je veux connecter GitHub je veux connecter, Superbiz je veux connecter plein de systèmes que j'utilise en tant que développeur mais je veux que ça soit mon agent Cursor ou Cloud Code ou Q qu'il le fasse, avec moi dans la conversation j'ai plus besoin d'utiliser, une interface web donc ça c'est cool pour ce genre d'initiative là pour sortir justement d'une technologie confidentielle Dev Only ou Tech Savvy Only. Mais c'est pas la seule initiative qu'on pense va aider à ce système de discovery on pense qu'on va voir réapparaître aussi assez rapidement un système similaire à celui du SIE chez Google c'est à dire que en tant qu'utilisateur t'auras toujours la possibilité sur ton App Store Cloud de sélectionner les MCP serveurs que tu veux toujours avoir avec toi dans tes conversations mais t'auras aussi des conversations que tu vas initier avec un chat GPT ou avec un autre agent dont tu vas parler d'un sujet pour lequel pour répondre pertinemment à ta demande ça serait pas, plutôt efficient de ramener un MCP serveur et sur lequel on pense qu'un chat GPT va venir faire une requête de bidding à ceux qui aimeraient présenter leur MCP comme étant une solution à cette conversation là, donc voilà l'extrait pour savoir si oui ou non tu veux effectivement bider là dessus et, que du coup si tu bides le plus haut, chat GPT prenne ton MCP serveur et l'insère automatiquement dans la conversation ou laisse le choix à l'utilisateur parmi un, deux ou trois des serveurs qui ont bidé le plus fort pour pouvoir être présent dans la conversation et être ajouté à la conversation. Mais exactement ce qu'on va voir avec les liens sponsorisés qui existent sur une recherche Google.

Bruno:
Je pense qu'effectivement, on n'a pas de souci à se faire sur la capacité de ces entreprises à trouver des moyens de monétiser ce trafic qu'ils vont générer.

Frederic:
Mais ça va aussi faire du bien à la discovery. Là, aujourd'hui, si je regarde à Té, l'expérience, elle est clunky pour des gens qui ne sont pas tech pour aller rajouter un MCP serveur. Ça va mieux, mais même sur un cloud AI, tu dois quand même aller dans les settings pour venir rajouter une URL que t'as copiée-collée depuis la doc de la plateforme que tu veux connecter et c'est pas un geste naturel pour le commun des mortels ça, du coup ça reste une population, assez faible qui va être capable d'utiliser ces solutions là le but du jeu c'est de la démocratiser et pour la démocratiser l'App Store ou la régie c'est un peu les deux grands mécanismes de discovery qui existent. Après je demande à être surpris peut-être qu'un Anthropik ou un Open AI vont me donner tort et vont trouver un autre moyen de générer de la discovery pour ces serveurs-là.

Bruno:
Il y a quand même un sujet qui me... J'ai deux questions qui te retent en tête. La première, c'est que, le MCP serveur, c'est que du coup, ton agent peut communiquer avec le... Un agent peut communiquer avec un serveur MCP. Donc déjà, ce que j'ai appris en préparation avec toi, c'est que côté MCP serveur, je n'ai pas forcément un agent. Je n'ai pas forcément de l'IA. C'est-à-dire que ça peut être simplement comme un API Gateway qui va aller consommer mes différents endpoints dans un ordre spécifique comme il veut, mais donc si c'est pour qu'un agent communique avec mon serveur au final l'agent il peut le faire entre guillemets sans que je le demande c'est à dire que je peux lui demander achète moi un vol Paris-Marseille, et il va pouvoir faire un ensemble de choix sans me consulter au moindre moment en se basant sur des informations qu'il a déjà sur moi dans d'autres conversations ou je ne sais quoi. Mais ça veut dire que... Comment on peut faire pour doser le niveau de contrôle qu'on a là-dessus ? Parce qu'au final, l'agent, il peut tout faire tout seul.

Frederic:
Ils pouvaient même potentiellement faire tout tout seul avant l'arrivée d'MCP avec une recherche sur le web. C'était un truc hautement inefficient, d'ailleurs c'est une petite aparté avant de répondre à ta question. La toute première idée sur laquelle on a commencé à travailler avec Alpic, c'était une transformation des sites web pour les rendre vraiment bare-bone minimale et que ce soit ce contenu-là HTML qui soit donné à l'agent pour qu'il puisse dépatouiller sur le site sans toute la pollution du contenu pour du SEO ou qui n'a aucun impact sur ses navigations. Et c'est assez marrant on s'amusait à transformer notamment le site d'Air France, sur lequel un opérateur n'arrivait pas du tout à faire la navigation et le check-out sur un vol Paris-New York, et en enlevant énormément d'assets on arrivait à avoir des résultats beaucoup conséquents mais c'est à ce moment là où MCP est sorti et on s'est dit c'est beaucoup plus efficient de penser, une interface pour les besoins d'un agent dès le début dès la conception plutôt que de transformer un truc qui était prévu pour des humains et de le formater pour essayer de le faire re-rentrer dans un rond ou ce qu'attend un agent de cette interface-là. Donc ça, c'est juste la petite aparté. Et comment tu disais, satisfaire en réponse à la demande d'un utilisateur avec un MCP server la variabilité des use cases que tu peux avoir, en vrai, tu peux fournir quand même à ton serveur beaucoup d'options de configuration. Je vais reprendre par exemple les vols dont tu parlais. Le fait que tu veuilles voyager avec un enfant en bas âge, ça peut être une option dans le tool que tu mets à disposition via ton MCP serveur pour l'agent. À lui de décider si du contexte de conversation qu'il a avec toi, c'est intéressant de remplir un en face de combien de passagers enfants sont à check-in pour ce vol-là. Et dans ce cas-là, laisser vraiment la responsabilité au modèle d'avec toute l'interface que tu lui mets à disposition, quelles sont les informations importantes qu'il doit te fournir. Le truc qui est important quand tu fais ça, c'est de rendre toutes les informations que tu demandes optionnelles. Typiquement pour reprendre le cas du vol, le seul truc que tu vas demander réellement c'est l'aéroport de départ ou la ville de départ, la ville d'arrivée et la date du voyage. Au mieux la date du retour si c'est un aller-retour mais c'est vraiment que ces trucs là dont tu as besoin. Tout le reste, tu peux faire des hypothèses sur ce qui est le meilleur scénario à proposer, n'ayant pas l'information. Par contre, toutes les infos supplémentaires qui auraient un impact sur ce parcours utilisateur-là, tu peux les proposer comme des paramètres optionnels dans l'interface de l'outil que tu mets à disposition. Et au modèle de choisir si oui ou non il veut renseigner une valeur pour ce truc-là, avec la consigne que tu lui as donnée, pour que tu puisses lui fournir exactement le booking dont tu as besoin.

Bruno:
— Mais donc, on laisse le choix au modèle de me poser la question ou pas si je voyage avec un enfant. Parce que si je prends l'exemple du voyage, potentiellement, je ne voyage pas toujours avec mes enfants. Ou même, potentiellement, un cas encore plus extrême, ce serait que j'ai eu une conversation avec mon agent pour parler de l'enfant de mon meilleur pote à qui je veux faire un cadeau pour la naissance ou je ne sais quoi. Et l'agent peut croire, enfin avoir mal compris qu'en fait c'est mon enfant et sur ma prochaine réservation il me book est-ce que toi côté MCP tu peux imposer au modèle en fait de poser la question à l'utilisateur ?

Frederic:
Ouais tu peux tout à fait alors c'est assez récent, ça date de la version de juin il y a eu trois releases sur MCP grosso modo la première initiale en novembre, une deuxième fin mars et une dernière en juin la dernière release de juin a introduit une nouvelle fonctionnalité qui s'appelle l'hélicitation, et qui permet à n'importe quel moment au serveur de solliciter via un élément d'interface visuelle auprès de l'utilisateur une information complémentaire. Donc grosso modo, au moment où toi tu reçois de la part du modèle une requête pour pouvoir réserver un vol Paris-New York, tu peux plutôt que de présupposer que la personne voyage seule, demander en tant que serveur au client de demander à l'utilisateur qui est derrière s'il voyage seul ou s'il voyage accompagné de son enfant. Et ce que tu peux faire qui va commencer à aller un petit peu loin c'est. Imaginer des expériences il y a aujourd'hui dans l'aspect de MCP une partie authentifiée qui permet du coup à un client de dialoguer avec un serveur au nom d'un utilisateur authentifié donc en plus moi en tant que compagnie aérienne j'ai peut-être ton historique de voyage et je peux venir te poser cette question alors que même que ton modèle est pas au courant que t'as déjà fait une dizaine de voyages avec ton enfant simplement parce qu'en tant que Air France ou n'importe quelle compagnie aérienne j'ai cette information sur toi je sais quel est ton loyal petit programme etc et c'est des comportements qu'on retrouvait déjà dans un front quand moi en tant qu'utilisateur j'allais booker mes billets sur le site d'une compagnie aérienne mais que tu peux retranscrire du coup en MCP, Alors que c'est ChatGPT qui est en train de te demander ça. Tu ne vois plus la marque qui est en train de te demander ça. C'est elle qui fait ça pour toi.

Bruno:
Donc ça veut dire qu'on peut trouver... Je ne sais pas si ça existe encore de manière fluide, mais en gros, tu peux avoir un login password à saisir dans une conversation, avec ton ChatGPT pour t'authentifier sur le portail d'Air France pour que ton ChatGPT fasse les réservations de billets à ta place.

Frederic:
Ne jamais mettre son login et son mot de passe dans une conversation avec ChatGPT. ce que t'évoquais.

Bruno:
Tout à l'heure c'est qu'en fait tu peux pousser un élément enfin je schématise en disant un élément HTML du coup tu peux tu peux pousser un formulaire qui serait un formulaire de login mot de passe.

Frederic:
Pour le coup toute la partie authentifiée dont je te parle elle est construite sur Auth qui est un standard d'authentification qui prédate MCP aussi, et du coup le login que tu vas avoir c'est typiquement celui que tu vois quand tu fais un Facebook Connect exactement, ou un sign in with Google etc Et du coup, tu vas avoir l'application, donc ChatGPT ou Cloud, qui va, vu qu'elle reçoit une 401 du serveur MCP, initier un flux d'authentification au hôte en ouvrant une fenêtre de navigateur pour te demander de t'authentifier. Mais tu seras en train de t'authentifier sur la plateforme auquel tu as l'habitude de t'authentifier. Pas du tout un truc brandé ChatGPT ou Cloud.

Bruno:
Et puis, tu sais à quoi tu donnes l'accès parce qu'en général, les effets...

Frederic:
Tu vois les scopes que tu vas lui donner et c'est ça qui va gouverner ce que du coup le serveur MCP pourra faire en tombant suite à la demande de l'agent ça. En fait le truc qui a été vraiment cool dans MCP et qui je pense a contribué à ce que le standard gagne en traction au delà de ce qui existait déjà avec function calling ou avec le fait qu'un modèle soit capable de lire une spec open API et d'utiliser une API derrière c'est, en plus d'avoir des problématiques, liées au fait de développer un truc spécifiquement pour des agents et du coup de faire en sorte qu'il soit facilement utilisable pour eux. Le fait de pouvoir enrichir l'expérience au-delà de juste le modèle. Donc on parlait de tools et d'hélicitations comme étant des fonctionnalités qui font partie du standard MCP pour les tools permettre à un modèle de sélectionner des actions qu'il veut faire sur un software et les licitations permettent à un serveur de récolter des informations supplémentaires. Tu as aussi d'autres fonctionnalités du protocole comme ressources et prompt qui sont des fonctionnalités qui sont à destination de l'utilisateur derrière l'agent et de l'application dans laquelle l'agent est packagé mais pour lesquels le modèle est plus impliqué dans la fonctionnalité en elle-même. Par exemple, les ressources, pour faire un exemple qui va parler à la communauté dev qui nous écoute, quand tu es sur un cursor et que tu ouvres une fenêtre de conversation sur cursor alors que tu es en train de regarder un fichier, dans ta conversation cursor, Il te marque en haut de la conversation qu'il y a le fichier que tu es en train de regarder qui est inclus dans le contexte de la conversation. Ce comportement-là, c'est celui qu'on retrouve pour une ressource MCP, où en fait, la ressource, c'est un moyen pour l'application de rajouter du contexte supplémentaire qui vient du serveur à l'initiative de l'application ou de l'utilisateur qui, avec un hat, rajoute un fichier bien particulier pour cette conversation. Mais du coup, tu redonnes le contrôle d'inclure un morceau de contexte qui vient du MCP serveur sans que ça soit à l'initiative du modèle. C'est à l'initiative de l'application, parce que tu as ouvert la fenêtre sur un fichier en particulier ou de l'utilisateur parce que tu as appuyé sur at pour ajouter un truc donc en fait il y a eu une complémentarité plutôt que de dire on va faire un protocole qui repose à 100% sur ce que le modèle est capable de faire on se rend compte que pour la plupart de nos use cases ça serait quand même encore vachement efficient de redemander de temps en temps à l'humain qui est derrière de refaire quelque chose et du coup les ressources et les promptes pour deux raisons différentes ce sont quand même des éléments du protocole qui sont très importants et qui ne sont pas à la destination du modèle, que les gens ont tendance un peu à mettre de côté parce que le truc impressionnant, c'est les tools et je veux voir mon modèle interagir avec toutes les fonctionnalités que je propose avec mon software et qu'il puisse les utiliser très bien. Ressources et prompt sont deux parties du protocole qui sont vachement importantes, et qui permettent de leur donner un peu de contrôle à l'application, donc à ce que ChatGPT ou Cloud peuvent proposer nativement ou à l'humain qui est derrière à travers ces fonctionnalités-là.

Bruno:
Alors attends, je ne suis pas sûr d'avoir bien compris ces ressources est prompt, c'est un élément qui est généré par le MCP serveur qui est renvoyé à l'agent.

Frederic:
À l'application. Ce que j'appelle application, c'est vraiment le processus de chat GPT ou de cloud qui va faire le lien justement entre j'ai une communication HTTP avec ton serveur MCP, puisque c'est de l'HTTP, j'ai une UI à afficher sur un écran et j'ai effectivement à certains moments des complétions à faire avec un modèle. Mais au centre de tout ça, il y a une appli, il y a un thread, il y a un processus qui tourne. Et ce qu'on appelle application dans le standard MCP, c'est vraiment ce thread qui orchestre justement l'interface utilisateur les appels au modèle et les appels au serveur MCP pour pouvoir récupérer du contexte supplémentaire.

Bruno:
Parce que du coup cette ressource que t'évoquais dans le cas de Cursor ça ajoute du contexte dans ton modèle pour qu'il réponde c'est à dire que si on prend un exemple, plus ou moins similaire en fait ce serait ton MCP serveur qui va générer du contexte qui renvoie au...

Frederic:
Il peut générer du contenu et le proposer à l'application, mais tant que t'as pas initié ta conversation avec ton modèle, le modèle a pas connaissance de ce contenu-là. Donc, quand toi t'appuies sur la touche « at » pour rajouter un fichier dans ton contexte de conversation avec Cursor, jusqu'à ce que t'aies fini de taper ton prompt, le contenu du fichier est pas envoyé à Cursor. Tu vois ce que je veux dire ? Alors que les tools, typiquement, qui sont exposés par ton serveur, dès le début de la conversation, ils sont injectés dans le contexte, sans que toi, en tant qu'utilisateur, tu sois conscient que t'es en train de les injecter dans le contexte. Donc le contrôle il est vraiment ça va finir par arriver au modèle à un moment ou à un autre parce que c'est ça qui est intéressant dans l'équation mais le contrôle sur à quel moment ça revient dans le modèle, à quel moment c'est injecté dans le contexte du modèle, il est redonné à l'application et à l'utilisateur qui est derrière.

Bruno:
Et c'est quoi du coup la distinction entre cette ressource et ce prompt ?

Frederic:
Alors ressource c'est vraiment cette image l'image la plus proche c'est celle de la pièce jointe c'est là en tant qu'utilisateur je veux rajouter une pièce jointe mais une pièce jointe qui est fournie par le MCP serveur, donc typiquement ta pièce jointe dans une conversation avec ton modèle, ça peut être, le vol précédent que tu as fait en lui disant « Reboote-moi ce même vol l'année prochaine pour moi et mon fils ». Parce qu'en fait, la ressource, le vol que j'ai fait, c'est une ressource exposée par le MCP serveur qui contient la description de ton vol et que tu injectes. Donc, c'est vraiment mis à disposition par le serveur. Tu peux avoir des ressources qui sont...

Bruno:
Donc, ça, ça veut dire que moi, mon serveur MCP, il doit quand même comprendre le concept de ce même vol.

Frederic:
Ton serveur MCP, il doit mettre à disposition les ressources qui sont pertinentes pour un usage dans une application.

Bruno:
Ça mettrait par exemple mon historique de vol avec la compagnie à dispo au MCP ou mon agent. Qui du coup après peut comprendre là-dedans ce qu'est le même bol.

Frederic:
Tout à fait, exactement. Mais ça peut être si t'es un CRM, ça peut être des fiches utilisateurs, des fiches clients. Si t'es un software de base de données comme Superbase, ça peut être les schémas de tes tables dans ta DB pour que ton utilisateur puisse poser une question sur le contexte, le contexte étant cette table spécifiquement qu'il a sélectionnée sur l'interface pour dire explique-moi pourquoi cette colonne-là.

Bruno:
Ah super intéressant.

Frederic:
Donc ça c'est les ressources. Et les promptes, c'est encore un niveau supplémentaire, c'est un peu l'équivalent de la slash commande sur Slack. Où c'est un peu la cristallisation de ce qu'il y avait comme mode il y a un an, un an et demi, où il y avait plein de gens sur Internet qui broadcastaient leurs dix promptes géniaux qui permettaient de faire exactement ce que tu veux faire dans tel ou tel cas. Sauf que ce coup-ci, tu redonnes au serveur la responsabilité de te donner un prompt qui est la meilleure façon d'utiliser ce qu'il a à disposition, à mettre à disposition pour l'utilisateur. Donc un prompt contrairement à une ressource c'est tout un début de conversation déjà écrit dans lequel tu peux avoir des trous, des placeholders donc au moment où tu sélectionnes un prompt à faire, genre je veux utiliser le prompt booker un vol, il y a une interface utilisateur qui s'ouvre côté application te demandant de remplir les paramètres qui sont paramétrisables une fois de plus c'est le serveur qui contrôle qu'est-ce que c'est ces paramètres là à demander à l'utilisateur et ça te génère tout le début de conversation qui est envoyé au modèle et du coup il reprend la conversation à partir de ce moment là mais du coup tu lui as déjà. Un des tout premiers serveurs que j'ai développé c'était un serveur pour t'aider à faire du contenu sur LinkedIn et une façon de cristalliser dans le serveur la meilleure façon de faire un post LinkedIn c'était des consignes assez, standards et qui sont les mêmes pour tout le monde et aussi des choses un peu particulières comme la longueur moyenne des posts que tu as l'habitude de faire qui est du contenu spécifique à toi et que le serveur MCP injecte dans le contenu du prompt au moment où toi, tu lui demandes en tant qu'utilisateur parce qu'il a accès à tes posts LinkedIn et du coup, il peut crafter un prompt sur mesure pour l'utilisateur qui lui demande aide-moi à écrire un post sur le dernier topic de IfTDT.

Bruno:
Ce qui veut dire que... Attends, ce qui est intéressant, c'est que ton serveur MCP, si je reprends l'exemple que tu décris, c'est que je peux avoir en fait un serveur MCP qui va... D'une certaine manière, ajouter de l'intelligence à mon modèle, pas uniquement en proposant un service genre booker un vol, mais par exemple comment devenir un bon expert comptable parce que du coup tu lui injectes un bon prompt d'expert comptable et du coup il sait de poser les bonnes questions et d'initier une meilleure conversation.

Frederic:
Avec ton agent un des usages de prompt qu'on fait pour des serveurs MCP, pour une équipe de dev c'était de cristalliser les bonnes questions à se poser au moment de développer une nouvelle feature et plutôt que de le faire avec un prompt qui demande à tout le monde de copier-coller, ils ont fait un serveur MCP interne pour leur équipe et dans ce serveur MCP il y a un prompt qui est. Le create issue parce que grosso modo l'output de ça ça va être créer une issue sur linéaire et ce que fait ce prompt là c'est de dire toutes les étapes qui vont être nécessaires au craft d'un bon ticket avec l'ensemble des features dont il y a besoin et du coup de tasquer le modèle avec les bonnes questions à poser jusqu'à obtenir la réponse à toutes ces questions-là et à la fin d'utiliser le tool qui est fourni par le MCP serveur de linéaire pour aller créer l'issue qui va dessus. Mais du coup tout ce que ça a demandé à l'utilisateur c'était de savoir que c'était slash create issue qu'il fallait taper pour commencer sa conversation avec son modèle plutôt que de savoir que, pour faire une bonne task technique je sais qu'il faut que je demande à Claude ou à Cursor de crafter un fichier markdown dans lequel il va me détailler les étapes qu'il veut faire pour que je puisse travailler avec lui dessus, parce que lui demander directement d'implémenter le truc ça marche pas au Whisper au bout d'un moment donc tu peux vraiment côté serveur, cristalliser la meilleure façon de faire la tâche qui t'incombe et côté application une des bonnes façons de le représenter c'est quand t'arrives pour la première fois sur l'application de te proposer ces prompts tout près pour faire des tâches spécifiques qui sont les exemples que tu vois d'habitude quand t'arrives sur un chat GPT ou sur un cloud de comment tu peux m'utiliser en fait, les prompts qui sont exposés par des serveurs c'est comment tu peux m'utiliser.

Bruno:
Avant de creuser la partie de comment est-ce qu'on peut designer un service, un MCP-server, dans cette approche de ces nouvelles interfaces pour un nouveau type d'acteurs, je rebondis sur le terme que tu as utilisé, tu as parlé de cristalliser, la meilleure façon de faire. Ce qui paraissait, révolutionnaire et game changer sur tous ces, IA qui pop de tous les côtés depuis quelques temps, c'est que en fait, ils sont justement pas contraints par notre manière de penser et qu'en fait ils approchent les choses de manière parfois très holistique est-ce que justement en cristallisant notre façon, de mécaniquement faire les choses, est-ce qu'on ne les prive pas de ce que, justement, il pourrait apporter à notre manière de faire ?

Frederic:
Ouais, je vois ce que tu veux dire. Est-ce qu'on se tire pas une balle dans le pied en lui donnant trop d'infos sur comment il faudrait faire ? Peut-être qu'il s'en serait très bien sorti sans qu'on lui donne tous ces consignes-là.

Bruno:
Peut-être qu'il nous aurait proposé une autre manière de faire qui est en fait meilleure que celle qu'on a envisagée jusque-là.

Frederic:
C'est vrai. Après, il faut aussi faire confiance aux gens qui développent des serveurs MCP pour que l'effort qu'ils aient mis dans le fait de crafter un prompt, ça soit découlant d'une étude que eux-mêmes ont menée de savoir qu'est-ce qui marchait le mieux après avoir fait des essais sans prompt justement. Et peut-être qu'ils se sont rendus compte que tel modèle d'anthropique avait réussi à trouver une solution originale à laquelle ils n'avaient pas pensé, mais que les autres modèles avec lesquels ils bossent n'y pensent pas spontanément et du coup ça vaut le coup d'aller cristalliser cet apprentissage-là dans un prompt pour que tous les modèles en bénéficient tout d'un coup. Mais cet effort-là, il a été fait intellectuellement par les équipes qui sont derrière le développement du MCP Server en question et du coup il y a une petite dose de confiance à leur donner sur le fait qu'ils ont crafté un truc qui découle d'un apprentissage que eux-mêmes ont généré à l'utilisation des modèles au quotidien pour leurs solutions spécifiques et que du coup cette cristallisation apporte une valeur ajoutée par rapport au modèle, blanc, quoi, sans consigne particulière.

Bruno:
Donc, t'évoquais que les serveurs MCP, c'est un nouveau moyen de consommer les différents services et applications qu'on peut créer. On a aujourd'hui déjà des gens qui sont très compétents sur la création de nos pages web, de nos parcours utilisateurs, de comment est-ce que nos API fonctionnent pour nos populations de développeurs. Comment est-ce qu'on peut construire un parcours justement des, LLM qui sont non déterministes, qui fonctionnent de manière très approximative, qui changent de manière aussi extrêmement rapide. Comment on fait pour concevoir des services qui soient consommés par des choses qui soient aussi abstraites que ça ?

Frederic:
Changeantes. La partie que tu mentionnes, qu'on appelle l'évaluation, elle est très importante dans un serveur MCP. Elle prédate aussi MCP, dès l'apparition des premiers modèles. Il y a eu pas mal de boîtes qui sont nées, qui ont proposé des services d'évaluation pour que le prompt système que tu proposes dans ton chatbot, il soit le plus optimal possible pour garantir que à aucun moment ta conversation, elle parte dans une direction que tu n'avais pas prévue. Cette problématique d'évaluation, où tu veux vérifier que ton serveur MCP, avec les fonctionnalités qu'il apporte, il soit contrôlé dans plein de contextes et de conditions différentes, c'est une problématique d'évaluation et c'est une problématique sur laquelle ça vaut le coup de s'intéresser in fine les descriptions de tes tools les contenus de tes prompts les contenus de tes ressources c'est autant de tokens qui vont se retrouver dans le contexte Windows d'un modèle pour lequel tu veux avoir un petit peu de prédictabilité sur ce qui va se passer derrière, de la même façon que pour du développement web traditionnel des métriques à disposition pour savoir si tu fais un bon travail de développement t'as des mêmes métriques qui existent côté MCP pour savoir si le serveur que tu développes il est performant en l'occurrence la métrique qu'on regarde le plus c'est la task completion rate donc à quel point un modèle est capable d'arriver au bout de la tâche confiée par un utilisateur grâce aux fonctionnalités qui sont disponibles dans ton MCP serveur. Mais cette task completion rate est difficile à mesurer en production et du coup on se sert de métriques proxy qui sont des bons indicateurs de si tu l'améliores, tu vas in fine améliorer ton task completion rate et ces mesures proxy, il y en a quatre à peu près qu'on utilise certaines que tu vas évaluer dans des environnements contrôlés avec des benches qui vont te permettre de, essayer de prédire à quel point elles sont affectées par telle ou telle modification que tu fais à ton serveur et d'autres qui sont mesurables en production et du coup que tu peux voir évoluer in situ en fonction de ce que les utilisateurs font vraiment avec ton serveur, Les deux qui sont dans des environnements plutôt benchés, pas en production, ça va être la Tool Selection Accuracy. Donc à quel point un modèle pour une tâche donnée micro sélectionne le bon outil parmi les tools qui sont à disposition sur ton serveur. Et la Parameter Accuracy, qui est à quel point pour un tool donné, il l'appelle avec le paramètre auquel tu t'attendais à ce qu'il soit appelé. Donc les bons paramètres et les bonnes valeurs pour ces paramètres-là. Ça c'est des trucs que tu vas mesurer et évaluer dans des conditions contrôlées donc grosso modo tu vas dire moi je développe un MCP serveur pour réserver des billets d'avion, je sais que j'ai envie de maximiser ma satisfaction utilisateur sur ces 10 modèles là qui sont ceux qui représentent 95% de ce qui va se balader dans la nature en termes d'agents. Et voilà les cas standards que j'aimerais pouvoir contrôler donc Intel qui me dit qu'il veut faire un Paris New York le 25 juillet, et en fait je me rends compte qu'avec ce prompt là, sur ce modèle là le tool est appelé book flight avec le 25 juillet 2024 et pas 2025 et c'est en fait parce que ce modèle là il n'a pas dans son contexte où sa cut of date elle date de 2024 et du coup il lui manque un élément de contexte pour savoir que c'est en 2025 bah ce test là que je fais sur un bench où je contrôle le modèle, le prompt initial et un outil pour mesurer que c'est bien le bon tool qui a été appelé avec le bon paramètre, va me permettre de détecter ce problème-là et de corriger le tir potentiellement en mettant dans la description de mon outil la date actuelle au moment où cet outil a été...

Bruno:
Ou d'ajouter une sollicitation pour que du coup la question...

Frederic:
Pour que tu puisses préciser si c'est cette année ou l'année prochaine que tu vas faire le vol en question, quoi. Donc ça c'est la partie contrôlée où tu vas du coup pouvoir sur plein de scénarios différents, sur plein de modèles différents, vérifier que le tool qui est appelé et les paramètres qui sont fournis pour ton serveur sont les bons et à chaque fois que tu fais une modif tu peux vérifier si ça a dégradé les performances du coup sur certains des scénarios que tu as envisagés, et aussi au fur et à mesure qu'en production tu as des problèmes qui arrivent tu peux rajouter ces 4 tests là dans ta matrice de test et ça ressemble à une CICD en vrai ça veut dire que chaque fois que tu fais une modification sur ton serveur tu vas rejouer avec des tests automatisés les différents scénarios que tu as proposés, la seule différence par rapport à des tests unitaires ou des tests end-to-end sur un système déterministe c'est que là ça va être statistique, plutôt que de faire un test sur le modèle avec le prompt que tu as donné, tu vas le faire 10 ou 15 fois ou 100 fois en parallèle et tu vas vérifier si ton taux de succès il a été drastiquement impacté négativement ce qui te permet de détecter une régression sur ce que tu es en train d'introduire donc ça c'est la première partie, et la deuxième partie.

Bruno:
De ce que tu me jures juste sur cette première partie parce que, déjà on le note quand même il y a une certaine latence quand je communique avec, un chat GPT ou un LLM il y a une certaine latence, il répond pas de suite, ça veut dire qu'à chaque fois que je dev que j'ai fini de coder ma petite fonction ou mon petit truc c'est quoi le temps de ma feedback loop c'est à dire que, tu te dis que c'est comme une CI mais en fait je dois attendre 15 minutes à chaque motif pour voir un peu le résultat.

Frederic:
Ça dépend de la quantité bien sûr de cas que.

Bruno:
Tu veux tester.

Frederic:
Et la quantité de modèles en parallèle sur lesquels tu veux les tester.

Bruno:
Sans compter le coût que ça représente du coût aussi exactement.

Frederic:
Là t'es bon pour plusieurs milliers de tokens qui sont ingérés souvent c'est plutôt le coût en dollars que le coût en temps parce que c'est des parallélismes, enfin tu vas pouvoir faire beaucoup de parallélisation sur ces tests là il n'y a pas de state à maintenir entre tes différents tests donc ils sont vraiment complètement indépendants et si tantôt que tu as 100 endpoints d'inférence à disposition tu peux venir faire 100 chat completion en parallèle pour résoudre 100 tests en parallèle mais ça va te coûter 100 balles c'est plus ce coût là qui va être un élément d'arbitrage pour savoir la quantité de tests que tu gardes dans ton bench ou la quantité de modèles sur lequel tu veux tester ton bench mais de la même façon que si tu fais tourner si tu t'appelles Doctolib et que tu fais tourner tes 7 millions de tests unitaires à chaque déploiement ça va te coûter en GPU, en CPU, un bras quoi donc c'est eux qui m'avaient parlé de leur longue, longue, longue CI à un moment et, c'est du coup des arbitrages que tu fais sur ta CI CD de dire c'est quoi le compromis que je fais entre la garantie que j'ai pas de drop de qualité et le temps ou le coût associé d'exécution de ces tests là.

Bruno:
Donc ça c'était pour.

Frederic:
La partie contrôle la deuxième partie qui est vraiment une partie que tu peux mesurer en production qui sont les deux autres métriques qu'on regarde pour avoir un proxy sur la task completion rate qui sont en fait ce qu'on appelle la latence mais plutôt que de considérer une latence en seconde qui est plutôt une quantité d'interaction que tu vas avoir donc à quel point un modèle il a besoin de faire des allers-retours avec ton serveur pour arriver au même résultat plus il a d'interactions, plus tu as un risque qui se plante sur l'une d'entre elles et du coup plus tu as un impact négatif sur ta task completion rate donc on va regarder très près grâce à un session ID dans le protocole MCP, tu as une session qui te permet de. Au moins avoir un contenant de... Je sais que c'est une personne en particulier qui est en train de dialoguer avec moi via son client. Ce n'est pas isolé à une conversation spécifique, mais c'est déjà un premier proxy plus simple que juste c'est le back-end anthropique qui est en train de me taper et du coup, je ne sais pas du tout parmi toutes les conversations lesquelles sont corrélées. On s'en sert comme correlation ID dans les conversations et ça nous permet d'avoir un proxy sur combien il y a d'aller-retour avant que l'utilisateur soit satisfait par ce que le modèle a fait pour lui. Donc ça c'est la première métrique et la deuxième c'est le coût mais une fois de plus le coût pas trop en dollars mais plutôt en tokens qui sont retournés parce qu'en tant que développeur de serveur MCP tu ne portes pas le coût des tokens qui sont utilisés par le client. Par contre tout ce que tu retournes que ce soit dans la liste des tools que tu retournes quand ton serveur est contacté pour la première fois pour savoir ce qu'il est possible de faire avec toi ou quand un tool est exécuté et que tu retournes du coup un résultat qu'il soit successful ou en erreur, tout ce que tu retournes comme texte, comme JSON etc et du contenu qui va venir manger de la contexte window sur le modèle de l'agent qui t'utilise et du coup ça a un coût sur cette contexte window là, pour ton client qui du coup lui va réellement payer les tokens en question mais aussi ça va manger de l'espace disponible de ce contexte et du coup potentiellement c'est de l'espace que tu aurais voulu garder pour une autre partie de la conversation donc ça a, impact sur la capacité du modèle à mener à bien sa tâche parce que si tu remplis sa contexte Windows avec plein d'infos dont il n'a pas besoin, il va être obligé de sortir de sa contexte Windows des éléments dont il aurait eu besoin pour aller au bout de la tâche.

Bruno:
Est-ce qu'on prend en compte parce qu'on est d'accord que quand tu as une conversation, on va dire, avec 10 aller-retours entre le modèle et ton serveur, potentiellement il y en a 5 où ça a été une question posée par l'utilisateur, et 5 allers-retours qui sont de l'initiative directe du modèle. Est-ce que tu mesures ça aussi avec une volonté d'avoir un ratio plutôt dans un sens ou dans l'autre ? Est-ce qu'il y a une volonté d'aller plutôt vers maximum, on évite que ce soit l'agent qui prenne des décisions ou au contraire, on veut que ce soit l'agent qui prenne le plus de décisions à la place du utilisateur pour lui faciliter la vie à l'utilisateur ?

Frederic:
C'est difficile à postériori de savoir si c'était l'utilisateur qui a dit « appelle ce tool avec tel paramètre ou si c'est l'agent qui a fini par arriver à cette conclusion-là dans la discussion parce qu'en tant que serveur, pas accès à la conversation sous-jacente, donc t'as pas accès à qu'est-ce qui a initialement déclenché cette interaction. Pour ça, il faudrait que tu maîtrises toute la chaîne de valeur et je pense qu'il y a des beaux outils d'observabilité qui vont naître du côté des clients pour que justement tu puisses avoir un peu plus d'instrumentation sur, est-ce que ce tool call-là qui a été fait par le client à mon serveur suite à cette conversation-là, il était effectivement pertinent. Mais en tout cas, juste côté serveur, t'as pas cette visibilité-là. Donc on va plutôt le regarder dans l'autre sens, c'est-à-dire qu'on va développer des tools qui sont spécifiquement faits pour être utilisés par l'agent sans input utilisateur et des tools qui sont faits pour que ça vienne quand même d'une volonté utilisateur initialement et un exemple que je peux te donner c'est sur tous les serveurs qu'on développe on fait toujours un tool supplémentaire qui est un tool de feedback qui permet au modèle spontanément de donner du feedback sur la façon dont la conversation s'est déroulée et si son utilisateur a l'air content par les résultats du serveur ou pas et en fait t'as le modèle si tant est qu'il est en YOLO mode, ce qu'on appelle le YOLO mode c'est la capacité de l'agent à appeler des tools sans forcément demander à chaque fois l'accord de l'utilisateur pour pouvoir le faire on voit souvent des feedbacks qui nous remontent grâce à cette interface là puisque le modèle va prendre, l'initiative de nous donner du feedback sur oui ça va marcher ou non ça va pas marcher pour cet utilisateur et voilà la raison pour laquelle ça va pas marcher.

Bruno:
Donc ça veut dire que t'as chat GPT qui te dit.

Frederic:
Qui explique des informations qui te dit.

Bruno:
Ton serveur est bien construit ou pas.

Frederic:
Alors il me compare pas par rapport à d'autres serveurs qui ont été construits mais en tout cas il est capable de donner du feedback sur un problème qu'a rencontré l'utilisateur à l'utilisation du serveur Ok.

Bruno:
Je trouve ça assez fou comme.

Frederic:
Concept ça a été détourné de, en fait MCP est arrivé avec son lot de vecteurs d'attaque supplémentaires puisqu'une fois de plus du coup tu as la possibilité pour des acteurs tiers d'injecter des tokens dans une contexte Windows donc forcément il est possible de faire des choses mal intentionnées, mais si tu détournes ces éléments là mal intentionnés qui sont par exemple d'essayer d'exfiltrer des informations de la conversation en te faisant passer pour un tool légitime et que tu fais quelque chose de légitime comme récupérer du feedback, bah t'as du feedback qui est pertinent puisque ce typologie d'attaque là marche bien effectivement.

Bruno:
C'est quoi le donc j'entends que c'est très récent comme techno donc il y a déjà eu 3 updates majeurs c'est ça que tu disais depuis novembre, c'est quoi pour toi la suite que tu vois sur MCP alors je me doute que tu peux pas me faire une projection à.

Frederic:
3 ans ça serait un peu risqué mais qu'est-ce que tu vois.

Bruno:
Toi comme perspective sur ces sujets là.

Frederic:
Les sujets dont je te parlais de discovery sont pour moi les gros sujets chauds du moment pour sortir de cette bulle justement utilisateur tech savvy uniquement pour aller sur du grand public c'est là où je pense on va vraiment passer la seconde sur l'avancée du protocole, mais du coup j'en parlais tout à l'heure j'attends de voir un peu qu'est-ce qui va être les gros mouvements des gros fournisseurs de modèles de ce monde que sont OpenAI Anthropik et Gemini etc qui ont tous annoncé le support de la techno mais sur lequel ces mécanismes de discovery ne sont pas tous implémentés ou pas tous encore existants, du coup à voir ce qui va se monter Discovery, App Store, Marketplace, Régie Publicitaire j'attends de voir un peu à quelle sauce on va être mangé, côté du protocole lui-même, ce qui est dans les cartons et ce qui est en discussion en tout cas au sein de la communauté, puisque le protocole a beau avoir été créé par Justin et David, qui sont deux employés d'Enthropic, ce protocole arrive petit à petit sous contrôle d'un comité neutre pour sortir d'Enthropic. Ce qui a aussi aidé à sa popularisation, c'est que ce ne soit plus uniquement un produit Enthropic, ce qui n'aurait pas aidé pour que OpenAI l'incorpore ou que Gemini l'incorpore. Et du coup les conversations sont complètement publiques sur les évolutions du protocole les grosses conversations qu'il y a pas mal aujourd'hui une qui je trouve assez intéressante c'est toutes les fonctionnalités dont je t'ai parlé elles sont purement à la discrétion d'implémentation de l'application donc par exemple la façon dont une application décide de représenter une ressource mis à disposition par un serveur ou un prompt mis à disposition par un serveur est purement au choix du développeur de l'application aujourd'hui on voit beaucoup de demandes dans l'écosystème de développeurs de serveurs de gagner un petit peu de contrôle sur l'interface qui est présentée à l'utilisateur notamment en B2C pour des problématiques de présence de marque et en B2B pour proposer des expériences qui sont plus sympas que juste du texte et sur lesquelles tu as un peu de contrôle, le gros moyen de réussir à faire ça aujourd'hui sans réellement avoir la feature à disposition c'est en allant. Solliciter un cloud ou un chat GPT pour faire un artefact ou un canva je crois qu'ils appellent ça sur chat GPT donc tu sais qu'il y a un bout du high qui est généré à la volée par le modèle, en écrivant du React souvent ou même de l'HTML pur avec un peu de JS, en fait dans tes réponses de tool tu peux lui dire voilà les trois vols disponibles plutôt que de les lister sous forme de bullet point à l'utilisateur je veux que tu montes un artefact ou un canva et que tu proposes les trois options à côté et qu'il y ait trois boutons et que ces trois boutons-là, à chaque fois quand tu cliques dessus, ça amène, grâce à un short URL, au checkout du booking correspondant pour que tu puisses finir ton achat. Bon, tu peux lui donner cette consigne-là. Potentiellement, il ne l'exécute pas, mais s'il l'exécute, tu te retrouves avec un bout d'interface que tu as réussi à faire générer au modèle au moment où tu en avais besoin pour l'afficher. C'est hautement inefficient, ça prend une plombe parce que du coup, il doit écrire une page complète pour essayer de restituer une information qu'il aurait pu restituer en une demi-seconde sous forme de texte mais c'est plus joli et c'est plus sympa à utiliser pour un utilisateur que de taper prends moi l'option 2 sur les trois options que tu m'as listées quoi, et du coup il y a un besoin dans le protocole de faire remonter une façon pour les serveurs de contrôler un petit peu plus la user interface qui est mis à disposition, ne serait-ce que pour améliorer le user experience sur certains sujets où le texte n'est pas le canal le plus approprié. Il y a beaucoup d'initiatives très différentes qui vont de l'iframe où tu contrôles entièrement ce que tu affiches à l'intérieur d'un bloc que je vois pas du tout arriver en production parce que ChatGPT ou Cloud prendra jamais la décision d'afficher un bout d'interface dans un truc qu'il ne maîtrise pas, mais en tout cas de permettre via un système de manifeste ou d'exposer un petit peu d'informations supplémentaires sur c'est quoi ton logo c'est quoi ton nom, c'est quoi les trucs qui font ta marque pour du B2C pour des problématiques B2C et pour des problématiques plus génériques de user interface avoir un truc un peu plus riche, j'irais pas trop jusque là parce que je trouve que l'expérience n'est pas tip top non plus mais il y a Slack qui avait avec les blocs à l'époque permis de créer une nouvelle user interface sur un truc de chat, l'initiative était cool et ça a permis de créer des interfaces qui étaient, vachement plus riches que du texte je ne suis pas un grand fan de ce qu'ils ont fait in fine en termes d'interface ou bloc mais une initiative similaire avec des building block du high au contrôle du serveur ça pourrait être cool pour justement enrichir ces interfaces là, et il y a des grosses discussions dans cette direction là, les raisons pour lesquelles des fois ça freine un peu des cas de fer c'est que, on imagine très bien à quoi ressemble un client lourd ou web, donc ton chat GPT sous forme d'application native ou dans le navigateur, mais il y a aussi des clients qui sont dans le terminal, par exemple Q, c'est un client dans le terminal. T'as pas la richesse d'interface utilisateur que t'as sur du web ou sur du client lourd avec de l'électron qui tourne derrière et du coup si tu mets dans le protocole quelque chose qui permet à des serveurs de contrôler l'interface utilisateur mais qui doivent tout d'un coup gérer tout autant le cas de l'affichage, avec un client qui est compatible HTML ou avec un client qui est uniquement capable d'écrire en assis tu te retrouves à devoir côté serveur gérer des problématiques que tu veux pas avoir à gérer et du coup, vient l'argument de capabilities donc un client quand il initie une connexion de lister les choses qu'il est capable de faire, ce qu'il fait déjà aujourd'hui pour des features comme les licitations dont je te parlais tout à l'heure, et de les enrichir pour aller jusqu'à même juste de l'UI de dire je suis capable d'afficher de l'UI en HTML et tant mieux si c'est le cas parce que l'interface, l'expérience utilisateur sera bien meilleure. Mais du coup tu jettes un peu à la poubelle tous ceux qui avaient décidé de faire un client sympa sur le terminal.

Bruno:
Super intéressant. Canon te merci beaucoup pour toute cette discussion Frédéric.

Frederic:
Avec plaisir c'est un sujet qui me passionne donc j'adore en discuter.

Bruno:
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 avec l'ensemble des auditeuristes.

Frederic:
Ouais j'avais beaucoup aimé j'ai eu la chance d'aller faire la toute première conf MCP, parce que la techno à six mois l'organisation de grosses conférences sur le sujet est très très early stage tu l'imagines Il y a eu une première conf qui s'est faite qui s'appelle le MCP Dev Summit, avec une journée de talk qui a été remplie avec des gens de l'écosystème, y compris Justin et David qui travaillent sur le protocole. Tout le contenu est sur YouTube, ça représente 8 heures de contenu, mais c'est vraiment génial. Il y avait notamment un talk en particulier que je recommande ne serait-ce que pour les 15 minutes de rire que ça offre qui sont fantastiques de Laurie qui est un des, créateurs de NPMJS et qui venait faire un talk sur toutes les alternatives à MCP puisqu'en fait des initiatives sur du protocole pour faire des frontages antiques, il y en a eu plein autre que MCP qui a été développé par Anthropik notamment A2A chez Google ou ACP qui était une initiative de chez Cisco, il fait l'état des lieux de pourquoi parmi ces 10 initiatives là il n'y en a pas eu qu'on catchait et est-ce qu'elles sont vraiment différentes de ce que MCP a proposé et du coup potentiellement complémentaires et en fait il passe 15 minutes à taper sur toutes les alternatives une à une il y a notamment Cisco qui prend très très cher pendant cette conférence, rien que pour la barre de rire que ça génère je recommande ce contenu là.

Bruno:
On mettra les liens bien évidemment en description et dernière question la plus importante de ce podcast, est-ce que tu es plutôt espace ou tabulation ?

Frederic:
Oui, je suis tabulation.

Bruno:
Très bien. Merci beaucoup Frédéric.

Frederic:
Avec plaisir, merci Bruno d'avoir accueilli.

Bruno:
Et merci à tous d'avoir suivi cet épisode. J'espère qu'on a développé encore plus cette curiosité autour de MCP. Donc c'est un nouveau canal d'acquisition, une nouvelle interface à devoir gérer avec tous les nouveaux challenges que ça présente. Tu disais tout à l'heure que tu n'avais pas connu l'époque que j'évoquais avec les navigateurs, mais tu connais l'époque où il faut gérer les différents LLM et les différents agents et leurs compétences différentes. Donc au final, en fait, on a tous les mêmes problèmes.

Frederic:
Ça revient. C'est un cycle éternel.

Bruno:
Donc voilà, préparez-vous à ce cycle. Ça veut dire qu'on va avoir des librairies qui vont arriver, qui vous permettent d'adresser tous ces trucs-là.

Frederic:
L'évaluation dont je parlais tout à l'heure, c'est un truc en plus des services d'infrastructure qu'on fournit, sur lequel on fournit du tooling pour que les développeurs puissent développer les serveurs les plus efficaces possibles donc n'hésitez pas à demander si vous avez besoin d'aide pour développer votre serveur chez Alpic, on essaye de fendre ça le plus simple possible.

Bruno:
Merci beaucoup Frédéric merci à tous d'avoir reçu cet épisode comme toujours moi je vous remercie de partager ce podcast autour de vous, n'hésitez pas à aller faire un tour sur le Tipeee si vous voulez soutenir ce podcast pour qu'il continue et qu'on puisse lancer aussi d'autres initiatives, n'hésitez pas vous abonner aussi sur notre canal TikTok, notre chaîne TikTok, où on va lancer tout un programme de live, ou qui a peut-être déjà commencé, parce que je ne sais pas quand est-ce que cet épisode sera diffusé. En tout cas, voilà, merci beaucoup, je vous souhaite une très bonne fin de semaine, je vous dis à la semaine prochaine, et d'ici là, codez bien !