De 15 à 90 % de fiabilité sur vos agents IA grâce au context engineering, Claire Gouze

Juste de clic. Salut Claire. Salut Théry. Merci de prendre du temps aujourd'hui pour parler de contexte engineering. Donc c'est un épisode où on va parler un peu technique, mais aussi ça va permettre de comprendre un petit peu où on en est aujourd'hui autour de l'illation générative et de la construction derrière le système agentique et des choses qu'il faut avoir sous le capot pour pouvoir récire à faire fonctionner tout ça. On enregistre cet épisode, je le précise et je pense que je vous rappellerai peut-être durant l'enregistrement en fin avril 2026, donc les choses évoluent très vite dans ce space si jamais c'était épisode et écoutez dans quelques mois ou dans quelques années, voilà. Sachez que ça a été dit fin avril 2026 et avant de rentrer dans le vide du sujet je te propose tout d'abord de te présenter. Oui, merci de m'avoir sur le podcast. Moi, je m'avais Claire Goose, je suis entrepreneur et j'ai co-fondi il y a deux ans naolabs avec mon associate Christophe Léphari et ce qu'on construit chez Nao c'est un le premier agent opensource pour faire de l'anahetics avec de l'IA. Le but c'est que n'importe qui dans l'entreprise puisse faire des analyses grâce à cet agent même si ils ont pas de compétences techniques. Et notre produit fournit un framework opensource pour que les équipes d'Ata puissent configurer leur agent, le déployer au sein de toute l'entreprise et avoir une visibilité sur la performance et comme on en parlera de travailler sur le contexte pour que l'agence soit performant et qu'il reste performant dans le temps. Et après, moi, sur mon parcours, j'ai un background en d'Ata. Avant de monter nao, j'ai travaillé pendant 8 ans à peu près en d'Ata. J'ai commencé en tant que d'Ata Sentice au PCG. Après, j'étais à Dope d'Ata chez Sundae. Et après, j'ai vu aussi un peu de freelance sur des sujets d'anahetics modèles de machine learning, production, personnalisation et style. C'est la marche très claire. Donc pour rentrer dans le visi sujet quand on parle de contexte engineering, en fonction de son niveau, on va dire, d'implication autour de l'IA, ça peut être plus ou moins loin d'un, on a entendu au tout début avec l'arrivée les premières sorties de la sortie de ChatGPT et les premières usages, on parlait beaucoup de prompte engineering. Après, on a parlé de ragues, parce qu'on a commencé à parler des hallucinations et du fait du coup qu'il fallait faire du ragues pour limiter des hallucinations. Et donc, on a parlé de contexte engineering. Est-ce que tu peux un peu te poser le décor entre la différence entre tout ça et comment on en arrive aujourd'hui à parler de contexte engineering? Ouais, je pense effectivement, il faut un peu retracer tout l'historique qui s'est passé dans une petite fenêtre de temps. Mais il s'est passé beaucoup de choses. Je pense que l'évolution du focus s'est fait aussi avec ce qu'on appelle aujourd'hui le Arnes. Donc tout ce qui est autour du LLM, je pense que tout début quand on a commencé à utiliser les LLM, parce qu'on parlait bien pas d'agentique avant, c'était juste la géniale. Au début, c'était vraiment juste un prompt. C'était juste un LLM à qui on posait des questions. Et donc en fait, le seul outil qu'on avait pour manier un peu lLM, c'était le prompt qu'on lui donnait. C'était comme dans le chat de GPD. On posait une question, il faut que la question soit la plus fière possible. Et après, les Arnes sont un petit peu complexifiés, donc on est passé de chat conversationnel à des agents. Donc là, je pense que c'est là où on a, par exemple, des outils comme "cursors" qui se sont rajoutés, l'arrivée des MCP. Donc là, c'est rajouter des tout, la ton agent. Et donc ça, ça, déjà lui apporte un peu de capacité en plus. Et puis finalement, on s'est rendu compte que plus il avait de capacité plus il fallait aussi l'aider à s'orienter dans tous les capacités qu'il avait. Donc on a commencé à appréhérer de rags ensuite, parce que en fait, encore une fois dans des outils et comme "cursors", on est face à des énormes codebase. Donc il faut que la agent puisse se orienter dans des codebase. Et donc là, on s'est dit "ok, bah on va utiliser le rag, créer des embeddings de contexte pour que la agent puisse les chercher, etc. Et puis petit à petit, en fait, on s'est rendu compte que c'était peut-être un peu trop opaque que ça apportait pas forcément de fiabilité mais peut-être plus de complexité que fiabilité. Et les outils, encore une fois comme "cursors" sont repassés sur, en fait, l'agent, il a accès à plein de fichiers de contexte. Et il faut lui donner un maximum de contexte dans des fichiers, que l'agent ensuite soit capable d'aller chercher son propre contexte. Et donc c'est là où je trouve qu'on commence à parler de contexte engineering. C'est quand on a commencé à créer des fichiers de cloutes.md, les routes.md, dans plein de déménations possibles, les skills qui sont appareils à quelques mois, etc. Et d'où qu'en fait, on s'est rendu compte que le contexte on pouvait. enfin que le contexte on pouvait le donner dans des fichiers à part et que ensuite l'agent, il allait lui-même aller chercher le contexte, plutôt que de se concentrer sur comment on allait prompté l'agent à chaque fois. - Il y a ce que tu dis, la notion de poser ce contexte-là dans des fichiers, ça permet du coup de répondre aussi à la problématique de la funnette de contexte aussi des élèmes, donc de ce qui est préchargé dans les élèmes et du coup pour limiter à la fois déjà la consommation token, mais aussi surtout le fait qu'il se perdre parce qu'on lui précharge plein, plein d'informations et si on précharge trop d'informations, c'est plus compliqué pour lui de savoir laquelle piocher. Donc, t'as mentionné, notamment avec anthropique les fichiers de clout de md, ensuite les skills qui permettent de donner des contextes sur des outils qui peuvent être utilisés, sur la manière de utiliser ces outils et derrière aussi une logique sur un projet en particulier. Maintenant, quand on en demande dans la notion de contexte engineering, quand on veut construire des agents qui vont marcher de manière autonome, pourquoi est-ce qu'on ne met pas encore plus de complexité là où, si on n'a pas besoin, c'est-à-dire que, est-ce que, juste, peut-être que ça voudrait la peine de prendre un exemple concret d'un agent, d'un agent avec lequel peut-être, toi, t'as eu l'occasion de bosser que ça soit vous en interne ou avec les clients que vous accompagniez. Est-ce que t'as un cas d'usage là, en tête que tu penses qu'on pourrait prendre justement pour éducer un peu tout ça, le chemin de moi? Oui, et ben, je pense que nous, dans notre domaine, par exemple, en data, il y a beaucoup de complexité parce que la data, elle a un regard sur tous les différentes domaines de l'entreprise, l'équipe d'attal va être user les opérations, la finance, la RH, et donc ça, c'est des contextes qui sont très différents. Et oui, il faut aussi être très précis parce que t'as besoin de fiabilité sur les chiffres que tu vas sortir. Donc en fait, si tu n'as pas de contexte, c'est que, juste, t'as un méga prompt qui t'explique à la fois que, quand tu calculais chiffre pour la finance, pour RH, etc, c'est sûr que ça va pas se cayer, et que, à la fin, la jambe, il est perdu que, toi, tu dépenses trop de tecquen, tout le temps, on va y le même contexte. Et donc, nous ce qu'on fait par exemple avec notre rémoire, c'est qu'on permet d'avoir, en fait, le système avec des contextes par domaines de l'entreprise. Et comme ça, ensuite, le but, c'est d'avoir un prompt qui va juste servir d'archestrateur, qui va être dit qu'il va s'il y a des questions sur la finance, il va aller voir le contexte dans cet endroit-là. Et ensuite, ça permet d'être très précis sur le contexte de ce domain de la finance et aussi de pouvoir se cayer avec l'entreprise, parce que demain, si l'équipe finance grandit, il y a plus de chiffre qu'il y a des entités dans plusieurs endroits, il suffit de rajouter des fichiers et des sous-fichiers, etc. Et donc, ça va escaler là où un seul méga prend, qu'on ne pourrait pas se cayer, lesquels. - On va prendre ce qualif, pour votre cas d'agents d'analysics, pour voir comment un peu du coup, du structure. Donc, vous allez permettre à des équipes non techs de pouvoir l'explorer de la donnée de manière assez fine, au travers de votre produit. Donc, avant, il y a la phase de setup du coup de votre produit au sein de l'écosystème data, de l'entreprise sur laquelle vous allez vous graiffer. Et vous allez permettre d'explorer autant des sujets que vous avez compués par domaine métier, par rapport à ça. Donc, quand vous allez arriver, si vous accompagnez du coup une boîte pour lui déployer la solution, leur permettre de construire du coin d'agents, un superagent d'analysics, quels sont un peu les mécaniques de réflexion que vous allez mettre en œuvre pour vous dire qu'il faut qu'on pose justement bien ce contexte-là par domaine métier. Quels sont. qu'elle est le process de réflexion, un peu le frein morts que vous utilisez pour poser ce contexte-là? Oui, oui. En fait, nous ce qu'on a construit du coup, c'est un frein morts que d'évaluation du contexte. Donc, c'est un gros, on fait des tests unitaires d'agents. Le but dans notre discussquais d'attaque, c'est que quand tu pose une question à l'agents, c'est comme je suis d'affaire de la semaine dernière, qui te donne le bon chiffre. C'est assez simple comme ça. Et donc, ce qu'on fait, c'est qu'on crée des tests unitaires de questions répandes chiffrées. Et comme ça, on peut faire tourner l'agence sur ces tests unitaires et voir si avec le contexte qui a été créé, on a une bonne fabilité. Donc, ça, ça permet d'avoir un frein morts que des évaluations qui va vraiment rassurer de façon très chiffrée. Enfin, ouais, chiffrée les équipes d'attaques. Et après, nous ce qu'on conseille, en fait, c'est de pas, non plus, mettre trop de barrares à l'entrée sur créer un bon contexte. Quand on conseille, c'est juste d'essayer ce que vous avez actuellement. Parce qu'en fait, les entreprises ont déjà du contexte. mais elle ne savent pas qu'elle est la quaiissée ce contexte actuellement. Et donc, nous, notre aimant par exemple, qui permet de faire, c'est de juste synchroniser tout le contexte qui existe. Donc, la doc a été écrit par là dans le notion, dans la base de données, les ripoqes dites qu'ils ont, enfin, on leur dit, synchroniser tout, lancer l'agence sur les tests. Et comme ça, déjà, vous avez votre baseline de où est ce que vous en êtes aujourd'hui. Donc, là-dessus, une approche très très pragmatique ou en fait, vous mettez en place le système d'évaluation avec des cas pour lesquels vous savez définir les autres pouts de que vous voulez. Et donc, quand tu dis aux connectés un peu tout votre contexte, là, vous le faites au travers de quel mécanisme avec du MCP, avec juste des accès par appels simples aux outils internes. C'est quoi, un peu votre manière de faire? - Ouais, bah là, c'est quelque chose, enfin, c'est un outil qu'on a conçu dans notre frère-moir. Nous, du coup, c'est des contextes assez ciblé séries en gros, ce connecte à Tower warehouse, à ton outil de documentation, à Inter, T-Gitrypo, de Transfour, de Bayplane, etc. Donc, on a ces connecteurs-là, et on va juste clonner en fait le contexte existant. C'est l'équipe d'attaque qui dit, enfin, qui dit, "Quel sont les sources de données existantes? Les sources de contexte existantes?" Donc, ça, c'est vraiment juste nous qui s'incronisons le contexte existant. - Ok, ça marche. Et donc, vous mettez en place du coup, c'est donc là, t'as pris l'exemple par exemple du chiffre d'affaires. C'est quoi un peu le nombre d'évaluation que vous allez recommander avant de commencer à tester justement, à mettre en place, tu vois. - Je sais pas si ça se mesure en termes de nombre, je pense que c'est plus quand tu es une équipe d'attaque, tu sais qu'elles sont les 10, 20 questions qu'on te pose tout le temps, et aussi celle où tu n'as pas le droit à l'erreur. Nous, par exemple, sur notre projet en interne, moi, je me suis construit une quarantaine pour une dizaine de tables. Voilà, ça reste assez raisonnable quand même. Et j'ai juste couvert toute l'équition où je veux absolument que l'agent ne se trompe pas. - Oui. - Je pense que c'est plutôt comme ça. - Non, mais ça donne un peu des heures de grandeur. Tu vois une quarantaine, ça reste. - Oui, c'est pas non plus 150. - Ou même des milliers, c'est quelque chose qui reste gérable par un humain sur une phase de step. Ce sujet toujours, quand tu veux mettre de liat, tu veux déployer pour t'augmenter sur certains stages, mais super plus de temps à vérifier les stages. En fait, ton héros y est négocé. - C'est sûr. - Au final, donc, donc, intéressant ce premier point, donc de poser un peu les évaluations du coup sur les cas où il n'y a pas le droit à l'héraire, sur les autres cas, du coup, quand ensuite ça commence à tourner, et tu vas du coup poser des questions potentiellement, il y a des fois tu peux vérifier facilement, d'autrefois, ça va peut-être plus complexe de vérifier la pertinence de la réponse. Comment est-ce que vous gerez ça, tu vois, ou intervient la notion de contexte en généralement? - Ouais, c'est pour ça que en fait, je dirais qu'il y a une notion d'évaluation de contexte qui est théorique, qui est celle qu'on fait avec l'étationitaire, et il y en a une qui est plutôt. - Pratique. - Pratique. - Pratique. Et donc ça, c'est. On a une deuxième phase du produit qui est de l'observa-busier, qui est en gros, pour pouvoir regarder toutes les conversations qu'on a été faites avec l'agent, détecter si l'agent ne trouve pas des informations ou fait des hypothèses à certains moments dont on est pas sûr. Donc on peut faire une chose de scorine, de fiabilité, des conversations. Pour qu'on se trouve que la boucle de feedback, et que dès que l'agent tombe dans un homain d'élande de contexte, et on enrichit le contexte, et c'est ce qu'on a. Cette personne apprête un peu de l'autolourning, quoi, en fait, en enrichir ton contexte, ça fera mesure que tu sais pas des choses, quoi. - Oui, et là, sur la phase d'enrichissement du contexte, c'est ajouter plus d'infos ou c'est réadapter la manière dans le contexte et destructurer ou la manière dont vous donnez le contexte, justement. - Je pense que ça peut être plusieurs raisons différentes. Enfin moi, j'ai fait du coup pas mal de tests, justement, du coup, sur notre propre données. Donc ce que j'ai fait, c'est que j'ai mis le contexte que j'avais telle qu'elle, à l'agent, et j'ai regardé la fiabilité, et je pense que je devais avoir peut-être 15% de fiabilité, quoi, de mes réponses qui étaient justes. Donc c'est pas assez fiable. Et donc, j'ai passé par exemple de temps à regarder ce qui ne fonctionnait pas. Et je pense que les premières choses, c'est que parfois, en fait, le contexte qu'on a de base et en bigule. Donc par exemple, très concrètement, moi, j'avais plusieurs tables qui parlait de revenu. Il y avait pas les mêmes définitions. Donc en fait, parfois, c'est même pas le contexte que tu donnes ton agent qui n'est pas bon. C'est une façon dont tu as construit ton archie où je sais pas de ta documentation. Et donc en fait, parfois, c'est l'étape d'avant le contexte. Et ensuite, ça peut être aussi que oui, il te manque des informations dans le contexte que tu as donné, ou qu'il n'est pas bien agressible, ce n'est pas bien clair. Voilà, ça peut être une fin de niveau. Et donc là, tu as commencé le premier test. T'étais autour des 15% ou 14% de taux de succès. J'imagine que tu as réussi en déco, à ta meilleure chiffre. C'est quoi un peu les chiffres aujourd'hui sur lesquels on peut se projeter du coup globalement, sur lesquels vous arrivez à atteindre. Et dans ton cas d'exemple, qu'est-ce que tu as fait comme motif, peut-être même concrète sur des cas très précis pour montrer justement le chemin de mon parlement qui a été passé pour atteindre un port de s'en tâche plus élevé. Ouais, ouais. Du coup, actuellement, on est à 80% de fiableté. Donc c'est. Bien, surtout que les 10% c'est surtout des alliades d'interprétation, on va y dire. Par exemple, si je dis "C'est quoi le pourcentage de new user qui ont testé ta le futur". Parfois, l'agent, ils vont prendre le nombre de users, ça a une ope, parfois ils vont prendre celui qui sont actifs la semaine dernière. C'est rien de faux. C'est des choix d'interprétation. Voilà. C'est gérable, je dirais. Du coup, je pense que vraiment moi ce qui a le plus à améliorer la performance, c'est justement de détecter les ambiguïtés que j'avais dans ma donnée et de le retravailler là-dessus. Aussi des champs, des données qui étaient mal décrites. Parfois, en fait, il y a des champs qui décritent des fiatures, mais les fiatures ne sont pas si. Fassil à comprendre si on n'a pas le contexte. Aussi beaucoup de contextes business a donné au-delà des chiffres et des tables. Donc cette partie vraiment, en fait, au retravailler les ambiguïtés qu'on avait de base dans notre façon de faire. Elle est super importante. Et là où je trouve que c'est crucial de dire qu'en un agent, on ne fonctionne pas bien. C'est pas que l'agent a hallucin, donc c'est la faute de l'agent. Souvent, c'est un peu un miroir à quel point on est clair nous-mêmes sur les choses. Et après la deuxième chose, c'était justement de aider l'agent à s'orchestrer. Donc comme je disais, nous, on a en file système, le contexte d'agent, c'est un file système. Mais potentiellement, il va prendre trop de temps à chercher les choses si on n'a pas inficher qu'il orchestre un peu dans le file système. Et du coup, j'ai fait un file d'agent principal pour lui dire, si il y a des questions sur telemetrie, il faut dire qu'il faut aller voir là. L'orchestrer un peu pour savoir où aller sur ses contextes, pour qu'il aille plus vite qu'il y a des choses pour se rendre compte. - Oui, c'est donc quoi? Deux points de panclé le premier au final qui est vrai sur un monde avant il y a générasif et qui l'est encore plus aujourd'hui, c'est avoir la donnée structurelle de manière assez claire et homogène où tu comprends la structure cota de ta data. Et le deuxième point que tu viens de partager, c'est comment tu fais pour avoir un peu un Master Agent un agent orchestrateur qui est en fait fletcher au bon endroit sur là, dans votre cas, du coup les bons dossiers vers lesquels elle a l'exploré pour aller chercher tel ou tel type d'information pour aller vite faire des alléros tour et de charger aussi trop d'informations dans sa contexte humdot qui pourrait aussi l'amener un peu à se disperser après haut de la data les plus vite. J'imagine, il y a aussi ce sujet de dispersion. Donc hyper intéressant sur ce premier point de la structure ration de la donnée. Du coup vous construisez un agent autour de la data et le but c'est quand même d'aller vers ce monde agentique. Et pour autant on entend bien avec ce que tu dis que pour récer à l'a, il faut avoir de la data qui soit bien structuré et de la data que tu mettrise quoi. Donc quel est un peu pour toi le facteur du coup derrière différenciant des boîtes qui vont vouloir se lancer vers ce monde là, vers l'agentique. Je pense notamment à ce potentiellement des sasses existants qui se disent où là là, je peux risquer de me faire challenge de main par un produit qui arrive foule agentique. Et je voudrais essayer de voir moins en tant que produit existant comment est-ce que je peux continuer à exister et capitaliser sur des forces que je peux avoir que je ne réalise pas que j'ai aujourd'hui. Et notamment potentiellement la donnée, c'est quoi un peu toi ton regard par rapport à ça. Sur l'évolution du monde vers l'agentique et la place en finale du monde préagentique et notamment la donnée là dedans. Je pense que le but c'est de pouvoir écutiser par des agents le plus possible. Et on voit par exemple pas mal de boîtes existantes qui commencent à créer leur MCP, leur Tialaille, migré sur du Ascode parce que si migrants vers ça, ils pourront être utilisés par des agents plus facilement et même les agents pourront les recommander plus facilement. un peu le sens de ce qu'il faut faire, c'est un peu ce que nous on a fait comme cheminement, avant on avait un software, un IDE, et en fait on s'est rendu compte que ça faisait plus trop de sens de proposer des outils qui étaient déjà packaged et aujourd'hui c'est plus, bah il faut fournir des briques pour que les gens puissent construire avec, ou même pour les agents, puissent construire avec, mais je pense que c'est quand même important d'avoir des briques, je pense que nous ce qu'on fournissait justement le frère-moire pour construire le contexte et pour le synchroniser, les valuer, etc. Ça fait pas forcément de sens que chacun reconstruise ces brûles-là, mais par contre t'as envie que la jambe puisse travailler dessus, quoi. Donc je pense que c'est comment tu transformes ton produit packaging en briques, ils peuvent être utilisés par un agent, quoi. Oui, non plus par des humains et par des agents du coup, donc t'as mentionné par rapport à ça sur la capacité des produits existants aujourd'hui où il y a beaucoup de temps peut-être passer sur justement la partie UX et UI d'un point de vue humain parce que l'itiateur final est un humain, ben demain, le UI du coup ça peut potentiellement être mis de côté, mais UX au sens expérience-développeur déjà pour les développeurs qui interconnecent les systèmes et au sens UX pour des agents, en fait, donc pour permettre aux agents d'être le plus facilement interconnecté, ça va devenir ultra important. Et donc pour pouvoir connecter ces agents entre eux, donc t'as parlé de choses, t'as parlé de MCP et de la commande line interface, la CLI. Est ce que tu peux un peu décrire rapidement du coup la différence entre les deux et ce que ça permet de faire et pourquoi il y a des avantages avec clins versus les autres. Ouais, du coup, le MCP concrètement, c'est juste des fonctions, enfin c'est un packaging de fonction pour rappeler l'appsiaille dans nos T, donc par exemple, je sais pas le MCP Slack, c'est des fonctions pour envoyer des messages sur Slack, récupérer des messages, etc. La CLI, c'est un ensemble de fonctions qui vont être exécutées par l'agent, c'est un fait de jouer à l'exprite, mais en gros c'est dans un… On peut, si tu veux, on peut commencer par dérouler un peu sur la MCP, donc comme tu le décries là, du coup, t'as un wrapper autour d'une API, donc en fait, c'est une manière d'abstraire encore plus en fait d'une API pour permettre à des systèmes qui connaissent pas les détails sous-assant de comment la API est implémentée, donc la CLI de Slack, veut dire, si je suis sur Slack, par exemple, moi, mon MCP off, la possibilité d'envoyer un message sur un canal, et potentiellement, ça peut être Slack qui rentre sous, mais potentiellement, ça pourrait être Discord, ça pourrait être MatterMoss, enfin, un autre outil type chat comme cela. Et du coup, l'agent lui va juste être intéressé par la fonction envoie message dans un channel qui s'appelle « P'en pas ». Pour faire ça, du coup, le MCP, il expose ses fonctions à des agents, mais derrière concrètement, techniquement, comment est-ce que ça marche? Parce que c'est là, après, vous vous tombez aussi par rapport à la distinction avec la CLI, comment derrière quand je pronte et que je connecte au travers de MCP, qu'est-ce qui se passe derrière dans mon pronte, en fait? - Ben, en gros, ce qui se passe, c'est que du coup, en gros, tu dis, à l'agent, ta disposition dit « Toul », et si tu veux, tu peux les exécuter, quoi, donc tu as le "toul", envers un message sur Slack, le "toul", cherche des messages sur Slack. Et donc ensuite, lui, en fonction du contexte, il va décider qu'il va appeler ce "toul", et il va dire qu'à les arguments, il veut, enfin, donner à ce "toul", et donc ensuite, il y a une autre, enfin, un backend qui va exécuter le "toul", etc. Et je pense l'inconvénient de ça, c'est, du coup, tu dis en permanence qu'elles sont les "toul" à dispose, ça remplit ton contexte, enfin, c'est un peu le challenge de MCP, quoi. Et en plus, du coup, t'es limité par les capacités du MCP. Si ton MCP, il a que 5 "toul", tu peux pas aller faire autre chose, quoi. Et tu peux pas non plus le modifier pour aller attendu ce qu'elle se co-est. Et la différence, du coup, de CLI, c'est que, en fait, c'est de l'exécution de code. En fait, c'est comme c'est avec un "toul", d'exécution de code. Et juste, tu vas donner, par exemple, le du contexte dans une "toul", ou dans un "fiché", sur. C'est quoi? Enfin, comment tu as exécuté du code sur Slack? Par exemple, et donc, par exemple, là, sur toujours l'exemple de Slack, tu n'as pas l'imitation, tu peux appeler tout ce que tu veux du moment que c'est dans la pilaille de Slack, parce qu'en fait, tu fais juste une exécution de code via ton agent, quoi. Et du coup, par rapport à ça, ce que tu disais, le fait de surcharger le contexte, vu que le MCP, tu envoies toutes les fonctions tout le temps en permanence. En fait, tu charge déjà ta fenêtre de contexte dans le prompt. Et potentiellement, il peut un peu si perdre. Et enfin, tu surcharges déjà là ou avec les outils du coup de ligne de commande, tu peux beaucoup plus spécifique. Et si l'outil de ligne de commande, la gende c'est pas comment l'utiliser. Il y a toujours des fonctions ELP pour essayer ensuite à demander le détail. Donc, pour revenir à l'action initiale, c'était du coup, effectivement, les produits et ça se demandent qu'ils veulent se tourner vers la gente, bien, réfusez à comment, au frire, soit du MCP, soit des CLI pour permettre du coup à d'autres systèmes de s'interconnecter avec. Sur la notion, si on revient du coup sur la notion de contexte engineering, parce que typiquement, ces produits-là, s'ils veulent aussi se réinventer, mettre de l'agentique dans leur manière de faire. Ils se questionnent un peu sur, ok, j'ai de la donnée qui m'est propriétaire, qu'il y a beaucoup de valeur, je voudrais réussir à, posant seulement, créer des agents autour de cette donnée-là. Quelles sont un peu là, pareil? Proces de la question, je te posais la question, quand on arrive dans une boîte qui veut déployer Nao pour pouvoir permettre de faire de la business intelligence au travers de votre agent, bah tu commences par maître des systèmes d'évaluation sur les cas, les questions les plus basiques pour vérifier, ensuite tu dis, ben, tester, et puis, ajuster le contexte en fonction. Là, si tu as une boîte qui a plein de données propriétaires qui peuvent avoir de la valeur et qui veut réfléchir à mettre à créer des agents autour de cette donnée-là, comment t'aborderais la problématique, tu vois, autour de ça? Mais tu veux dire, une boîte qui propose un sasse? Ouais, qui propose un service aujourd'hui, ouais. Ouais, franchement, tu vois, je trouve un exemple intéressant, c'est le source, là, il vient d'annoncer genre il y a quelques jours qui d'aller faire un adlès CRM, Nao Uai CRM, je trouve que c'est le smart move à faire, quoi. Je pense que tu peux plus te dire que maintenant ton mot, ton tableur à rajouter, c'est lui-aille, quoi, et que c'est vraiment plus qu'elles sont les blocs et les fonctions que tu vas apporter aux agents existants, quoi. Donc si tu penses à celles force, bah déjà, c'est capital que ton CRM puisse être accessible depuis un agent type clôtre, codex, etc. Et si tu peux aussi apporter des fonctions que ensuite ces agents-là puissent utiliser, donc par exemple, je ne sais pas enrichir des profils de CRM ou faire des récables de code ou juste pas. Mais donc pour moi, c'est la valeur ajoutée, maintenant c'est qu'elle toule ta porte à son agent, comment tu rends accessible facilement les infos à ton agent, c'est plus dans ça qu'il y a la valeur ajoutée, quoi. Oui, c'est très clair. Du coup, par rapport à ça, ce dont tu parles au début aussi sur les niveaux de précision que t'attends, donc au début quand tu commences potentiellement, tu peux avoir des niveaux assez faibles et après quand tu commences à configurer des choses hop, tu peux arriver du 80% de fiable d'obtéguer. L'empêche pas moins que on parle de 90% de fiable d'obtéguer ou que le software soit ça marche ou ça marche pas. Du coup, qu'elle est par rapport à ça, en fait, il y a vraiment un shift sur l'évolution du secteur abagrant, en data science, et du coup, la spécifre et pertinence des analyses que tu fournies, elles sont basées sur la donnée en gros, c'est noir ou c'est blanc, je veux dire, tu peux avoir des choses assez factuelles, là, on parle de système du coup qui sont noms de déterminisme dans lesquels il y a des fois potentiellement des approximations, etc. Comment tu vois ce shift là, du coup, plus là, autour du monde du produit de la tech s'opérer et être adopté ou pas justement parce que c'est une nouvelle manière de penser, je trouve. Oui, je pense qu'il y a plusieurs choses. Il y a déjà le fait que je suis passant à 100% de fiabilité avant, je ne pense pas qu'on était à mieux que 90%. Si je reprends les exemples d'interprétation dont je parlais, je pense qu'il y avait les mêmes erreurs d'interprétation avant, je pense que dire à quelqu'un qui n'est pas technique de faire lui-même une analyse que ce soit investuée là ou avec du no code, c'est les mêmes erreurs, parce qu'en fait, les erreurs, c'est que les personnes ne savent pas trouver la donnée, donc ils ne choisisaient pas les bonnes colonnes, et je pense que c'était peut-être même plus problématique avant. Donc voilà, je pense qu'il faut pas se dire qu'avant, il était à la 100% de fiabilité. Et ensuite, je pense qu'il y a quand même eu un shift où, de plus en plus, les gens favorisent la rapidité à la perfection, on va dire, et je pense que le shift, ça se voit dans les outils des agentiques codes qu'on utilise avant, on utilisait juste le tab de cursors pour aller plus vite. Maintenant, on laisse Claude code faire tout et on regarde même pas le code, donc je pense qu'il y a un peu ce truc de "je veux juste vérifier la route de route de route, mais pas trop qu'est-ce qu'il a été produit par l'agent, et c'est un shift qui je pense à dire "pian d'avancé quoi". Donc par rapport à ça, est-ce que tu vois, toi, justement, potentiellement, demain, est-ce que on redra plus du tout le code, est-ce que, au contraire, on va avoir un retour en arrière avec du coup, ben, un nouveau besoin de profils experts sur des techniques, parce que en fait, il va falloir démêler un peu des trucs qui ont été faits pour comprendre qu'elle serait un peu. Est-ce que, si tu fais de toi, ils n'ont de si passion à quelques années, du fait que tout le monde, bah, sans barque sur cette logique, va ébcoing, et vraiment, laisse les machines créer un peu le code, comment. qu'est-ce que tu entissies toi par rapport à ça? Je pense que la mauvaise est plus de créer les outils pour libérer le bottleneck du webcoding, donc c'est, par exemple, avec Tursor, ils ont sorti leur feature où dès que tu fais une PR, ça te fait une vidéo du feature, et du coup, tu as juste regardé la vidéo de ce qu'il a fait, il y a plein d'outils maintenant pour faire du code review automatique, non, on utilise ça, parce qu'on a un projet opensour, on a plein de contributeurs, on ne peut pas se permettre, qu'il y ait quelqu'un qui te met une backdoor ou quoi dans le code, et donc on a des code reviewer automatique qui va regarder tout ce qui se passe, et je pense que la mauvaise c'est plus ça, c'est comment est ce qu'on fait pour pouvoir aller plus vite en étant sûr de la route, et finalement, le code d'un intérieur, c'est OK quoi? C'est effectivement, et puis, si une approche du coup, beaucoup plus solente est produit, où en gros, tu veux que ça trente un service, et tu assure que ce service est rendu, et après, pas importe la manière dont ça fait, dont ça fait en dessous. C'est intéressant, après moi, le point que je me dis, c'est sur les sujets cyber, posonsiellement, en fait, alors ça enlève pas, aujourd'hui on a déjà ce problème là encore récemment, enfin, il y a toujours des failles de sécurité, alors est-ce que ça va en faire apparaître plus, où est-ce que à l'inverse, ça va à réduire, parce qu'il y aura moins d'avoir humaine à voir après sur ces sujets-là, mais le fait, par contre, d'avoir une pensée très très produite, en gros, je veux que ça me rende tel ou tel service, et donc je me concentre surtout là-dessus plus que sur comment c'est fait en dessous. C'est quand même une approche aussi intéressante, je trouve, par rapport à ça. Maintenant, si on vient un peu sur vous, votre histoire avec Nao, et en fait, ça va faire deux ans que vous êtes dans cette univers autour de la généracie, que vous construisez, vous avez déjà évolué, puis vos té-pour-fois, du coup, votre modèle, votre proposition de valin, justement, qu'est-ce que t'en a appris de ça? Donc là, on sort un peu du pure contact engineering, mais de ces deux ans à construire, donc vous avez fait ou avec un binateur du coup, de ces deux ans à construire dans le space, avec une vitesse folle où il y a des changements tous les jours. Est-ce que t'arrives là à prendre un tout petit peu de recul pour dire, ok, il y a quelques pâtènes, quelque chose que je commence à apercevoir sur ce que ça veut dire que de construire un produit dans cette univers-là pour éviter de se brûler non plus et réussir à la fois être à l'écoute de ce qu'il faut faire, et en même temps, ne pas tourner en rond en permanence parce que tous les jours potentiellement, tu as une nouvelle disruption. - Oui, oui. Bien, événement, je pense qu'il y a eu un peu un shift, par un drive que là, ça fait, on a vraiment commencé à monter la boîte au début de la vague de l'IA, et il y a vraiment ce shift au début, on était là pour construire du software, packaging, quoi, clé en main, et maintenant, on essaye de s'orquestrer autour des agents, de ces megas utilisateurs de produits, et je pense que justement le shift, c'est de se dire, tant. Il y a ce truc de les startups, mon peur, maintenant, de se faire disrupter demain par anthropie, que le sort sort de nouveau produit et leur produit, il y a une autre chose, et il faut prendre encore plus qu'avant, ne pas être attaché à son produit, et remettre en question sa place par rapport aux avancés des gros labo-diats, et donc c'est pour ça que nous, on essaie de revenir le plus possible à l'essentiel, le plus possible vers des bris, de l'infra, des choses qui ne vont pas être disruptées par n'importe qui qui prend un agent, et qui peut bien être codé quelque chose, donc je pense qu'il y a un retour au fond d'amontale, au fond d'amontaux, au bruit, plus que au software, au global. - Oui, donc les couches d'infra qui vont permettre de construire ce monde agentique plus que la partie, justement, applicative, la suite. Et par rapport à ça, du coup, ce que vous vous construisez là, justement, donc tu prenais les emplois potentiellement des labo qui sortent une fiture qui qu'ils complètement ont produit du jour au lendemain, quoi, enfin là, on va avoir qu'elles tournent, ils ont ça, prend, mais il y a anthropique qui a sorti cloud design, il y a quelques jours, et donc ça va faire, je pense beaucoup de mal à Lovable, FigmaMaker, Enco, avoir apprécié tel et leur promise, etc. Qu'est-ce qu'il fait que vous vous dites, en fait, ça ne va pas être aussi simple du jour au lendemain pour un anthropique ou un OpenAI, de sortir une brique, qui soit la même que la note? Je pense que le but des anthropiques et contextes, c'est de créer plutôt un OS qui va orchestrer des outils déjà existants, mais qui doivent vraiment bien s'interconnecter avec eux. Par exemple, il y a des gens qui ont une test que celles forces va disparaître, que ça n'a plus aucun sens avant un CRM, etc. Moi, je ne suis pas forcément d'accord, enfin, je suis pas forcément d'accord que chaque entreprise va revive coder en CRM un email, enfin, je pense que ça ne va pas être sens, enfin, on a quand même envie d'avoir un peu de road productivity. De road productivity? De pari inventer la route en interne sur chaque truc, et donc le but, c'est, mais par contre, on veut que ces solutions ne soient plus propriétaires, ça interconnecte avec les agents, mais je trouve que ça a fait pas sens que chaque entreprise reconstruise, chaque software en interne, et je trouve que ça ne va pas être sens non plus que anthropique se met à construire un CRM en fait, enfin, ils ont, je pense que je vais de la rajouter à construire de autre chose. Donc c'est pour ça que je pense qu'il faut être le software qui va pouvoir s'intégrer, enfin pas du software. La plateforme ou la archite qui va pouvoir s'interconnerter avec les agents. - Oui, et du coup, enfin, tu vois justement ce que vous en pensez à la note, du coup, qu'est ce qu'il fait que vous dites? C'est pas la place dans l'opinariat ou dans l'antropique d'aller là où vous êtes. C'est quoi? Qu'est ce qu'il fait que vous dites? Enfin, ils ont pas vraiment intérêt à venir là où on est? - Oui, bah, nous, en ceant, on est sur une verticale assez précise, qui est l'analyse de données, et l'analyse de données, c'est pas juste. Il y a plein de nos clients qui se disent "Bah pourquoi en fait, je ne mets pas juste le MCP de ma warehouse sur Claude ou le MCP de ma API sur Claude, mais en fait, si tu veux vraiment t'assurer que les chiffres sont bons, que ça n'a pas dévisé dans le temps, que tu peux toujours avoir une gouvernance sur ta date à que des gens dans un domaine aient pas voir les chiffres qui sont interdis et etc., il faut quand même tout un travail de préparation de la donnée et de source of trousse, de contexte lière comme on le disait. Et donc nous, on a de valorger, c'est vraiment cette contexte lière que tu construis, consincronise avec plein d'autant droit où il y a ce contexte, il se ferait mort avec des violations qui quand même assis propre à la data, quoi, de réfléchir si ta le bon chiffre pour une question. Oui, très clair du coup, tel à quand tu parlais de OS, ça m'a fait penser du comment en sujet, on parlait une semble en off, juste avant, sur le fait que tu commences à construire ton personnel OS, donc ça fait le robot aussi avec cette logique de contexte engineering, parce que quand construit son système d'exploitation personnelle pour être plus productif, ça veut dire effectivement qu'on essaie de donner le plus de contexte pertinent par rapport à cet âge du quotidien à la machine pour qu'elle nous augmente au maximum. J'ai un épisode, je pense qu'il sortira, alors je sais plus il sortira après ou avant celui-ci, mais qui est concentré là-dessus sur construire son personnel OS en tant que product manager. Donc je suis curieux là-toi de t'entendre sur toi qu'elles sont tes apprentices là où, qu'est-ce que tu as fait pour toi, à titre perso, les choses qui marchent, il marche pas à ce que tu en as appris aujourd'hui. Oui, oui. Et je rappelle qu'on enregistre du coup cet épisode fin j'ai le 2016. Ouais, du coup, en fait je pense que je me suis. Enfin, je trouve ça frustrant quand même d'avoir autant de tâches que je faisais de façon de répétitive et de ne pas pouvoir les automatiser plus par un agent et je sentais que quand j'essaie de le faire faire par un agent, j'avais pas assez de contexte pour qu'il le fasse bien et donc ça a été plus rapide que je le fasse moi-même. Mais je me suis dit, bon, je vais essayer d'investir vraiment pour que l'agent, il est tout mon savoir et qu'il puisse faire bien les choses. Je pense que le premier news case où j'ai commencé à le faire, justement j'ai créé pas mal d'artiques de blog par elle de LinkedIn. Donc j'avais déjà beaucoup de choses écrites, d'articles et post que j'avais créé avant. Donc j'ai commencé par lui dire de se craper tous mes postes et de créer une première chose pour juste faire des postings d'in et des postes abstracts. Et juste sur ce juice case là, je voyais qu'il est arrivé vraiment bien à prendre mon ton, à prendre un drape de d'idées et à en faire quelque chose qui veut moi, je ne aurait plus écrire quoi. Et donc c'est là où je me suis dit, vraiment si j'arrive à archiver tout ce que je fais et mon contexte à apprendre avec lui et etc. Ça va être, ça va bien marcher. Et du coup j'ai créé un OS pour pas pour moi pour voir en toute l'entreprise. Donc concrètement c'est un repo GitHub pour, enfin où il y a un folder par domaine de entreprises, marketing sales, que c'est marseux, tout ça. Et sur chaque folder du coup, je log. Tout ce qui a été produit en termes de contenu, toutes les événements qui sont arrivés. Je connecte aussi à tous mes outils de CRM, RIS, de Nuts, Mail, Agenda, cela qui fait en tout. Et le but, c'est vraiment que maintenant dès que je commence une tâche, je demande à l'agenda le faire. Si je vois qu'il n'y arrive pas, je vous donne le contexte qui manque pour le faire. Il l'apprend, il le garde en mémoire. Et du coup, on fiche un mesure et il est plus en plus bon à faire les choses. Et je pense maintenant que le seul truc qui me bloque justement, c'est l'accès aux outils que je utilise. Par exemple, je parle de Slack tout à l'heure. Le MCP Slack permet de se connecter à un seul Workspace Slack. Alors que moi, je prends des dices. Et donc, c'est ça, en fait, la limite. Maintenant, c'est plus la connectivité. Et tous les outils que je choisis, je choisis sur critères de est-ce que c'est connecté aux agents ou pas. Il perd intéressant. Et donc aujourd'hui, les choses peut-être là quand je t'écoute, j'ai l'impression que ça marche bien. Est-ce que ça va? Donc, elles sont les choses sur lesquelles peut-être ça marche moins bien, ou tu penses que ce n'est pas encore maturant? Je dirais que pour un instant, après si je suis au début, c'est plus sur la partie que ce marche que c'est. C'est une question de client parce que du coup le contexte, il est très éparpillé dans plein d'endroits différents. C'est encore un peu dur pour lui de trouver tous les infos à tous les endroits possibles. Donc j'irais que c'est plutôt sur ces parties-là. Et après, sur le contenu, je trouve qu'il faut quand même faire beaucoup de contenus manuellement pour qu'il arrive à prendre le bon ton. Avant d'avoir fait une centaine de postings, ça va toujours être de l'Eye Slope avec des learning of the day. Oui, donc avoir quand même une certaine matière avant de. Oui. Je pense qu'il faut quand même passer par une phase où il faut faire des choses manuellement beaucoup avec. Pour qu'on suit de cette tourne. Très clair. Avant d'aller vers mes questions de fin des change, je suis tiens un sujet dont on n'a pas parlé. Quand tu aimerais aborder un point en particulier, un message à faire passer. Je pense que le point. Je pense qu'il faut pas se mettre une marche trop haute pour faire les choses et essayer avec ce qu'on a, pas essayer de trop se renseigner, trop faire les choses dans les règles de l'arbre. Moi, je sais pas ce que j'ai fait. J'ai juste tenté avec ce que j'avais à chaque fois. Et puis, on avance de façon incrementale. Je pense que c'est comme ça que ça fonctionne en expérimentant. Oui, complètement aligné là-dessus sur avoir la notion de vouloir être dans l'action, pour justement faire et en faisant, on apprend et d'autant plus que les boîtes en face qui construisent ces nouveaux outils eux aussi, sont dans cette même démarche. Les outils évoluent en même temps que les usages évoluent. Et donc, en fait, au final, c'est aussi une. Mettuellement, entre les utilisateurs et ceux qui construisent ces produits-là, il y a un enrichissement qui va dans les deux sens. Et je trouve intéressant pour. Il dirait ça, c'est ChatGPT Apps qui sont sortis du coup, c'était fin de 1915 ou début de 1926, cela en France. Donc, le qu'on sort des apps dans ChatGPT. Les guidelines, en fait, au début de ChatGPT, étaient très vague sur qu'est-ce que c'était qu'une bonne ChatGPT Apps puisque eux-mêmes, au PNI, ils ne savaient pas, en fait, quoi à mettre, ils attendaient de voir comment les utilisateurs allaient se comporter au sein d'une app qui pop dans une contexte de FNAF, de ChatGPT. Et donc, ça montre aussi que tout le monde, et en fait, est en train d'apprendre en faisant quoi. Donc, je suis assaligné sur ça, le fait de construire d'apprendre après le bon. Après, le problème de ça, c'est que du coup, il y a beaucoup de gens qui sont en mode 8 et 6, quoi. Il y a beaucoup de gens qui ne disent, il y a trop de trucs sortes. Je sais pas qui va gagner dans l'histoire. J'ai attendu de voir, mais je pense que ce sera trop tard. C'est comme si, en avisieanne, j'ai attendu d'apprendre que les ordinateurs allaient finir d'évoluer avant d'apprendre à les utiliser. Je pense qu'il faut prendre la vague et puis, peut-être, on prendra la mauvaise vague, mais au moins, on aura à briller quelque chose. Oui, non, je pense que c'est assaligné là-dessus. Donc, pour aller vers, mais question de fin des change, la première, c'est, est-ce que tu as une conviction forte avec laquelle tu as en général, en désaccord avec tes pairs? Ma conviction forte, j'étais en désaccord, c'était que, moi, en le cas, c'était que, je pense que les profils business vont avoir de plus en plus d'importance. C'était plutôt dans la data, quoi. Il y a toujours un peu ce truc de, il y a des data qui viennent de la tech, il y a des data qui viennent du business, qui va prendre le dessus en truc dimé. Je recruche que c'était la business, parce que pour moi, le business sense, les capacités de réflexion, etc. C'est des choses qui s'apprennent pas forcément et le code, enfin, c'est quelque chose qui s'apprend, qui se maîtrise, on va dire, quoi. Mais il y a quelques années avec une mauvaise un peu, est-ce code qui, du coup, faisait que, on disait, "Ah oui, non, mais les gens qui savent pas coder, ils vont nulle part." Et je pense qu'on m'a donné un peu un renversement de cette situation, ou en fait, t'as plus besoin de savoir coder, ce qui va te distinguer, c'est ton business sense, ton tais, c'est ta créativité. Et donc, aujourd'hui, il fait bon, ne pas savoir coder finalement. - Oui, alors après, moi, voilà, par rapport à ça, tu vois, tout dépend des sujets sur lesquels tu boches, je trouve, parce que la barrière à l'entrée du code, complètement liné, elle est complètement ambécée, le coup en fait de produire du code et vachement baissé. En revanche, en fonction des produits sur lesquels tu travailles derrière, si tu as pas la compréhension, tu peux sortir des choses rapidement, sans savoir coder. Mais si tu comprends pas ce qui se passe sous le capot, tu peux arbitrer des choix parfois qui ne sont pas bien arbitrés, parce qu'en fait, tu n'as pas compris aussi certains sous-achemantes techniques. Donc, je pense qu'il y a un peu des nuances. Là-dedans, je trouve que j'ai du mal t'assonant avec la notion que tu vois de mettre dans des cases, soit des business, soit des dèques, je pense qu'on va plus vers des profils assez hybrides qui comprennent à la fois l'un et l'autre. Et c'est comme ça en fait que tu arrives derrière à construire des choses qui sont pertinentes. Mais après oui, c'est sûr que dire aujourd'hui codis-low, c'est moi la mode, en tout cas, qu'il y a quelques. Mais, il fait chiant que si il faut avoir une bonne base, mais je pense que c'est moins important d'être vraiment un expert encore de qu'avant. Et donc pour aller vers ma dernière question, qu'est-ce que tu te nourrisses intellectuellement? Je pense que, comme je vous disais, ce qui me nourrit attention à, c'est vraiment de tester des nouvelles choses, de faire des nouvelles choses, dès que je vois quelque chose de nouveau qui sort. J'essaie de le tester dans mon coin. C'est comme ça que j'apprends. Il y a toujours des nouvelles choses à tester aujourd'hui. Ça me donne pas mal l'inspiration sur ce qu'on construit, comment je l'intègre dans le project, etc. Voilà, il y a pris d'un point de vue plus personnelle, où je viens couter des podcasts sur votre entrepreneur, à développer un personnel, et pas mal apprendre de mes pares de centroprenaire aussi. Et le meilleur endroit pour te suivre du coup, et sur vos aventures avec Jonnao. Merci pour ton partage, et puis l'on vit à Longuie-Annao. Merci. Ça y est, l'épisode est terminée. Si celui que vous a plu, vous pouvez me soutenir en mettant un commentaire et une note sur votre plateforme d'écoute préfaite. Aussi, n'oubliez pas de vous abonner aux podcasts pour être sûr de n'a rien manqué. À très bientôt sur JustEclic.